How to Install an ipsCA SSL Certificate in OS X

ipsCA is a company that sells SSL certificates. Their SSL certificates are recognized by all the major browsers so you don’t need to worry about manually installing additional Certificate Authority (CA) certificates into your users’ web browsers like you have to do with CA companies whose certificates are not included by default in the major web browsers. What is great about ipsCA is that they offer free 2 year SSL certificates for educational institutions such as Universities. If your domain ends in .edu then you qualify for a free 2 year SSL certificate.

ipsCA certificates are a little unusual in that you need to install two certificates onto your server before it will work. I couldn’t find a documented set of procedures for installing ipsCA certificates on a MacOS X 10.4 server so I wrote some up:

Installing an ipsCA SSL Certificate in OS X 10.4

Generate the CSR

  1. In Server Admin, select the server you would like to secure.
  2. Click “Settings” > “Certificates” tab > “Add(+)” button.
  3. A dialog box will appear to enter your certificate information. Please refer to vs7313 for detailed CSR requirements.
  4. Enter starting and ending validity dates.
  5. Select private key bit length size (1024 is recommended and required for three year certificates)
  6. Enter a passphrase (“password”) for your private key.
    • Apple recommends “use at least 20 characters, include mixed case, numbers and/or punctuation, have no characters repeat, and having no dictionary terms.”
  7. Click “Save”. Now, “Request Signed Certificate From CA” can be selected.
  8. A dialog box will appear. Drag the certificate icon onto your desktop. This will create your CSR file.
  9. copy and paste the text of the CSR file into the certificate request form on the ipsCA website.
  10. Submit the request and wait for ipsCA’s email response.

Import the Signed Certificate

  1. In Server Admin, select the server the certificate needs to go on.
  2. Click “Settings” > “Certificates” tab
  3. Highlight the certificate the signed certificate corresponds to.
  4. Click the “edit” icon.
  5. Click the “Add Signed Certificate…” button.
  6. Paste the contents of the signed certificate text file you received from ipsCA into the text box that appears. Press OK to import the signed certificate.
  7. Quit and restart the Server Admin app to make sure it refreshes the status of the signed certificate.
  8. When you try to edit the certificate all the fields should be greyed out to indicate the certificate is signed and the import was successful.
  9. You may need to redesignate the newly signed certificate in the web server and/or restart it before Apache will start using the newly signed certificate.

Install the ipsCA Intermediate Certificates

1. Copy the ipsCA intermediate certificates bundle file into the /etc/certificates/ directory on the web server. At the time of this writing this file was named “IPS-IPSCABUNDLE.crt. The file is available on the ipsCA website.

2. Change the permissions on the certificate bundle to “640”.

  • cd /etc/certificates
  • sudo chmod 640 IPS-IPSCABUNDLE.crt

3. Navigate to the folder /etc/httpd/sites/ and locate the .conf file that corresponds to the the SSL virtual host that the certificate belongs to. Usually the filename of the .conf file will be named in the format “someNumber_IPAddress_443_fullyQualifiedHostName.conf”

4. Once you locate the file, open it in a text editor at locate the part of the virtual host section that covers the SSL certificate settings. The section you are looking for will look something like this:

SSLEngine On
SSLLog "/var/log/httpd/ssl_engine_log"
SSLCertificateFile "/etc/certificates/www.foo.com.crt"
SSLCertificateKeyFile "/etc/certificates/www.foo.com.$
SSLCipherSuite "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP$

5. Add the following setting in between the “SSLCertificateKeyFile” and “SSLCipherSuite” setting:

SSLCertificateChainFile /etc/certificates/IPS-IPSCABUNDLE.crt
  • When you are done the certificate section should looking something like this:
SSLEngine On
SSLLog "/var/log/httpd/ssl_engine_log"
SSLCertificateFile "/etc/certificates/www.foo.com.crt"
SSLCertificateKeyFile "/etc/certificates/www.foo.com.$
SSLCertificateChainFile /etc/certificates/IPS-IPSCABUNDLE.crt
SSLCipherSuite "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP$

6. Save your changes and restart the web service. You should now be able to navigate to your SSL website and receive no “invalid” certificate errors. You can test your web server by using the ipsCA test website at: http://certs.ipsca.com/checkserver/

SSL Certificate

