Volume Number: 25
Issue Number: 07
Column Tag: Security

Demystifying PKI-Part 2

A Series of Articles and How-Tos about PKI technology in the OS X environment

By Michele (Mike) Hjörleifsson

Last month we traveled the road of history reviewing where PKI came from, what it is and how it is used. This month, let's dive into what we can use PKI for on a daily basis and then we'll set up our own standalone Certificate Authority (CA) and start cranking out some certificates of our own.

Issuing SSL certificates to protect websites, e-mail, iChat, iCal and other OS X services is probably the most popular use for PKI on the OS X platform. Yet, there are some other interesting uses you'll want to know about. Digital signing has become a more popular use of PKI so it's worth mentioning in this context. If you have ever downloaded an ISO file or manually downloaded an update from Apple, you have probably seen either an MD-5 or SHA-1 hash that is associated with the download. The hash provides a sanity check to ensure you downloaded the entire file properly and in tact. The concept behind digital signing is similar to providing this hash with one caveat; it uses your personal certificate as part of the generation process so that the signature is specific to you. This is the smoke behind the mirrors on digital signing.

Mac OS X Leopard provides an application for administrators to create a CA and provide some basic functionality utilizing OpenSSL via a little known and somewhat hidden GUI application called Certificate Assistant. In the following section, we will create a CA and then generate a self-signed certificate that can be used for several of the Mac OS X server-provided services.

From Finder, press Command+Shift+U to open the Utilities folder (a sub-folder of your Applications folder). Select and then open the Keychain Access application. From the Keychain Access menu, select Certificate Assistant and then choose Create a Certificate Authority.

The Certificate Assistant Application launches and then prompts you to enter some basic information about the CA you want to create. Enter the name of the CA. For 'Type,' select Self Signed Root CA. Make sure the Let me override defaults box is checked.

Click Continue to proceed to the next dialog box.

Enter an arbitrary, unique serial number and a validity period. Mac OS X remembers certificate serial numbers and rejects a new certificate with the same serial number as a previous certificate (coming from the same authority, that is). Make sure you keep track of serial numbers. The User Certificate Type must be set to SSL Server. The other settings are for generating a pretty CA web page to let people make certificate requests for your new authority (you may want to use that), and to sign your certificate invitation.

Enter the basic contact information for the CA certificate. The Name (Common Name) field doesn't have to be a valid domain name, since the CA certificate won't be used by any server, but it is good practice to provide accurate information especially if you will be providing services to individuals outside of your internal organization. The email address entered is presented when someone looks at the details of the certificate and wants to pose a question to the owner of the certificate or certificate authority.

The next screen presents options for the key pair cryptography elements such as the size of the key and the algorithm used to create the key. The defaults are acceptable since 2048 bit keys are considered un-hackable and RSA is the most common algorithm in use today.

The CA certificate must have a Key Usage Extension with at least the Signature and Certificate Signing capability boxes checked. If either one of those capabilities are not specified, browsers and client applications will reject any child certificate (the certificates you create for your specific servers or services) of the CA certificate.

Next, specify the default key usage extension settings for any leaf certificate (also called a sub-certificate) created with the CA certificate as the root. SSL server certificates must have at least the Key Encipherment and Key Agreement capability boxes checked. If either one of those capabilities is not checked, services and browsers will reject the certificate.

Although documentation suggests this may not be necessary, giving the CA certificate an extended key usage extension with at least the SSL Server Authentication capability bit set has no serious consequences and provides additional insurance that browsers will be happy. Note that the default value is All, which provides more flexibility for you to issue certificates specifically for services assigned to dedicated servers (such as Mail).

Though the following screen may look the same as its predecessor, there is a purpose for the seeming redundancy. These options apply to the leaf or sub-certificates issued by the CA and what they should be allowed to do. You are setting permissions for the issued certificates coming from your certificate authority. Using Any is fine, but at a minimum you will want to employ SSL Server Authentication, the most common use for the certificates you issue.

The CA certificate must have a basic constraints extension with at least the Use this certificate as a certificate authority option specified. If it does not, client browsers and client side applications will reject any child certificate of the CA certificate and our entire exercise was for naught.

This step, though it seems redundant, specifies default basic constraints extension settings for any leaf or sub-certificate created with the CA certificate as the root. SSL server certificates must not have the Use this certificate as a certificate authority option specified (while having a basic constraints extension). If the extension is missing or that option is specified, services and client applications will reject the certificate.

