SSL Certificates Made Simple

What Is An SSL Certificate?

SSL certificate is just specific data that is formatted in a specific way. Because this data is used, among other things, to certify web site identities, it is called a certificate.

How Do Certificates Verify a Site?

SSL certificates can be complex because they are used to certify many different things. This document attempts to explain in simple terms how certificates are used to verify websites (HTTPS) and email (STARTTLS). More formal descriptions of how all this works are available elsewhere.

For our purposes, an SSL certificate is just an ID badge. It says identifies that a website (or email server) is legitimate, meaning the site is who it says it is.

When you browse a website, the site sends its end user certificate along with the webpages. It’s then up to your browser to decide if the ID (certificate) is real and matches the website you were expecting.

Certificates can contain all kinds of data. Think of it like an IRS tax form with lots of lines that could be filled in. There is a strict format for the data in the certificate, but not all the fields need to be there. When used to verify a website, two sections inside a certificate are used: the Subject and the Signature. The Subject identifies the organization who purportedly owns the certificate, and it includes data like name and address. The Signature is binary code that verifies of all the data in the certificate; think of it as an immutable copy of everything. If the Signature matches the all the data, then the browser knows that the Subject is valid. Then if the Subject matches who the browser was expecting, the browser knows the site is good.

How does the Signature keep a copy of everything? It doesn’t keep an exact copy but instead keeps a hash of everything. A hash is just a math trick that makes data smaller. The browser checks that the certificate data has not been altered by doing its own hash. If the Signature hash matches the browser’s hash, the browser knows the Subject is good.

How do we know the Signature has not been tampered with? The Signature is protected from alteration because it is encrypted with a Private Key (more about keys below). The browser has a matching Public Key that it uses to decrypt the Signature. If the Public Key can decode the Signature, then the browser knows the Signature is good.

Where does the browser get this matching Public Key? Another field inside a certificate is the Issuer, which is who created the Signature. The browser uses the Issuer to find a matching certificate in its Trusted Root Store. The matching certificate contains the Public Key that decrypts the Signature. If the browser finds the Issuer’s certificate in its Trusted Root Store, it knows the Public Key is good.

Every computer that verifies certificates has its own Trusted Root Store that contains certificates from all the reputable Certificate Authorities (CA) that it trusts.

How do Public and Private keys protect data from being altered? These keys are parts of Public Key Infrastructure (PKI), and they are used to encrypt information. Something encrypted with a private key can only be decrypted with the corresponding public key, and vice versa. As long as each side of a conversation only knows one of the two keys, both sides can be sure that the other side really sent the information – because whatever they decrypt with one key could only have been encrypted by the other key.

Note that certificate PKI is only used for identification and is NOT what is used to encrypt SSL/TLS data, for example secure (HTTPS) websites.

To help the above explanation make sense, let’s take it from the other direction, starting with the Trusted Root Store.

The Trusted Root Store contains certificates for every Certificate Authority that is trusted. Microsoft keeps Trusted Root Stores updated as part of Windows Update. Linux systems do the same with their update process, and vendors of other devices that use certificates use their patch/update process.

A certificate from the Trusted Root Store has Subject and Public Key sections. The Subject section of the root certificate matches the Issuer section of any certificate that the root certificate has signed. Using the Public Key from the root certificate, a browser decrypts the Signature on the signed certificate, recovering the original hash that the Certificate Authority used to “keep a copy” of the signed certificate.

The Certificate Authority’s certificate is trusted because it came from the Trusted Root Store. The Signature on a signed certificate is trusted because it is decrypted using the Public Key from this trusted root certificate, meaning the Signature could only have come from the CA and the Signature has not been altered. The contents of the signed certificate are trusted because the original hash from the CA matches a new hash of the contents.

Going back and following the chain from end user to trusted root:

The end certificate is trusted because it is signed. The signed certificate has not been altered because it matches the copy made by the signing certificate. The copy has not been altered because it was made by and encrypted by the owner of the signing certificate (the CA). The signing certificate is valid because it came from the host’s Trusted Root Store. The end certificate is therefore vouched-for by the CA and has not been tampered with.

