The anatomy of certificates

So, let's talk about certificates. 

In our ongoing series on security fundamentals, we have discussed the need to verify the identity of someone’s primary key.
In discussing public and private keys, you recall that we showed that a message encrypted with a user’s public key and associated with a message digest results in a ‘tamperproof’ – or digitally signed  document that cannot be altered by any third party.
Certificates are an example of such a document. They are intended to ‘prove’ certain claims about a user or entity.
Normally, the most important claim about a user is that their public key is a specific key. Because the issuer of the certificate is implicitly trusted, by following the ‘chain of trust’, a third party can independently verify the identity and public key of another entity.
In the discussion that follows, I have kept things simple – but be aware that certificate and certificate management can be a complex topic, so this is only a quick introduction.

Certificates and certificate stores

It is common to store multiple certificates in a certificate store on a computer. There is no requirement that there be a specific single certificate store – and in fact, there are often multiple stores.
For example, on Windows, there is a built-in certificate store. You access this store using either the certmgr.msc utility, to view certificates associated with the current user, or, more generally, by running the mmc.exe utility and then adding the certificate snapin. This option allows you to choose between viewing the certificates associated with the current user or the certificates associated with the local computer account.  These certificates are intended to be shared by all users who log on to that machine.
However, the Windows certificate store is just a convenience. Some software on Windows does not use the Windows cert store. For example, although the Chrome, Edge and Internet Explorer browsers use the Windows Store, Firefox has its own certificate store.
Java applications use an associated utility to manage certificates in so-called key stores which exist as normal files.
You can see therefore that certificates can be scattered around in multiple locations.

Anatomy of a certificate

The exact content of a certificate varies depending on the purpose of the certificate. Let’s take a closer look at a certificate inside the Windows cert store.
We’ll start by looking at all the user certificates in the Trusted Root Certificate location in the store. Trusted Root Certificates are those certificates whose issuer's we implicitly trust. We can add any certificate to this list or remove one if we want.
You can see here that there are some key fields.
Issued to indicates the ‘subject’ of the certificate – you can see that in most cases this is the same entity, or a similar entity, to the entity who issued the certificate (i.e the issued by field)
Expiration date. This is when the certificate ceases to be valid. Note that certificates expire without warning and this has led to many a production system going down unexpectedly. You should proactively manage certificate lifetimes to avoid this.
Intended purposes. One or more purposes for which the certificate is valid. You can see here that purposes can include validating a server or client name, or code signing (i.e, allowing you to use this certificate to stamp your identity on software that you create), and so on.

Certificate details

If we look at the detail associated with one of these certificates, we see

Note that the certificate is not just valid TO a given date, it is invalid BEFORE a specified date as well, so you can have certificates that are valid only at some future point in time.
We see here that the public key of the issuer is contained in the certificate. Recall that the certificate is digitally signed. Because this certificate is stored in the trusted root part of the certificate store, any software retrieving this certificate can be confident that we trust the issuer. Also, we have the public key of the issuer. We can be confident that this is the correct public key because we trust the certificate.

The chain of trust

Certificates are associated with a ‘certification path’ or ‘chain of trust’. Here we see a certificate issued by Microsoft whose chain of trust involves two other certificates. At the top of the chain, we will have a trusted root certificate. Because we can trace a chain of trust to the trusted root, we can, therefore, trust the certificate itself. In this case, the certificate is shown with a little red X because its ‘valid to’ date has expired. Therefore on this system, the certificate is invalid because of this.

Self-signed certificates

You do not have to have a trust chain associated with a certificate. It is common, particularly in test environments, to create so-called ‘self-signed’ certificates. These certificates are created and placed in the certificate store just like any other certificate. However, there is no chain of trust associated with them so we cannot be confident about any assertion the certificate makes.
Nonetheless, in test environments this often is not important, hence, we can set up one or more self-signed certificates and use them just like any other certificate. It is common for software to warn when such a certificate is used, as a protective measure.
Note that if you place a self-signed certificate in the trusted root path in the certificate store, then it IS trusted. Therefore you have to be careful about the certificates that get placed in this path.
The misuse of certificates in the trusted root path has led to some significant security vulnerabilities. For example, Lenovo included a trusted root certificate associated with SuperFish, inc. in order to implement targeted advertising to users. Unfortunately, this exposed users to a significant security vulnerability, as you can see in the discussion here. 

Importing and exporting certificates

You can move certificates around by importing and exporting them. Additionally, it is common for software to request a certificate automatically. This is known as certificate enrollment. Another computer on the network provides a certificate to the requesting software. Normally the software then stores this in the local certificate store so that it will not require a fresh copy next time.
There are lots of standard formats for certificates. You can see some of these when you export a certificate from the Windows cert store.

 
If we select ‘Base-64 encoded X.509’ as our option, we get a little file that looks like this
 
—–BEGIN CERTIFICATE—–
MIIDuDCCAqCgAwIBAgIQDPCOXAgWpa1Cf/DrJxhZ0DANBgkqhkiG9w0BAQUFADBI
… and so on
 
As you can see, although it looks like gibberish, it’s in a format that other software that wants to read the certificate can understand, so we can now send this file to another machine and turn it back into a certificate inside that machine’s certificate store.

Exporting certificates and private keys

When you export a certificate, it may contain a private key. Obviously, in most cases, trusted root certificates do not include private keys; these, of course, belong to the certificate issuers and are one of the most closely-guarded secrets they have.
However, other certificates, such as self-signed certs, will often have private keys. You get to choose whether the exported copy includes the private key. If it does, then anyone importing that certificate will be able to access the private key and thus they can both encrypt and decrypt messages using the certificate. Otherwise, the certificate will only contain the subject’s public key and thus be used only for verifying the subject’s identity.
You can protect the exported certificate with a ‘passphrase’ so that someone wanting to use the exported certificate must enter the passphrase when they import it.
We hope this introduction has shed some light onto this complex yet important topic.