SSL Certificates
Overview
Secure Sockets Layer (now superceded by the Transport Layer Security (TLS) although you still use SSL certificates) is a means by which two parties can exchange information with a reasonable degree of confidence that no-one can eavesdrop on that conversation.
A common transaction would be the supply of credit card details to an online merchant. The merchant presents their SSL certificate, you authenticate it as valid then using it you negotiate a secure channel for the duration of your conversation.
OpenSSL is an open source implementation of the standards.
PKI Systems
An SSL certificate is the fancy name for the public key part of a public key infrastructure (PKI) key-pair. PKI systems all involve the (future) certificate owner generating two matched prime numbers. One they keep very safe (their private key) the other they make as public as possible (their public key). The PKI system allows for the secure communication between the holders of the two keys. Anyone with the public key can decrypt a message encoded with the private key (which, whilst not obviously secure allows the receiver to verify the sender). Only the owner of the private key can decrypt a message encoded by the public key (no surety of sender but the sender can be sure only the intended recipient can decode the message).
SSL Certificates
SSL certificates are the public key part of a PKI key pair, then. Well, not quite. Just because someone generated two numbers and gave one of them to us doesn't (shouldn't!) make us believe they are who they say they are. Certificates have another attribute, an issuer. The issuer is someone we (mutually?) trust who has made some effort to verify that the person who generated the numbers is who they say they are and, to recognise this, the issuer signs the public key of the generator.
The issuer signs the public key with their own private key for which we have in our hands the public part (itself in the form of an SSL certificate). Using this public key we can verify that the signature of the issuer is genuine and therefore, since we trust the issuer, then the original generator must themselves be who they claim to be.
There's been a sleight of hand in there. How have we come to trust the issuer? Well, there's the rub, we just do. However, once we trust an original issuer we can have a veritable chain of trusts so long as we have all the duly signed public keys.
From a technical point of view, there's a small problem with our issuer's certificate. Who has signed it and therefore don't we want that signing certificate in turn? The get out clause of this otherwise intractable problem is that our issuer has given us a self-signed certificate. And we just believe them!
Cetificate Details
An SSL certificate isn't just a few numbers, it's more than that. It is a set of attributes (whose numbers should add up!) including some more practical bits of information. In particular it has some textual information pertaining to the generator and the issuer. In both cases the idea should be that you have some human readable information that will help you decide whether or not to trust either generator or issuer if there is any doubt.
For SSL certificates the generator will include a CN field (from the OSI/LDAP terminology for Common Name) which, for a web site, should match exactly the domain name of the URL you're trying to talk to. That is to say, if you contact https://foo.example.com your browser will shout a warning at you if the certificate presented does not have a Common Name attribute of foo.example.com. Thus, you can quickly determine that bar.example.com, example.com and stealing.your.cash are all invalid SSL certificates for that URL.
As it happens, there are two variations on the theme of the Common Name attribute. You can have wildcard certificates where the Common Name is a wildcard, *.example.com, say, and it accepted for all domain names matching the wildcard. A more interesting variant is Subject Alternate Name (or SAN) certificates which populate a different attribute with a number of different domain names, www.example.com and www.example.net, say. This second variant is particularly useful if you are hosting several different domain names on the one server and a wildcard certificate will not cover them all -- .com and .net are separate top-level domains, for example.
SSL Terminology
There are some grander terms to get used to when dealing with SSL certificates:
- subject
- The generator of the SSL certificate
- self-signed certificate
A special 'root of the tree' certificate where the entity who has signed the certificate is the entity themselves. Obviously, these are all or nothing in the sense that we either trust them or the whole system collapses.
Not that you should trust every self-signed certificate that comes your way. We'll be generating our own self-signed certificate later and if that isn't evidence enough that anyone can do it then nothing is! At some point, however, some self-signed certificate must be trusted.
- CA
- A Certification Authority is the fancy name for the issuer in the description above, ie. the signer of certificates. They're the entity we're supposed to trust and we will have a self-signed certificate from them in our hands.
- CA Certificate
- Is the self-signed certificate of the CA.
- x509
- X.509 is the standard for the format of SSL certificates.
- CSR
- A Certificate Signing Request is an interim document that the subject creates to be passed to the CA for signing. The CA will return the signed SSL certificate.
SSL Transactions
With all these PKI keys floating around, what actually happens when you 'do' SSL? In essence the flashy PKI keys (which are cryptographically very strong using 768 or 1024 or more 'bits') are used to generate a session key (of a rather more humble 56 or 128 bits) which is what you use to actually encrypt the traffic for your transaction.
The reasoning is thus: the heavyweight SSL certificate keys make traffic very secure (longer than the lifetime of the universe to break, etc.) but they're very computationally intense. Everything would be very slow if we used them all the time. However, if we just use them at the start of the session to agree upon a lighter weight session key then things are much better. No-one can see us trading the session key, the session key is 'good enough' for what will be only a few packets popping backwards and forwards (and would still require half the computers on the planet a couple of days to break) but cost very little computationally. Everybody's happy.
Why 56 or 128 bits for the session key? Well, there's a question. US government export restrictions kept the world on 56 bits for a long time before grudgingly everything was allowed to shift up to 128 bits. Presumably, session keys will migrate to more bits as computers become more powerful.
Bootstrapping The System
So how do we get started? Who decides who's trustworthy? Good questions. Take your browser for instance. Someone somewhere has made a decision that these (thirty or forty) CAs are trustworthy and they will install those CAs into the browser. So long as all the SSL certificates you subsequently see are signed by one of those CAs then (assuming you trust the people who gave you your browser) everybody's happy.
Problems start if those initial CAs are either wrong, incomplete or malicious.
June 2010 Update
These words of wisdom were originally penned in December 2005 and it's not until April 2010 that the first widespread concern was raised about the reliability of the built-in browser CAs.
Document Actions