Skip to content. | Skip to navigation

Personal tools
Log in Register
Sections
You are here: Home Articles Open Directory PKI

Open Directory PKI

A brief introduction.

I first presented the basics of this information at a session at the MacIT 2013 conference in San Francisco. However, the session was only 45 minutes long, so I couldn't go into much detail on how I accomplished the tasks. This series of articles is the result.

We're moving into an era of ubiquitous digital certificates. Going forward, almost all network services will be secured via a certificate-encrypted and -verified connection, whether using the TLS protocol or using IPSec. Right now, obtaining a certificate that is good for an extended period is both inconvenient and expensive. If you need to cover multiple DNS host names it's even worse; you have to do this for each of the DNS host names, either by individual certificates or by using a Subject Alternative Name certificate.

Each time you have to wait for the CA to issue the certificate, which can take several minutes to several hours at a minimum. At worst it can sometimes take several days. It's enough of a hassle that most admin's don't bother unless they're setting up an external service.

[soapbox] The original idea behind certificate expirations was that you could limit the damage due to a compromised private key. However, doing so would require a rotating the certificate very frequently, at intervals on the order of days or weeks. This doesn't happen, so certificate expirations have turned into a way for CA's to make more money without doing any more work. [/soapbox]

By taking advantage of the Open Directory CA, you can issue up to 5-year certificates for any purpose, with no waiting. All you have to do is install the appropriate trust profile on your clients. Since you'll be doing this anyway for Profile Manager, there's no additional cost to it. Binding an OS X computer to OD can accomplish the same thing. It's also a lot more convenient since you can just issue the certificates yourself, rather than going through an external purchase process.

The downsides are that these certificates are only going to be trusted by internal clients, and you have to be more careful with your infrastructure. However, for some purposes that's just fine, as many services aren't going to be used legitimately by anyone outside the organization. For customer-facing services, you probably want to use certificates verified by an external CA. However, that's going to be a fraction of the services that could utilize certificates.

BTW, Apple is behind the curve on this. A much more sophisticated Certificate Services role has been included in Windows Server for years.

I've split the article into three parts, to keep the lengths manageable. Here are direct links to the parts:

Part 1: Creating the Certificate Authority

Part 2: Extracting and Preparing the Certificate Authority

Part 3: Issuing Certificates

I hope this information is useful to everyone, and thanks for taking the time to read through things. As always, I value feedback and suggestions. Feel free to contact me if you can think of a way to improve the process, have additional information that people should know, or just want to say thanks!

Entire article as a PDF.

Document Actions
Add comment

You can add a comment by filling out the form below. Plain text formatting.

(Required)
Please enter your name.
(Required)
(Required)