10.5 Leopard – How to Manually Kerberize Services

Introduction

Today when I went to “kerberize” the services on my 10.5.1 Leopard server I attempted to follow the instructions in the official Leopard server manual. If you have read the “excellently written” (FYI I am being sarcastic) OS X server manuals then you already know how it went. In the manual it states there is supposed to be a nice pretty button in the Open Directory service settings that you can just press to “kerberize” all built-in services on your server which are capable of being kerberized. Well when I went to the location the manual stated the button should be there was no button. At this point I already knew what had to be done. If you haven’t figured this out yet, for every server administration operation you can do with the pretty GUI apps that Apple provides, you better know how to do it from the command line. Because when the pretty GUI tools fail you, you are up the creek unless you know how to bust out the terminal and do it the “hard” way. Before I tell you the terminal command to run to kerberize the services on your server, here is a very brief explanation of how kerberos works with Leopard when a user accesses a “kerberized” service. I warn you that I am no kerberos expert and what I am about to tell you may not be accurate but it is what I have observed from the dozens of test installations I have done with Leopard.

Description of Leopard Client/Server Kerberos Interaction

For this explanation I will use the example of a user wanting to connect to a Leopard file server via Apple File Sharing using purely “single sign-on” kerberos authentication. Let us assume the Open Directory is properly setup and its Kerberos services are running fine and the client computer the user is using to access the file server is configured to authenticate against this Open Directory server. Let us also assume that the file server has been configured to authenticate against that same Open Directory server. So here is the whole process of what happens when the user accesses the file server:

1. The user logs into their Leopard desktop computer in their office. Upon logging into the computer OS X requests and receives a kerberos ticket from the Open Directory server.

2. The user then initiates an AFP connection to the file server.

3. The AFP service on the file server first asks the Open Directory server if the user has already been issued a valid kerberos ticket. Before responding to the AFP service, the Open Directory server first checks its configuration to see if the file server has been authorized by an administrator to use the kerberos services of the Open Directory server. If the file server has been authorized then the Open Directory server responds to the file server. If the user has not been issued a valid ticket, then the user is prompted with a username/password dialog box which allows the user to receive a new kerberos ticket from the Open Directory server.

4. Once the user has a valid kerberos ticket then the AFP service on the file-server issues the user another ticket for accessing its AFP file service. The user is then automatically logged into the server via Kerberos. At this point the user has a valid kerberos ticket for accessing the Apple File Sharing service on the server so until the user reboots their computer or their kerberos ticket expires, they will be able to log into the AFP file service on the server automatically without being prompted for a username/password.

Terminal Command to Manually Kerberize Services

This terminal command will kerberize all the built-in Leopard services which are kerberos compatible. It will write entries into the Open Directory master’s kerberos configuration. There will be a kerberos configuration entry added for each service.

sudo sso_util configure -r YOUR.REALM.COM -a diradmin -p theDirAdminPassword all

Replace YOUR.REALM.COM with the exact name of your Kerberos “realm” which is displayed in the settings of your Open Directory master server. Replace “diradmin” with the username of an account that has “directory administrator” privileges for your Open Directory. By default this account is named “diradmin” but it may be different in your environment. Replace “theDirAdminPassword” with the password of the “diradmin” account.

Once you execute the above terminal command, you may need to restart your newly “kerberized” services on your server for the changes to take effect.

10.5 Leopard – Server Tools Rant

So far my early dealings with the Server Admin app and other server management tools in Leopard Server have not impressed me much. I was hoping for a lot of improvement over the Tiger versions of the programs but some of the same old bugs are there. In particular the Work Group Manager app has been giving me the same old negative numbered errors occasionally and as with Tiger when that happens whatever process it was doing is instantly aborted without a rollback so you are left with user/computer/group objects with partially edited states resulting in weird errors. At this point I have to roll up my sleeves and do “surgery” on the Open Directory via the “inspector” in order to manually remove the remnants of the aborted process. C’mon Apple… proper error handling with rollback of “atomic” operations is something I learned in my first year of Computer Science. Try/catch blocks with undos of what was done before the process threw an exception please! Showing the user a cryptic error message with a negative number and a reference to a line of source code is ridiculous and way below the standard that is expected of Apple’s typically user friendly software. Rant done.