Becoming a CSA to sign SSL certs for Open Directory Replicas

If you have an Open Directory infrastructure, and you want to secure your connections between the client and Open Directory services using SSL, the simplest solution is to purchase SSL certificates and install the certificate on your Open Directory Master and each Replicas.  However, each server will require its own certificate.  In this article, we'll look at how to create a Root Certificate Authority and how to create and sign certificates for your Open Directory Master and Replicas.

Read on for more…

Step 1: Create Your Certificate Authority

Open up /Applications/Utilities/Keychain Access.app, and check out the Keychain Access menu.  You’ll see a menu item called Certificate Assistant.  Select Create a Certificate Authority and the assistant will start. 

Give your CA a name, and select “Self Signed Root CA”.  If you get large enough, you can become an intermediate CA, which delegates the authority to issue certificates by the root CA.  We aren’t going to do that, so just select Self Signed Root CA.  Select the option to override defaults, because we want to be secure some things down.  The “Make this CA the default” just selects this root certificate in the popup menu when signing a certificate signing request (CSR) from a user.  Since you’ll probably just have the one CA, go ahead and make it the default.  Enter your an email address.  This email is used by Certificate Assistant when sending emails back to users’ requests when they want their certificates signed.  It does not go into any certificates.  That comes later.  Hit Continue.

Step 2: Certificate Information

Give your certificate a serial number (most likely 1 since this is the initial creation), and how long you want the certificate to be valid for.  Since we want SSL certificates, select the “SSL Server” certificate type.  This will allow us to specify some defaults to easily sign user requests when they come in with a single step.  A template is created at ~/Library/Application Support/Certificate Authority with the choices you make when creating the CA certificates that relate to users’ settings.

You also have the option of creating a CA web site.  It is a simple html based site that allows the user to download the root certificate to install in their keychain (or wherever they want), and to send you requests (via email or sneakernet) to sign a certificate that they have generated via a CSR.  The “invitation” is a special keychain type document that will automatically to to the “Generate Certificate Signing Request” section of Certificate Assistant, so it is really easy for an admin to use.  

Note that if you select to create this site at your .Mac site, make sure you have populated your .Mac info in System Preferences, and that the “Web” folder exists at the root of your .Mac disk.  If it doesn’t, post something to a Gallery in iPhoto, and the correct folders will be populate.  You can also have the html files, invitation, and CA certificate dropped into a folder of your choosing.  If there is an error writing to either .Mac or the local location, the CA certificate will still be created but the website creation will be skipped and you won’t be able to get back to the website creation without creating a new CA certificate.

Here is what the website looks like:

website

Pretty sweet, eh? Click Continue and you’ll fill out some information that will be on the CA’s certificate.

Step 3: Certificate Information (part 2)

This information will appear on the CA’s certificate, and you can’t change it without generating a new CA Certificate, so fill it out correctly.  None of fields are required, so only fill out information that you want to give to the user.  The Common Name is important to identify the certificate. Hit Continue.

Step 4: Key Pair Information for this CA

You now specify the key size and algorithm.  The defaults of 2048 bits and RSA are good choices, but you may want to check client software/browser compatibility.  Hit Continue.

Step 5: Key Pair Information for Users of this CA

This is where is may get a bit confusing.  The “Specify Key Pair Information for Users of this CA” window is identical to the prior window (aside from the title), and it doesn’t really have anything to do with the CA certificate creation.  It specifies the key information to use when signing requests.  The results of this window are saved to the template at ~/Library/Application Support/Certificate Authority/<CA name>.  Specify the same settings as the prior step.

Step 6: Key Usage Extension for This CA

The next screen determines how the CA’s certificate can be used.  You may have the impules to select all the options, since that will let you do whatever you want with it. Be aware, that with great power comes great responsibilty, and that didn’t work out so well for Uncle Ben.  If your root CA private key is ever compromised, you can limit the scope of what they can do with it.  We just want to sign other certificates, so just select the signing options.  The “extension is critical” just means that if the software using the certificate does not recognize the signature extension, it will refuse to use the certificate.  Probably a good thing, so select the “This extension is critical” checkbox.  Hit Continue.

Step 7: Extended Key Usage Extension for This CA

The next step allows you to limit how the certificate is used.  Actually, this is a misnomer.  For  CA certificate, this specifies what kind of certificates can be created with the root certificate.  If you choose not to include Extended Key Usage Extension, the root certificate can be used for any operation.  While this may sound good, it also means that if the private key is compromised, it will not limit the scope of the what could be done and what needs to be revoked.  It is best to only specify what needs to be done with the root certificate.  For our purposes, we’ll select SSL Server Authenication, since we’ll be install the certificates on Mac OS X Server for SSL connections.  Note that any options selected here must be selected in the next window for client connections, otherwise you may be in a situation where you are trying to create a certificate for an usage that is not supported. Click Continue.

Step 7: Extended Key Usage Extension for Users of This CA

