OS X Server Essentials 10.10: Describe SSL Certificate Basics
From the book
From the book
From the book
Reference 4.1 Describe SSL Certificate Basics
You want the users who use your server’s services to trust your server’s identity and to be able to encrypt network traffic with your server.
The OS X solution is to use SSL, which is a system for transmitting data securely between hosts. You can configure your server to use an SSL certificate, which provides the ability to use the SSL system.
An “SSL certificate” (also referred to as simply a “certificate”) is a file that identifies the certificate holder. A certificate specifies the permitted use of the certificate and has an expiration date. Importantly, a certificate includes a public key infrastructure (PKI) public key.
PKI involves the use of public and private keys. Grossly simplified, a “key” is a cryptographic blob of data, and within PKI, public and private keys are created in a way that they are mathematically linked: Data encrypted with one key can be decrypted only by using the other key. If you can decrypt data with one key, it proves that the data was encrypted with the other key. The public key is made publicly available, and the private key should be kept private. Fortunately, all of this encryption and decryption happens behind the scenes and is the basis for establishing secure communications.
Here are some definitions:
A “digital identity” (or more simply, an “identity”) is an electronic means of identifying an entity (such as a person or a server). An identity is the combination of a certificate (which includes the public key) and the corresponding private key. If you don’t have your private key, you can’t prove your identity. Similarly, if another entity has your private key, that other entity can claim your identity, so be sure to keep your private key private!
Again simplifying, a “digital signature” is a cryptographic scheme that uses PKI private and public keys to demonstrate that a given message (a digital file such as an SSL certificate) has not been changed since the signature was generated. If a message, which has been signed, changes or is otherwise tampered with, it will be clear that the signature no longer matches the underlying data. Therefore, you can use a digital signature on a certificate to prove its integrity.
A certificate must be either self-signed or signed by a “certification authority” (also known as a “certificate authority” or, more simply, a “CA”). In other words, you can sign your own certificate using your private key (remember that a certificate is a file that identifies the holder of the certificate and includes the public key), or you can have someone else, namely, a CA, use their private key to sign your certificate.
An “intermediate CA” is a CA whose certificate is signed by another CA. So, it’s possible to have a hierarchical “chain” of certificates, where an intermediate CA, which in turn is signed by yet another CA, signs a certificate.
In the following figure, the certificate for www.apple.com is signed by an intermediate CA with the name of Symantec Class 3 EV SSL CA - G3, and that intermediate CA is signed by a CA with the name of VeriSign Class 3 Public Primary Certification Authority - G5.
)
You can follow a chain of certificates, starting with a signed certificate, up to the intermediate CA and ending at the top of the chain. The certificate chain ends with a CA that signs its own certificate, which is called a “root CA.” It is not required to have an intermediate CA involved—you could simply have a root CA sign your certificate—but in practice, an intermediate CA is often involved.
How do you know if you can trust a CA? After all, since a root CA has signed its own SSL certificate, this effectively means that the organization in control of a root CA simply asserts that you should trust that it is who it claims to be.
The answer is that trust has to start somewhere. In OS X and iOS, Apple includes a collection of root and intermediate CAs that Apple has determined are worthy of trust (see the Apple Root Certificate Program page on the Apple site for the acceptance process: www.apple.com/certificateauthority/ca_program.html). Out of the box, your Mac computers and iOS devices are configured to trust those CAs. By extension, your Mac computers and iOS devices also trust any certificate or intermediate CA whose certificate chain ends with one of these CAs. In OS X, these trusted CAs are stored in the System Roots keychain. (See Lesson 8, “Keychain Management,” in Apple Pro Training Series: OS X Support Essentials 10.10 for more information about the various keychains in OS X.) You can use Keychain Access to view this collection of trusted root CAs. Open Keychain Access (in the Utilities folder). In the upper-left Keychains column, click System Roots. Note that in the following figure the bottom of the window states that there are more than 200 trusted CAs or intermediate CAs by default in Yosemite.
)
In Lesson 8 “Configuring Open Directory Services”, you will learn that when you configure your server as an Open Directory master, the Server app automatically creates a new CA and a new intermediate CA and uses the intermediate CA to sign a new SSL certificate with your server’s host name as the common name (the Common Name value is part of what identifies the certificate holder). It is recommended that if you haven’t engaged a widely trusted CA to sign an SSL certificate for your server, you should use the SSL certificate signed by your Open Directory intermediate CA; in Lesson 10 “Configuring OS X Server to Provide Device Management”, you will learn how to use the Trust Profile to configure your iOS devices and OS X computers to trust your Open Directory CA and, by extension, the intermediate CA and the new SSL certificate.
But what about computers and devices that are outside your control and that you cannot configure? When people use computers and devices that are not configured to trust your server’s self-signed SSL certificate or your server’s Open Directory CA or intermediate CA and they try to securely access services on your server, they will still see a message that the identity of your server cannot be verified.
One way to prove your identity is for your server to use an SSL certificate that’s signed by a CA that most computers and devices are configured to trust or trust inherently.
Deciding What Kind of Certificate to Use
Before going through the process of getting a widely trusted CA to sign a certificate for you, consider the services you’ll use with the certificate, as well as the computers and devices that will access those services.
If you use a self-signed certificate, there is no additional server configuration to install the certificate on your server, but you do need to configure each client to trust that self-signed certificate. For a Mac client, this involves not only distributing the certificate to the Mac and adding it to the System keychain but also configuring how the operating system (OS) will trust the certificate.
If you use a certificate signed by a widely trusted CA, you need to generate a certificate signing request (CSR), submit the CSR to a CA, and then import the signed certificate.
Of course, it is possible to use a mix of certificates for different services; if your Websites service responds to multiple host names, you’d want a certificate for each host name that you use for web services secured by SSL.
In all cases, you need to configure your server’s services to use the appropriate certificates.
The next section shows you how to obtain a certificate that’s signed by a widely trusted CA so that you can use it to prove the identity of your server and to encrypt communications between your server and the users of your server’s services.