I’ve got a small infrastructure. I think, all told, I deal with something like 3 or 4 SSL certificates, maximum. Probably less. This means that I don’t deal with them very often, and last night was my first time dealing with intermediate certificates. Ye gods.
A quick introduction to how SSL certificates work may be in order…
First, SSL certificates deal with public key cryptography and key pairs. There is a private key that remains protected, and is used to create a public “certificate”, and can be used to “sign” (in other words, vouch for) other certificates.
Secure Socket Layers is all about trust. Making sure that the website you’re visiting is REALLY the website you want to visit is important on lots of occasions. The way SSL does this is by having an organization that you trust vouch for an organization that you’re not sure about.
Your web browser comes out of the box with several trusted certificates. These are the public certificates from Signing Authorities (SAs) that are trusted because…well, usually because they’ve spent a lot of money to put themselves in a position where they’re trusted.
The benefit of having these pre-existing trusted certificates means that whenever the private key owned by the trusted SA signs someone else’s certificate, your browser trusts that certificate, too.
If I, as standalone-sysadmin.com, created a certificate and presented it to your browser, your browser wouldn’t trust it. Why should it? Anyone can generate their own certificate. In order to have your browser trust my certificate, I have to get it signed by a CA that your browser trusts. Once that happens, then your browser will see “oh, this is his certificate, and it’s vouched for by someone I know, so I’m going to trust it”.
Back in the good old days (or at least before a year or two ago), Certificate Authorities (CAs) just used their root key to sign certs. This had the benefit of simplicity…the same key that generated the public root certificate pre-installed into your browser also signed the certificate being presented to it. Then things got more complex…
See, the benefit of root key signing was also the risk. Since a root key was trusted implicitly, if that key was compromised, it could be used to sign ANY certificate, and malicious people could present seemingly identical sites to unsuspecting people. It’s sort of like the equivalent of stealing the printing press and paper to counterfeit money.
The most likely way that the root key would become compromised is during the signing process. Since every certificate needed signed by the root key, the root key needed to be everywhere signing took place. The volume of certificates that get churned out by some of these CAs is huge, which meant that one hole in the system anywhere could be exploited to cause the whole system to come crashing down.
In order to avoid this problem, what CAs have implemented are “intermediate certificates”, which alleviate the necessity of keeping the root key around by creating “certificate chains“. The root key still creates the public certificate installed in your browser, but it no longer signs the certificates presented by web servers. Instead, the signed certificates refer to the intermediate certificate, and the intermediate certificate refers to the root key.
This picture from IBM does it much more justice than I can:
The problem for us is that the browsers don’t inherently know anything about the certificate chain…so we have to configure our web servers to present the entire chain of certificates. To facilitate this, lots of CAs have provided ready-made certificate chains in .pem files. I use Thawte, and you can get their intermediate bundles from here. Essentially, it’s just a text file:
$ cat SSL_PrimaryCA.pem -----BEGIN CERTIFICATE----- MIIERTCCA66gAwIBAgIQM2VQCHmtc+IwueAdDX+skTANBgkqhkiG9w0BAQUFADCB zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQk