The details of a public key infrastructure are sometimes the most important pieces. In this video, you’ll learn about online and offline CAs, OCSP stapling, certificate pinning, and more.
<< Previous Video: PKI Components Next: Types of Certificates >>
Our public key infrastructures rely on trust. Usually this trust is provided by a certificate authority. But what if someone compromises the CA? This obviously means that we can’t trust any of the certificates that were generated by this particular certificate authority.
This is why we will usually have a root certificate authority that will then create intermediate certificate authority certificates. And these intermediate certificate authorities are the ones that then issue certificates. So this certificate authority may issue 1,000 certificates, this one may issue 2,000, and this one might issue 3,000.
Once these certificate authorities are up and running, we can then take the root certificate authority offline. This means that we’re able to protect the root CA. If someone does compromise an intermediate certificate authority, the scope of the compromise will only be for the certificates that were issued by that particular intermediate CA.
In our last video, we talked about OCSP, or the Online Certificate Status Protocol, and how it’s used to check to see if any certificates may have been revoked. This is a process that relies on the certificate authority. But as we found, if we have many devices that are needing to check in with the certificate authority, it becomes very difficult to scale this up into a very large-scale implementation.
Instead of using the central method to the CA, we can implement OCSP stapling. This means that the device that holds the certificate will also be the one to provide status of any revocation. This information is gathered directly from the device that holds the certificate rather than going all the way back to the certificate authority.
The revocation status is stapled into the handshake that occurs initially for the SSL or TLS communication. There is a digitally-signed notice in there from the certificate authority, so the person that does receive the OCSP-stapled information can trust that it really did come from the CA.
In certain situations, someone may be able to sit in the middle of an encrypted communication using a man-in-the-middle attack. One way to prevent this from occurring is by using certificate pinning. Certificate pinning is when an application has hard-coded the server’s certificate into the application itself. The application will then communicate to the server, receive a copy of the certificate, and then compare that certificate to the one that has been hard-coded into the application.
If the certificates match, then we know that we’re communicating directly to the server. But if the certificates don’t match, the application can decide what to do at that point. It may shut down or show an error message about the mismatch of certificates.
Certificate authorities start with a single CA. And if we just have that single certificate authority, then all of the devices that receive certificates will use that as the single authority for everything that’s created. In most environments, though, we have a hierarchical structure where there’s a root certificate authority and then there may be many intermediate certificate authorities under that one. In some environments, you may choose to mesh these certificate authorities together. Although, you can see, once you get to a larger number of CAs, it becomes more and more difficult to scale this so that you can mash all of the CAs to each other.
An alternative to a certificate authority is to make everyone an authority. This is called a web of trust. So I might trust you, someone else may trust you, therefore, someone else may trust me. This is commonly used with PGP, where people will sign other people’s certificates so that a friend of a friend is someone who could be trusted. And in some environments, you not only have a scenario where you’re trusting the certificate from a server, but the server may be also trusting the certificate from you. We call this mutual authentication.
With key escrow, someone else may have access, or hold, your decryption keys. These private keys would be in the hands of a third party and that third party would have a particular service or particular backup function to the keys that you would normally have internally. This may also be part of a business arrangement, where you may need access to certain kinds of information, but you may need to go to a third party to gain access to decrypt those details.
When someone else is holding these decryption keys, there obviously needs to be very well-defined processes and procedures. These keys are incredibly important pieces of information and you need to be sure they’re managed appropriately. Of course, you need to be able to trust the third party who will be holding these keys and you need to be sure that third party is able to secure the keys properly.
In some cases, it may be very difficult to gain access to these keys from the third party. It might take legal proceedings or even court orders to be able to gain access to the keys, but that may be by design. You may not want anyone having free access to the keys unless there’s a very good reason.
As we mentioned earlier, there may not be just a single certificate-authority. There may be an entire hierarchy of certificate authorities and there may be multiple levels within this hierarchy. We call this connection between all of these different certificate authorities a “chain of trust.” This would be listing out all of the different root certificate authorities and then the intermediate certificate authorities underneath that one.
This chain would start with the SSL certificate that’s part of a web server. You would then see the certificate authority that assigned that particular certificate. There might be a certificate authority above that one. And then, finally, a root certificate authority above that one.
We call these certificates between the web server SSL certificate and the root certificate authority “chain certificates,” or, “intermediate certificates.” And it’s very common on your web server to configure not only the SSL certificate you’ve been assigned, but to also add the chain certificates or intermediate certificates between that SSL certificate and the root CA.