This is where we we specify the options for when we sign requests (CSRs).  These options don’t affect the root certificate, but only save them in the template file at ~/Library/Application Support/Certificate Authority/<CA name>.  Specify the same options as in the prior step. For SSL connections on Mac OS X Server, you should select “SSL Server Authentication”.  Click Continue.

Step 8: Basic Constrains Extension for This CA

The Basic Constaints Extension for the CA specifies that this is indeed a certificate authority (it is).  We can also limit the number of intermediate authorities.  Since we do not know how many intermediates we’ll need, we’ll leave that option unselected.  Click Continue.

Step 9: Basic Constrains Extension for Users of This CA

The same options are available for when we sign certicates, but since those certificates will not be CAs, and we are not limiting the depth, we’ll leave this extension off.  Click Continue.

Step 10: Subject Alternate Name Extension for this CA

The next step allows you to provide information for service record signing (for details to make your ears bleed, see <link>).  We are not doing any of these operations, so we’ll leave this option unselected.  However, there is an issue with the Certificate Assistant that even if you leave the option unselected, you’ll get strange red arrows that point to whitespace:

warning

The mysterious red arrows are pointing to DNS name and IP address text fields, which aren’t shown.  A workaround is to select the “Include Subject Alternate Name Extension” checkbox, put anything in the dns field, and deselect the “Include Subject Alternate Name Extension” checkbox.  You then can continue.  Do the same thing for the Subject Alternate Name for Users of This CA.

Step 11: Specify a  Location for The Certificate

Finally!  The last step is to save our root certificate, in a keychain.  The System keychain would make sense for all users of the system, but the public key and private key is stored there as well.  Best to store it in our own keychain to keep it safe.  Make sure you check the “On this machine, trust certificates signed by this CA” so that any signed certificates will show up as successfully verified.

The certificate then gets created…

You are now a root CA!  Congratulations!  Take a look at the certificate by clicking the “Show CA Certificate…”.

If you open up your login keychain, you should now see a public key, a private key, and the root certificate.  Let’s have some fun and sign some certificates to use in Server Admin.

Open up Server Admin, and select the server name under Servers, and click on the spiffy “Certificates” button.  You’ll see a single Default certificate, which doesn’t do us much good since it does not include the server DNS name and will be rejected by SSL clients.  We need to create our own certificate, and get it signed by our CA.  Let ramp it up!

First, create a self-signed certificate that we'll get signed by our CA.  

Click “+” to add a self signed certificate.   You’ll see a form to fill out.  Put in a Common Name that is the DNS name of the server that will be providing this certificate.  Don’t worry about filling the remainder of the information, as Certificate Assistant only recognizes the Common Name and will ignore the other information in the CSR when signing the request.  You can always fill it in when you are signing the request and then it will be put in the server certificate.

After you have filled out the info, click Save. 

Now that we have a self-signed certificate, let's get it signed by generating a certificate signing request.  Make sure the self signed certificate you created about is highlighted in the top section, select the gear, and select “Generate Certificate Signing Request”.  You’ll see a sheet appear with a form to fill in an email address.  Ignore it since we are going to use the magic of drag and drop (but leave the sheet open and don’t click done).

Go back to Keychain Access, and select “Certificate Assistant->Create a Certificate For Someone Else as a Certificate Authority”.  You’ll see a window with a place to drag the CSR.  Drag the CSR from Server Admin to Certificate Assistant:

Drag Illustration

You can then select the Certificate Authority that is used to sign the request.  The “Make this CA the default” option just means that in future signings, this will be the CA that get selected by default in the popup menu.  The “Let me override defaults for this request” will allow you to change the defaults we set when for User requests when creating the root certificate.  It will also allow you to add other information beside the Common Name (DNS name of server) to the certificate that is being signed.  If you just care about the DNS name, select Continue and the certificate will be created.

You’ll see the information about the certificate, but don’t click “Done” yet.  We can drag the certificate from here back to Server Admin once it is set up (if you did click Done, just find the certificate in your login keychain under the DNS name and open it up).

In Server Admin, select your self-signed certificate you created for the server, and select “Add Signed or Renewed Certificate from Certificate Authority”.

If you drag and drop the certificate now, it won’t be recognized by Server Admin.  It has to be in pem format.  To do this, hold down the option key, and drag from Certificate Assistant to Server Admin:

Drag Illustratioon of PEM

You should see the certificate in pem format (encoded text with “—–END CERTIFICATE—–” at the bottom).

Click Save, and you should see the description of the certificate change from “Self Signed” to the name of the Certificate Authority.  Success!  (If Server Admin crashes, launch and try again.).

We now have a rocking setup.  We have a website that has our root certificate so users can add it to their machines, and we have a certificate for our server that we can use to encrypt traffic and verify our server’s identity.  Let’s kick the wheels a bit by using it with Open Directory.

Select the Open Directory service in Server Admin, enable SSL, and select your SSL certificate for your server that you just created.  You can now follow the most excellent instructions on getting Leopard clients to work with SSL.

