An X.509 certificate is something that can be used in software to both:
- Verify a person’s identity so you can be sure that the person really is who they say they are.
- Send the person who owns the certificate encrypted data that only they will be able to decrypt and read.
To be fair, X.509 certificates can be used to do these things for more than just people – they’re heavily used by software applications or computers to do this amongst themselves as well. Anyway, just keep in mind when I say ‘person’ in this article, it can mean any of these.
Let’s look at these two use cases a little more closely.
So we’ve said that an X.509 certificate can be used to verify a person’s identity so you can trust that they really are who they say they are.
In this use case, you can think of an X.509 certificate as similar to a national passport. And as with national passports, you are very careful about who would ever have access to it – you would never give your passport away to anyone else. It uniquely identifies you and only you. Because of this uniqueness, the government uses passports to verify who you are – you present it as a way of proving that you are a citizen of your country.
X.509 certificates act kind of like a digital passport of sorts – it contains information about you and only you. And just as a national government acts as an authority for issuing and validating passports, something similar, called a Certificate Authority (CA), exists for X.509 certificates.
A Certificate Authority is a 3rd party trusted by both you and anyone who might verify your identity. That is, when you use your X.509 certificate with someone who needs to verify your identity, you both trust that a certain Certificate Authority has validated your identity. Because the 3rd party trusts that the CA verified you, they in turn trust that your X.509 certificate really represents you and only you.
There are well-known global and public Certificate Authorities, such as Verisign and Digicert. But a Certificate Authority can also be any party that both you and the person verifying you agree to as trusted. Many companies have their own private Certificate Authorities used to verify employee identities, for example.
In addition to verifying your identity, X.509 certificates can also be used to secure data intended for you so that prying eyes won’t be able to see it. It does this via a mathematical concept known as asymmetric key cryptography.
Asymmetric means, well, not symmetric of course, but for the purpose of this discussion, it helps to think of asymmetric as ‘not equal or similar’. A key in this case is what you would think it would be – something used to lock or unlock a protective barrier. So when put together, asymmetric key cryptography basically means that one key is used to lock up data, but an entirely different key is used to unlock the data.
Asymmetric Key cryptography is also known as Public/Private Key cryptography for this reason: one of the two asymmetric keys can be freely given out to the world at large; anyone can see and use it, which is why it is called the ‘public’ key. The other of the two keys however must remain totally private to you, so no one will ever see it or be able to use it. This is naturally called the ‘private’ key because it should remain private always.
The reason Public/Private Key cryptography works is that data locked by the public key can only be unlocked by the private key and vice versa. If someone locks data with the public key, no one else who has the public key can unlock it – not even the person that originally locked it. Only the person with the private key can unlock the data. That is why the public key can be given to and seen by anyone. As long as the private key remains safe, you can rest assured the data is locked safely.
So if we had a public and private key, how would they be used?
As an example, let’s say your bank wants to send you your bank account balance. Naturally this is very sensitive information that should be for your eyes only. The bank can use your public key to encrypt your bank account balance. The encrypted data can be safely emailed directly to you (maybe as a file attachment), because it is all ‘jumbled up’ and no one can make sense of it (remember that public keys can not unlock data that was previously locked with the same public key).
Because your private key is the only thing that can ‘un’ encrypt (aka ‘decrypt’) the bank’s email, you can use your private key to unlock the attached file and see your bank account balance. Because no one else should ever have your private key, you can rest assured that you’re the only one who can see your bank account balance.
Ok, great – we now know about asymmetric (public/private) key cryptography. What does that have to do with X.509 certificates? Well, an X.509 certificate is composed of two chunks of information:
- Your identifying information, such as your name and maybe address
- Your public key
As you can see, your public key is included in the X.509 certificate. This way, anyone who gets your certificate can both verify your identity (via a Certificate Authority) and encrypt data ‘for your eyes only’ with the included public key.
Now that we’ve seen the benefits of having an X.509 certificate, how do you get one?
Anyone can create their own X.509 certificate. Just know that until it is verified by a Certificate Authority (like Digicert or Verisign or your company’s own CA), most people won’t trust it or use it. But we can list the process of creating your own and having a CA verify it.
Here is the high level overview of how one would create a validated X.509 certificate:
- Using a cryptographic software tool (such as OpenSSL, the Java
keytool, etc), a user generates a cryptographic public/private key pair and of course keeps the private key very secret (known to himself only).
- Using their software tool, the user’s public key and an X.500 hierarchical name identity, called a ‘Distinguished Name’ are bundled up together into an intermediate file called a certificate. This certificate is not considered a valid X.509 certificate yet. We’ll get to that.
- The user then encrypts this certificate using their private key which results in a new file called a ‘Certificate Signing Request’ or CSR. If you look inside this file, you’ll see —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—– lines sandwiching a Base 64-encoded blob.
- The user then submits this CSR file to a Certificate Authority (Digicert, Verisign, etc) along with his public key (so the CA knows how to decrypt the CSR).
- The CA decrypts the CSR using the user’s public key which results in the intermediate certificate from step #2 that contains the user’s Distinguished Name and the user’s public key.
- The CA verifies the identity of the user associated with the CSR. They will ask for faxed identification of some sort – a national ID, a driver’s license, passport, etc.
- Once the CA is happy that they have verified the user’s identity, they take the intermediate certificate and encrypt it with their own private key – which results in a new file. If you look inside this file, you’ll see —–BEGIN CERTIFICATE —– and —–END CERTIFICATE—– lines sandwiching a Base 64-encoded blob. This file is what is known a valid X.509 certificate.
- The CA sends this newly created X.509 certificate back to the person who was verified.
After this final step, the user has their validated X.509 certificate that they can use as necessary.