Of the many marvelous Calvin and Hobbes cartoons by Bill Watterson, one of the most marvelous (and memorable) is The Horrendous Space Kablooie. Quoth Calvin, “That’s the whole problem with science. You’ve got a bunch of empiricists trying to describe things of unimaginable wonder.”
I feel the same way about X.509, the name of the international standard defining public key certificates. X.509? It’s sort of hard to take that seriously — “X.509” feels better suited as the name of an errant asteroid or perhaps a chemical formula for hair restoration.
But I digress. X.509 digital certificates are exchanged when you create a “secure” connection on the Internet, for example when you read your webmail using HTTPS. The exchange happens something like this:
- Your computer: Hi, I’m a client.
- Webmail server: Howdy, I’m a server. Here’s my X.509 certificate, including the public key you’ll use in the next step.
- Your computer: Fabulous. I’ve calculated new cryptographic information that we’ll use for this session, and I’ve encrypted it using your public key; here it is.
- (Further traffic is encrypted using the session cryptographic information.)
Several things happen behind the scenes to provide you with security:
- Your computer authenticates the X.509 certificate(s) provided by the server. It checks that the server uses the expected web address. It also verifies that a trusted third party vouches for the certificate (by checking the digital signature included in the certificate).
- Your computer verifies that there is no “man in the middle” attack in progress. It does this by ensuring that the server has the private key associated with its certificate. It does this by encrypting the session cryptographic information with the server’s public key. If the server didn’t have the private key then it wouldn’t be able to encrypt and decrypt any further traffic.
Unfortunately the system isn’t perfect. The folks who programmed your web browser included a set of trusted root certificates with the browser. Those root certificates were issued by well-known certificate authorities [CAs] such as Verisign and RSA. If an attacker breaches security at either a root CA or an intermediate CA, as happened with the 2011 Comodo and DigiNotar attacks, then an attacker could silently insert himself into your “secure” connection. Yikes! Efforts like HTTPS Everywhere and Convergence are trying to address this problem.
Public-key cryptography is pretty neat. When you use public-key cryptography you generate two keys, a public key (okay to give out to everyone) and a private key (not okay). You can use the keys in two separate ways:
- When someone wants to send you a private message, they can encrypt it using your public key. The encrypted message can only be decrypted using your private key.
- When you want to publish a message, you can encrypt (sign) it using your private key. Anyone who has your public key can decrypt (validate) your message.
In a public key infrastructure, a root CA (say, Verisign) uses its private key to sign the public-key certificates of intermediate certificate authorities (say, Thawte). The intermediate CAs then use their private key to sign the public-key certificates of their customers (say, www.google.com). When you visit Google’s site using HTTPS, Google provides you both their certificate and Thawte’s certificate. (The chained relationship Verisign-Thawte-Google is sometimes called the “chain of trust”.) Your browser uses the certificates provided by Google, plus the Verisign root certificate (bundled with the browser), to verify that the chain of trust is unbroken.
[I use Google as the example here, since you can visit https://www.google.com and configure your browser to show the certificates that Google provides. However, I have no knowledge of Google’s contractual relationship with Thawte. My assertions below about Google are speculative, but the overall example is valid.]
Recently I was asked “We have been trying to understand Certificate Chaining and Self Signing. Would a company [like Google] be allowed to purchase one certificate from a Certificate issuer like Verisign and then issue its own signed additional certificates for additional use?”
Great question! (Where “great question” is defined as “um, I don’t know, let me check into that.”) It turns out the answer is no, a company’s certificate(s) cannot be used to sign other certificates.
Using Google as an example, the principal reason is that neither Verisign nor Thawte let Google act as an “intermediate certificate authority.” It’s (1) likely against the license agreement under which Thawte signed Google’s certificate, and (2) prohibited by metadata fields inside both Thawte’s certificate and Google’s certificate:
- Google’s certificate is prohibited from signing other ones because of a flag inside the certificate metadata. (Specifically, their Version 3 certificate has an Extension called Certificate Basic Constraints that has a flag Is not a Certificate Authority.) And Google can’t modify their certificate to change this flag, because then signature validation would fail (your browser would detect that Google’s modified certificate doesn’t match the original certificate that Thawte signed).
- Certificates signed by Thawte’s certificate cannot be used as Certificate Authorities (CAs) because of a flag inside Thawte’s certificate. (Specifically, their Version 3 certificate has an Extension called Certificate Basic Constraints that has an field Maximum number of intermediate CAs that’s set to zero, meaning that no verification program should accept any certificates that we signed using their key.)
If your company needs to issue its own signed certificates, for example to protect your internal servers, it’s relatively easy to do. All you have to do is run a program that generates a root certificate. You would then be like Verisign in that you could issue and sign as many other certificates as you wanted. (The down side of your “private PKI” is that none of your users’ browsers would initially recognize your root certificate as a valid certificate. For example, anyone surfing to a web page protected by certificates you signed would get a big warning page every time, at least until they imported your root certificate’s signature to their trusted-certificates list.)
The article I found most helpful in digging up this answer is here:
http://unitstep.net/blog/2009/03/16/using-the-basic-constraints-extension-in-x509-v3-certificates-for-intermediate-cas/
(The full name of the X.509 standard is the far worse ITU-T Recommendation X.509: Information technology – Open systems interconnection – The Directory: Public-key and attribute certificate frameworks. One name with four hyphens, two colons, and the hyphenated equivalent of comma splicing? Clearly rigorous scientific work.)