Securing Open Directory Replicas with CSA signed certificates 

But what about replicas?  Server Admin doesn’t allow you to select certificates for replicas, but each replica needs to have its own cert.  You can still create certificates under “Certificates” in Server Admin on the replica, but you can’t install them or set openldap to use SSL through the GUI.  Go ahead and create a self signed certificate and sign it as outlined above on the replica, and check out /etc/certificates on the replica. You should see your new certificate in that directory. However, OpenLDAP doesn't know about it.

OpenLDAP in Mac OS X 10.5 “Leopard” Server stores its configuration inside the LDAP store, at “cn=config”. Don’t confuse this with “cn=config,dc=<domain component>, dc=<domain component>, dc=<domain component>…”.  This “cn=config” is a entry that stores the configuration information of slapd.  To modify it, we use an ldif file and do a ldapmodify:

-----------

dn: cn=config<br />olcTLSCertificateFile: /etc/certificates/xs3.twocanoes.com.crt<br />olcTLSCertificatePassphraseTool: /etc/httpd/getsslpassphrase xs3.twocanoes.com:636 RSA<br />olcTLSCertificateKeyFile: /etc/certificates/xs3.twocanoes.com.key<br />&nbsp;---------

ldapmodify -W -x -f ldif -D &quot;uid=root,cn=Users,dc=example,dc=com&quot; -h &quot;xs3.twocanoes.com&quot; <br />

Modify the LDIF above to reflect the name of your certificate. The “-D” option specifies the path to an OD admin user.  Note that since we did not use a passphrase on the private key, we don’t really need the “olcTLSCertificatePassphraseTool” line above, but since Server Admin adds it when using SSL on the OD Master, it is probably safer to add it in with the replicas as well.

With this config, the replica now knows about the certificate, but is not listening on port 636 for LDAP queries over SSL.  OpenLDAP is launched by launchd, and we can modify the launchd config for OpenLDAP.  In the bolded line below, add “ ldaps:///”:

<span>bash-3.2# cat </span><span> /System/Library/LaunchDaemons/</span><span>org.openldap.slapd.plist&nbsp;</span>

&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />&lt;!DOCTYPE plist PUBLIC &quot;-//Apple//DTD PLIST 1.0//EN&quot; &quot;http://www.apple.com/DTDs/PropertyList-1.0.dtd&quot;&gt;<br />&lt;plist version=&quot;1.0&quot;&gt;<br />&lt;dict&gt;<br />    &lt;key&gt;Disabled&lt;/key&gt;<br /> &lt;false/&gt;<br />  &lt;key&gt;Label&lt;/key&gt;<br />    &lt;string&gt;org.openldap.slapd&lt;/string&gt;<br /> &lt;key&gt;OnDemand&lt;/key&gt;<br /> &lt;false/&gt;<br />  &lt;key&gt;Program&lt;/key&gt;<br />  &lt;string&gt;/usr/libexec/slapd&lt;/string&gt;<br /> &lt;key&gt;ProgramArguments&lt;/key&gt;<br /> &lt;array&gt;<br />       &lt;string&gt;/usr/libexec/slapd&lt;/string&gt;<br />     &lt;string&gt;-d&lt;/string&gt;<br />     &lt;string&gt;0&lt;/string&gt;<br />      &lt;string&gt;-h&lt;/string&gt;<br />     &lt;string&gt;ldap:/// ldapi://%2Fvar%2Frun%2Fldapi <strong>ldaps:///</strong>&lt;/string&gt;<br />   &lt;/array&gt;<br />  &lt;key&gt;ServiceIPC&lt;/key&gt;<br />   &lt;false/&gt;<br />&lt;/dict&gt;<br />&lt;/plist&gt;

Unload and load slapd (or reboot the server):

bash-3.2# launchctl unload org.openldap.slapd.plist <br />bash-3.2# launchctl load org.openldap.slapd.plist <br />

You should now be able to do a query over SSL to the replica:

ldapsearch -v -x -H ldaps://xs3.twocanoes.com 

Your clients should now be able to connect to your replicas over SSL, and can do so knowing that the certificate is valid. Since you installed your root CA on the clients, you do not need to worry about SSL with new servers and replicas coming online. The clients will follow the certificate chain and be able to verify the certificate.  

Timothy Perfitt

Timothy Perfitt is currently the head of Twocanoes Software, Inc, creator of iOS and Mac apps for the IT market. Prior to Twocanoes Software, he survived the collapse of the dot com era by jumping from Coolboard.com to Apple, Inc in 2001. He worked on the initial certification training materials for Mac OS X, worked in Education Sales, and then finished his time at Apple in 2012 working with Fortune 500 customers to integrate Macs and iOS devices into complex environments. He is a returned Peace Corps volunteer, serving in the Solomon Islands as a math and science teacher from 1991 to 1993.

More Posts - Website

Follow Me: