Certificate management is an important part of a PKI. In this video, you’ll learn about offline CAs, OCSP stapling, certification pinning, trust relationships, certificate chaining, and more.
If you’re managing a certificate authority, one of the things you do not want to have happen is to have someone compromise your CA or any of the keys associated with your CA. That means that any of the keys that may be signed or distributed by that CA would no longer be trusted in your organization.
To limit this type of exposure, we can have some CAs act as online CAs, and others certificate authorities might be offline CAs. We might, for example, want to build out some intermediate CAs, and those CAs are signing the certificates that are used throughout our organization. This means that we can remove our root CA from the network and store that root CA somewhere safely, so that no one has access to the root CA certificates. This means that we could limit the scope of any type of compromise of a single intermediate CA, and we would only have to recreate a new CA and distribute a fraction of all of the total certificates in our environment. This also means that the root CA remains protected, and if we need to create all new intermediate CAs, we have a protected CA that could not have been compromised.
One of the challenges we have when working with certificates is knowing if a certificate may have been revoked. There are different ways to check this revocation status, but one of the easiest ways is through something called OCSP stapling. This is using the online certificate status protocol to be able to determine if a certificate may have been revoked. One of the challenges in using OCSP is we have to constantly check back with the certificate authority to see if this certificate is valid.
It’d be much easier if we were able to make that validation ourselves on a local server. And you can do that by using OCSP stapling. The status information regarding that certificate is stored on the local server, and we effectively staple that particular status into the handshake that normally occurs when SSL or TLS is used when first connecting to a server. Since the status information is digitally signed by the CA, we can trust that it’s valid without having to go all the way to the CA to perform that validation.
Another concern we might have when using digital certificates to something like a web server is really trusting that we’re talking directly to the web server without someone in the middle modifying our conversation. One way to confirm this is to put the certificate inside of the application that you’re using, and then compare that to the certificate that you’re seeing when that application connects to the server. This means that you’ll have to compile the certificate inside of the application that you’re using, or add it the first time that you run the application. This means the application is going to perform a check when it connects to that server. It will see if the certificate that it has internal in the application matches the certificate that it’s seeing on the server. And if those don’t match, the application can decide what to do. It may show an error message on the screen or it may shut down the application and prevent it from running.
If you’re just starting out with a certificate authority, or maybe you’re building one out in a lab, it may only be necessary to have one single certificate authority in your organization. There’s obviously some security concerns associated with that, but if you’re using this on a limited basis, that may be all you need. It’s probably more common for organizations to create a hierarchical structure where you have intermediate CAs and leaf CAs so that you can limit the scope of any type of compromise. This means your users and devices are probably receiving certificates from a leaf CA, which was created from an intermediate CA, and of course, the intermediate CA was created from a root CA. If a security event occurs and a leaf CA is compromised, we would only need to replace the certificates associated with that single leaf CA.
Another model might be to create multiple CAs and create them as a mesh of CAs where every CA trust every other CA. This is probably not a concern if you only have two or three of them, but you can see once you get up to a larger number of certificate authorities becomes very difficult to maintain the scalability across all of them. If you’ve created a certificate in PGP, you’ll notice there is no certificate authority. PGP was created as a web of trust. In a web of trust, you would sign certificates of people you know, and those people would sign certificates of people they know. This means that if you happen to CA certificate from someone you don’t know, but that certificate has been signed by someone you do know, then there is a level of trust. You can associate with that.
And another PKI trust relationship is one that is mutual authentication. This is when you’re validating that the server you’re communicating with is trusted, and the server is also confirming that the client that it’s communicating to is trusted. This means that both sides of the conversation can trust each other, and that ensures that the application that they’re using has an additional level of trust that can be associated with it. There may be cases where you need to have a third party hold on to the decryption keys that are used in your organization. This means that you would hand over your private keys to a third party, and they would only use those keys in particular situations.
For example, you might be storing private information about your employees that is stored in an encrypted form, and you would only be allowed access to that information if it is validated by the third party that has the decryption keys. Obviously, if a third party has control of your decryption keys, there needs to be very specific processes and procedures in place to allow access to that data. You obviously need to be able to trust the third party that you’re using for this key escrow, and you also need to be assured that they’re using the proper security to keep these private keys safe. There may even be a very specific set of circumstances that has to occur for someone to be able to gain access to those decryption keys, so there might be court orders, or legal proceedings that are required before anyone is able to gain access to those decryption keys.
It’s very common for the certificates that we’re using to be signed by an intermediate CA, or device that is not the root certificate authority. Because of this, we need to have some way to validate that the intermediate or hierarchical CA that we happen to be using is one that is original to the root CA. To be able to do this, we use a chain of trust, which allows us to list all of the certificates between the server that we’re connecting to and the root certificate authority. This chain starts with the SSL certificate that we are connecting to, and it ends with the root CA. You can see a representation of this if you click the lock that is in your browser address bar, and have a look at the details of the certificate.
Any certificate that is between the device that you’re connecting to and the root CA is a chain certificate. Sometimes you’ll hear this referred to as an intermediate certificate. This means if you’re the administrator of this web server that you’ll need to add the certificates for all of these chain certs. Otherwise, someone connecting to your site may receive an error in the browser.
Here’s a better view of this entire chain of certificates. We’re connecting to robowhois.com. There is an R3 intermediate certificate, and then finally, the DST root CA certificate. So on our web server, we would have to have, of course, the certificate for the local web server, but we’ll need to include the certificate for R3, and ultimately, we’ll need to make sure we have a certificate for the root CA as well.