March 2008 Archives

SSL certificates are a necessary component for using WebAuth and for serving any web pages using https. ITS provides some guidelines for getting SSL certs, with information on how to procure certs from Stanford's "certificate authority of choice" --essentially the third-party vendor with whom ITS works most often. There's even a nice web form to streamline the process. InstantSSL is fine, but they cost $83 per two-year certificate. This is the best choice if you have sensitive data and need that level of confidence.

But for other occasions, there are alternatives worth considering. You can use a self-signed certificate, but that might just annoy or confuse your users with browser warnings about untrusted certificates (and they don't enjoy a high degree of trust). Or, you can use ipsCA, which is a Spanish certificate authority that offers free two-year SSL certificates to educational institutions. Their root certificate (IPS SERVIDORES) is on just about every computer out there, too, so it works almost every browser. In other words, it's legit.

Here are some simplified instructions on how to implement SSL on your Leopard web server on a SUnet host. We'll start with generating the certificate signing request (CSR).

On the Libraries’ cluster computers we need to allow Stanford people to log in with their SUNet IDs and passwords. This means that we need to authenticate against Stanford’s LDAP server. Previous documents have described how to do this for 10.4, and this document will cover the much easier process for 10.5.

In addition, we will be covering how to auto-mount the users AFS home directory as their home directory.

Note: Auto-mounting the home directory can cause problems if your users move back-and-forth between OS versions. You should be aware of this potential problem.

On the Library cluster macs we decided that we should set a specific SSH option for a number of the shared computers on campus (for example: Cardinal). The specific option is GSSAPIDelegateCredentials, and when used with GSSAPIAuthentication and GSSAPIKeyExchange allows users to ssh from our cluster computers to the selected hosts without typing a password (while getting full Kerberos-based services on the new host). We had considered allowing this for all hosts with a stanford.edu address, but concerns about untrusted computers that might have stanford.edu addresses (like all the computers in the Residences), along with some of the details about how names are evaluated for ssh_config meant we had to be a little more savvy. At the same time we were not interested in managing an ever-changing list of hosts.

The solution that we came up with was to decide to trust the hosts listed in the canocial list of stanford hosts found at '/afs/ir.stanford.edu/dev/pubsw/config/ssh/' (that is in afs space). I wrote a script that pulls in this information from the canonical file, and then makes modifications to both /etc/ssh_config and /etc/known_hosts. I am offering this script out to anyone who might like to use it.

I've been busy modifying the syslogd.conf file on various servers to additionally send entries to a central syslog server. Getting syslogd to restart properly after modifying the conf file proved to be more problematic than it should be.

You'd think you'd be able to use a kill -HUP, but that's not appropriate here. You'd think you'd be able to issue a launchctl stop command, but that doesn't do it either. If you just kill it, even with a -9 flag, you'll see launchd just happily pops up a new one. That was my case, but the new syslogd wasn't actually logging.

Instead, what worked for me was to issue this command.