This is an attempt to explain how certificates and keys are used for security. I’ll write elsewhere about how to do practical things like view and manipulate certificates. Where I talk about a browser talking to a server, the browser could just as equally be some other application like a secure FTP client or something.

If there’s anything that you think should be covered in this page, drop me an email and I’ll write something about it (if I know anything about it!)

Keys

SSL uses key pairs. A secure server will have a private and a public key, which it uses to encrypt and decrypt data. It must never give the private key away, but it can give the public key to anyone (and does so as part of its certificate, shown later). The keys have two uses: encrypting messages so that the contents can’t be read in transit, and signing messages so the recipient can be sure that they are talking to the intended machine.

Certificates

Certificates are used as a chain of trust; when you connect to an HTTPS server, the server will show its certificate to the browser. All certificates have an issuer, which is some other party who created and signed it (known as a Certificate Authority or CA). The CA will have their own certificate identifying them. All browsers have a collection of built-in issuer certificates that they trust implicitly; these are called Root CAs. An example is Verisign CA. If a server presents a certificate signed as being issued by Verisign CA, the browser can trust the certificate for this site and continue without warning the user.

Not all certificates have to be issued directly by a root CA. You could get a certificate from another CA, which in turn was issued from a root CA. As long as the server presents both certificates to the client, it can form the chain of 3 certificates and know to trust the server. A certificate authority between you and the root CA is known as an Intermediate CA.

There can be more than one intermediate CA; as long as there is a single unbroken chain from the server’s certificate to the root CA certificate, the client can still trust it.

Clients can also choose to trust any certificate they like. For example, Websignon has the TestSSO CA certificate in its trusted list because we want it to trust our test services for the purpose of signing in.

Untrusted certificates

When you get a warning in your browser saying that a certificate is untrusted, it’s generally one of two things:

• The certificate was genuinely issued by an untrusted issuer (such as our TestSSO CA which we use on some test machines)
• The certificate was issued by a trusted intermediate CA, but the intermediate certificate wasn’t supplied by the server

The former is intended behaviour, but in the latter case it’s a sign that the server hasn’t been set up correctly.

Keystores

Keystores are just Java’s format for storing keys and certificates. It can hold any number of key entries and certificates, though typically you will have one key entry for your server, plus certificates for any intermediate CAs.

Java’s trusted list is called the cacerts file, which is just another keystore containing a few dozen CA certificates. You can add more certificates to this file, and all Java applications will then trust those certificates by default. It’s also possible to choose a different cacerts file when you start a Java application, using the system property javax.net.ssl.trustStore. It’s better to add certificates to a copy of cacerts and use that for the specific application that needs it, so that you don’t accidentally affect other Java applications.

Glossary

• CA – Certification Authority. Some entity with the authority to issue certificates to others
• Root CA – A CA at the top of a chain, which a browser implicitly trusts
• Intermediate CA – A CA in the middle of the chain, which the server must show to the client

Certificate types

The various certificate types hold much the same data but encoded quite differently.

PEM is a text format, recognisable by being a big block of letters and numbers, with “BEGIN CERTIFICATE” and “END CERTIFICATE” at either end. The begin and end lines are part of the certificate so make sure you keep these when copying certificates.

DER is a binary format, used occasionally.

You will probably use PEM most of the time.