It is these CAs that make the whole certificate system work. When a client wants to get a signed certificate from a CA, the client sends a Certificate Signing Request (CSR) to the CA. A Certificate Signing Request is basically an unsigned certificate. The CA adds its identification (the Issuer) and a Signature to the CSR to make the signed certificate. To “sign” a certificate, a reputable CA does these things:

Example Certificates

All certificates look like this: -----BEGIN CERTIFICATE----- MIIGkDCCBXigAwIBAgIIapaVPVWFWIQwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNV ...lines deleted... Amv4tYsi/LxOGaCoz/AxVClEC/TTSR62xLvf/Mj7BBGbOvOI7rDGBjPHt75TmmTn BrH0IA== -----END CERTIFICATE-----

The CheckTLS end user certificate: view

A GoDaddy trusted root certificate: view

Intermediate Certificates

What Is An Intermediate Certificate?

As the number of websites went from thousands to millions to over a billion, the popular CAs realized that their root certificates were not scaling well. Think of a root certificate as the trunk of a tree, and all the certificates they signed were leaves coming straight off the trunk.

Root certificates are just one of many certificate types. They are allowed to sign other certificates, but they are not the only kind of certificate that can sign other certificates. Staying with the tree design, CAs began issuing Intermediate Certificates that act like branches on a tree. The trunk, or root certificate, signs branch, or intermediate certificates, which in turn sign leaves, or end user certificates.

So how does the above discussion about certificates work when there are Intermediate Certificates involved? Think of intermediate certificates as links in a chain that reaches from the end user certificate to a trusted root certificate. The end user certificate is signed by an intermediate certificate, which is signed by either another intermediate certificate or a trusted root certificate.

Each link in the chain is signed by the next higher link. The Signature in a lower certificate verifies the contents of that certificate, and the Public Key of the next higher link verifies the Signature.

The links in a three or more link chain work just like the links in a two link (end user and root) chain described above. But where do the middle links come from? Recall that the lowest certificate in a certificate chain comes directly from the website (or email server). And the trusted root certificate comes from a Trusted Root Store on the user’s computer.

Do You Need An Intermediate Certificate?

When you ask a CA to sign your CSR (see above), the CA will send back your signed certificate and all the intermediate certificates needed to connect the end user certificate to the CA’s trusted root certificate. Note the CA may send a link to the intermediate certificates, send them in a separate bundle, or send them already bundled with the end user certificate.

If you test your website with CheckTLS’s //email/testTo: ("TestReceiver") test and you get messages like this:
Cert VALIDATION ERROR(S): unable to get local issuer certificate
Then you need one or more intermediate certificates.

How Do You Use An Intermediate Certificate?

Intermediate certificates are very easy to use. Despite that, many of the email problems we see at CheckTLS come down to missing intermediate certificates.

Intermediate certificates must come from one of the two ends of a certificate chain: either the end user certificate from the website or the Trusted Root Store on the user’s computer. Obviously there is no way for every CA to load all their intermediate certificates into the Trust Store in every computer, and router, and phone, etc.

Intermediate certificates come from the end user. When a browser connects to a website, the website sends its end user certificate and all the intermediate certificates needed to make a secure trust chain a trusted root certificate.

So how do you tell a webserver (or email server) to send the intermediate certificates along with the end user certificate? That depends on what server software you are using, but in most cases you just add the intermediate certificate text to the same file where your end user certificate text is kept. A certificate file with an end user certificate and one or more intermediate certificates will look like: -----BEGIN CERTIFICATE----- MIIGkDCCBXigAwIBAgIIapaVPVWFWIQwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNV ...lines deleted... Amv4tYsi/LxOGaCoz/AxVClEC/TTSR62xLvf/Mj7BBGbOvOI7rDGBjPHt75TmmTn BrH0IA== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx ...lines deleted... LXY2JtwE65/3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEfTCCA2WgAwIBAgIDG+cVMA0GCSqGSIb3DQEBCwUAMGMxCzAJBgNVBAYTAlVT ...lines deleted... qm5vjLyb4lddJIGvl5echK1srDdMZvNhkREg5L4wn3qkKQmw4TRfZHcYQFHfjDCm rw== -----END CERTIFICATE-----

Some servers have a separate spot for intermediate certificates, so just put the intermediate server text there. Many of those will still work if you just combine all the certificate texts into the end user certificate file and leave the separate spot empty.