The joy of certificates - Part 1

We have a big project going into Operation Acceptance Testing and one of the things that the project, in its ∞ wisdom, has decided to leave for the last minute is, to get SSL/TLS working. This would not necessarily be a big problem if it wasn't for the fact that there still are a lot of questions about the application's architecture, in particular with respect to SSL. I won't go into details because I don't want to get into rant mode.

At any rate, there is a lot of FUD regarding cryptography, so I thought I would try to clarify things a little bit, more for my own understanding that anybody else's really.

What is a certificate?

A certificate is generally a public key, which in essence is a very long prime number, normally stored in base 64. Some certificate formats, such as pkcs12, also store the private key, which again is a very long prime number.

Certificates also contain metadata, which might tell you what the certificate has been designed for, e.g. Client or Server authentication, key length, expiration dates and so on. The key thing to remember is that the metadata does not really do anything. It's a bit like a label on some food packaging. The label might say that it has expired but you can chose to eat it.

The take away point is that, the way certificates are dealt with is implementation dependent. Let me repeat it for emphasis (in bold this time), the way certificates are dealt with is implementation dependent. Your browser will complain if you visit a SSL/TLS page that is not signed by a known CA, but your own app can choose not to implement a warning, ditto for expiry dates etc...

To repeat myself, a certificate is a very long prime number (public key) and might also contain another long prime number (private key).

Should we HTTPS?

HTTPS is based on SSL/TLS and its main purpose is two-fold:

1. Ensure the identity of the website being visited.
2. Ensure that browsing is encrypted.

The first is accomplished by a Certification (or Certificate) Authority that signs the server certificate. There is an implied trust on these CAs. In other words, you are assuming that the CA is trustworthy and will only issue legitimate certificates to its legitimate owners, so that if I say to Verisign or Entrust, Can you please issue a certificate for a domain called www.hsbc.co.uk to me manyrootsofallevil? They'll want to make sure that I actually represent HSBC and I'm not just trying it on, so that I can get unsuspecting HSBC customers to provide me with their login details.

Encryption works by using a secret session key. Diffie-Hellman or a similar scheme is normally used to exchange the keys and arrive at this shared, secret, session key that can then be used to symmetrically encrypt the communication or browsing in this case.  There is more to it that this though, as the client and server need to agree on SSL protocol, compression methods, etc.. The whole process is called a SSL or TLS Handshake and at the end of it we end up with a secure communication between a server and a client.

In other words, HTTPS is based on Public Key Infrastructure.

A bit of theory done, we can now look at how this certificate thingy™ works in practice, after all you know what they say:

In theory, there is no difference between theory and practice. In practice, there is.