Any certificate with the SSL Server type must have a subject alternate name extension specifying either the dNSName field or the iPAddress field. Obviously, there are no special constraints on the value of either of those fields for the CA certificate.

Again, any certificate with the SSL Server type must have a subject alternate name extension specifying either the dNSName field or the iPAddress field. The value of those fields must match the domain name or IP address which clients will use to contact SSL servers using any child certificate of the CA certificate. Obviously, we will have to override this value when creating each such child certificate unless we're creating them for the same server all the time. Nevertheless, Certificate Assistant requires a value to be specified to continue, so provide a reasonable default.

Select the keychain in which the CA certificate will be stored. If you want browsers using Keychain Services to accept child certificates of the CA certificate, check the On this machine, trust certificates signed by this CA box. Note that, as the label implies, this affects the trust setting for the CA certificate for the entire machine, not just your specific system user. Consider the consequences of that choice carefully. It is possible to change trust settings on a per user basis.

We can finally appreciate the fruit of our labor. Double-clicking the CA certificate in Keychain Access will allow you to confirm that all the required settings, options and capabilities are properly configured.

Now that we have a valid CA creating certificates for our web and other services, we see that utilizing the CA is pretty easy. I will not repeat the entire sequence of operations presented for the CA certificate, but rather focus on the steps that are specific to the creation of an SSL server leaf certificate. Keep in mind that the various restrictions mentioned above concerned leaf certificates since we have to override the default values we specified during the creation of the CA certificate. Certificate Assistant does not fill in those defaults.

From the Keychain Access application, choose the Create a Certificate command from the Certificate Assistant menu.

Enter the domain name that clients will use to access the SSL server as the certificate's name. For Type, choose Leaf. Check the Let me override defaults box to edit some of the certificate's settings we specified earlier.

Enter a serial number different from the CA certificate and different from any other leaf certificate you have already created, even if they were for the same domain. Applications check and keep track of certificate serial numbers. Certificates with identical serial numbers are rejected. Also make sure that the Certificate Type is set to SSL Server, otherwise applications may reject the certificate.

The Name (Common Name) field must match the domain that clients will use to connect to the SSL server; otherwise, applications will either reject the certificate out of hand or prompt you with an ominous warning message about the certificate mismatch.

Select the CA certificate created earlier.

SSL server certificates must have a key usage extension with the Key Encipherment and Key Agreement boxes checked. If they are not enabled, applications may reject the certificate.

SSL server certificates must have an extended key usage extension with, minimally, the SSL Server Authentication check box set. If it is not, browsers and other applications may reject the certificate.

SSL server certificates must have a basic constraints extension with the Use this certificate as a certificate authority option disabled.

SSL server certificates must have a subject alternate name extension with either the dNSName field or the iPAddress field specified. The values for those fields should match what clients will use to connect to the SSL server. In order words, the value for the dNSName field should match the value of the Name (Common Name) field of the certificate (specified the Certificate Information dialog box) and the value iPAddress field should match the IP address to which the dNSName domain resolves.

We can once more appreciate the fruit of our labor. Double-clicking the certificate in Keychain Access will allow you to confirm that all the required settings, options and capabilities are properly configured.

We can now install this certificate onto our Mac OS X Server and use it for Web, iChat, iCal, Open Directory or any number of services.

Now, while this may seem like a ton of work to get an SSL certificate, keep in mind that you will typically create the CA once on a standalone, preferably non-network connected machine and then issue and copy the SSL certificates as you need them when deploying servers or additional services. Why would you want this machine off the network you ask? Well, simple my dear Watson. If someone gets hold of your root keys or can get onto the CA machine they can issue certificates all day long and create bogus websites with security certificates in your organization's name�not a good thing. We will dive a little deeper into this concept in later articles when we discuss additional methods of protecting root keys and offloading cryptographic processing to a hardware security module (HSM).

Digital signing has become a hot topic in today's information technology circles. So what does digital signing mean exactly? There are three main types of digital signatures: one that is inclusive of the content; one that is separated from the content; and the third which is a digest or "hash" of the content.

For instance, when you manually download an Apple Update from the Apple website you will notice a line with SHA1 = xxxxx. This represents a digital "hash" for the download that is used to check the integrity of the downloaded file ensuring no one has tampered with a single bit of it. Here's a real life example.

Go to http://support.apple.com/downloads/iTunes_8_1_1_for_Windows and download the file.

Take note of the SHA=cad92e6882b5fb49d710d342f315d7d6293e2b0a at the bottom of the description. Once you have downloaded the file you can open a terminal and type:

   openssl sha1 iTunes811.dmg

The following is returned if the file has been downloaded intact and matches the file created by the signer. This is an example of a separate signature, signing:

   SHA1(iTunes811.dmg)= cad92e6882b5fb49d710d342f315d7d6293e2b0a

Another example of a digital signature is digitally signing email. Most users are unaware that it is extremely simple to forge an email from one party to another without the receiving party being aware of the forgery. Detecting the forgery would require the help of a forensic administrator or a savvy IT administrator. Digitally signing an email ensures that the message originated from the person in the from field by using something called S/MIME or, secure mime (Multipurpose Internet Mail Extensions), which puts a signature derived from your personal certificate into the headers of the email. If the email is tampered with in any fashion the signature is invalidated and most email programs will display an X or some other visual indicator to show the mail has been tampered with. This is a common example of an inclusive signature.

Installing this type of signature is pretty simple. You can issue a personal certificate from the CA you created above and double click it to put the certificate into your login keychain. Double click on it and "Always-Trust" the certificate for email. Be sure that the certificate's email contact matches your "from" address. Apple Mail will auto-magically change its compose pane to give you a check mark and lock icon below the subject on the right allowing you to sign and encrypt an email. That's all there is to it for signing. For encryption, since that is a little more involved, you need to send a signed email to your desired recipient and they need to send you one. Once the both of you double click and accept the other one's certificates, you can send each other encrypted emails that only the two of you and the root CA can open (because they can store your private certificate).

Digitally signing documents is gaining in popularity. The most popular applications that provide this capability are Adobe Acrobat for creating PDFs, and OpenOffice. Unfortunately Microsoft Office 2008 does not provide this functionality, while its Windows counterpart does, we can only hope the next revision will or someone will write a utility for injecting a certificate into Office 2008 documents. And sadly Apple's Preview is not currently signature aware either at the time I wrote this article.

Why sign a PDF or other document? Glad you asked. In 48 states, digital signatures of varying types are actually considered legal signatures. That's right, you can even sign your tax returns with a digital signature and put that pen away. The IRS has to accept it (if it meets some basic criteria). An even more obvious use of digital signatures in these types of documents is to make them tamper evident. Once you sign a document if anyone tampers with its contents at all it will "break" the signature. Why "break" vs. break? Well, it doesn't actually ruin anything. It just becomes quite evident via one or more visual indicators that the document was tampered with. Again we come back around to the question of why digitally sign a document? A couple of examples of documents you may want to digitally sign are legal contracts, financial documents, documents containing personal identification (more on this later), basically any document you want to ensure no one touches before it reaches the desired recipient.

While the simple CA installation routine above works well for smaller environments, it does not scale well. And, more importantly, it does not provide some key features an administrator would want to implement in a larger environment.

For instance, say you issued a certificate for a user to sign and encrypt their email. Later, that user has moved on to another company. How do you ensure the user isn't still using that certificate to sign emails as authentic your company emails? This is a key component in a certificate system and it is called revocation.

Certificate revocation is typically performed in one of two ways. Certificate revocation lists (CRLs) are the traditional way of maintaining a list of which certificates are no longer valid. CRLs were provided or distributed to resources that validated the certificates. This method proved a bit inefficient and validation occurred "offline" so a newer technology called Online Certificate Status Protocol (OCSP) was developed to allow for online validation and revocation of certificates in a more dynamic environment.

Additionally, in larger environments, you may be issuing various types of certificates, and may want to allow other administrators to create SSL certificates for their own internal servers, let users register and create their own email certificates and so on. Offloading some of the administrative burden makes the system more efficient. In next month's installment, we explore enterprise grade CA choices and a great choice for deploying enterprise certificate authority services in an Apple Mac OS X environment.

Michele (Mike) Hjörleifsson has been programming Apple computers since the Apple II+, and implementing network and remote access security technologies since the early '90s. He has worked with the nation's largest corporations and government institutions. Mike is currently a certified Apple trainer and independent consultant. Feel free to contact him at mhjorleifsson@me.com