We use certificates to provide trust when accessing other devices or services. In this video, you’ll learn about digital certificates, certificate signing requests, key revocation, OCSP stapling, and more.
A digital certificate is a file that contains both a public key and a digital signature. You can think of this as a digital version of an identification card. But in reality, it has so many more capabilities than simply providing authentication.
One of the characteristics we’re constantly striving for in IT security is that of trust. Whenever we’re allowing someone access to a system, we’re trusting that the person using that username and password really is the person that we’d like to provide access. A digital certificate is a way to provide that trust. We can create a digital certificate, have a certificate authority digitally sign that certificate so that we know that if the certificate authority trusts that person, then we should also trust that person as well.
There are other ways to provide trust with digital certificates. One of those methods is through the use of a web of trust. Instead of having a centralized certificate authority, we can have multiple individuals sign each other’s certificate, thereby creating this web of trust. If we trust our friend and our friend has signed the digital certificate of a third party, then therefore, we can trust the third party as well.
But of course, you don’t necessarily need a third-party certificate authority to provide trust, especially if you’re just creating certificates within your own organization. In that case, you may want to use the certificate tools that are built into Microsoft Windows Domain Services. And there are many other third-party software options to provide your own certificate authority.
If you’re in a web browser and you’re connected securely to a website, you’ll notice there’s a lock in the address bar. And if you click that lock, you’ll be able to see the details of the certificate associated with that web server. You’ll notice that your browser is able to show you the information about the certificate for that web server regardless of what websites you might be connected to. That’s because all of these different websites are using a single certificate format that everyone can read.
The standard for that format is called an X.509 format. And sometimes, you’ll hear people refer to the X.509 certificate. And they’re referring to the standardized format for a digital certificate.
There is an amazing amount of information stored in these digital certificates. You have a serial number, a version, and a signature algorithm. You can see who issued the digital certificate, the name of the holder of the digital certificate, the public key, and other information as well.
In this video, we’ll look at some of these characteristics inside of this certificate. And we’ll talk about how we can use those to help better secure our networks. Having a method of creating trust between yourself and someone trying to gain access to your systems is a foundational part of IT security. The real challenge, of course, is, how do you trust something that up to this point has been an unknown entity?
For example, when we use our browser to visit a website for the very first time, how does our browser know that we’re connecting to the right website and creates that trust between you and that resource? One way to provide this trust is to have a third party vouch for the site that you’re connecting to so that if the third party trusts the site, then therefore, I should be able to trust the site as well.
We often refer to this inherently trusted component as the root of trust. This might be provided through hardware or software. Or there may be firmware or some other component that provides trust for a particular system. If we have a mobile phone or a website, we may be using hardware security modules, Secure Enclave, a certificate authority, or some other method that provides us with some level of trust for this particular system.
The method of trust that’s built in to all of our browsers is one that allows us to understand if we’re connecting to a website that can be trusted or not trusted. When you’re connecting to a website for the very first time, it would be great if we could get some feedback on whether this site can be trusted or whether it’s untrusted. So we’ll use a trusted third party, an authority of sorts, called a certificate authority.
The certificate authority is one that digitally signs the certificates that are stored on that website. And your browser trusts the certificate authority. So when you visit this website for the very first time, you can view their certificate and see that their certificate was digitally signed by a certificate authority that your browser already trusts. Therefore, you also will trust this third-party website.
This provides a real-time validation that this website is one we can trust. And it’s this process that occurs to every website we visit throughout our workday. This process that a browser uses to trust a website is built into the internals of the browser that you’re using.
And if you look at the list of certificate authorities that are trusted by your browser, you will see there are hundreds of certificate authorities listed. This means the website can purchase a certificate from any of these hundreds of certificate authorities, put that digitally signed certificate on their web server. And as long as they’re in the list of your browser, they’ll be trusted.
In this example, the certificate authority is in charge of digitally signing this certificate that you put on your website server. But we’re not really purchasing a digital signature. When we purchase a certificate, we’re really purchasing the validation process that a certificate authority goes through.
The certificate authority is going to go through a series of verifications to make sure that the person receiving that digital signature is truly the owner of that particular website. That is the trust part that is built into this certificate authority. And it’s how we can trust any of these websites that we visit throughout the day.
Let’s say that we would like to create a certificate for our web server. We’d like to send that certificate to a certificate authority to be validated, have them digitally sign it, and return that back to us. The process to do this is relatively simple.
We would first create what is effectively a digital certificate by using our public key, add the identifying information about what server this might be connected to and information about our organization, and combine those together to create a Certificate Signing Request, or a CSR. That CSR is sent to a certificate authority. The certificate authority now does the validation process. They confirm that the certificate that you’re asking for is one that is really for a web server that you own and control. And if they agree that this is a valid certificate, they will use their private key to digitally sign the certificate and send it back to you.
It’s this middle part where the validation is occurring that is so important to this entire process. If the certificate authority doesn’t provide this validation, then we can’t trust any of the certificates from that CA. That’s why this validation process is so important, because that’s where we get trust associated with this digital certificate.
So far, we’ve been talking about using a public CA that is built into everyone’s browser in the world to be able to provide trust. But if you have your own internal applications and your own internal web servers and these will only be connected to by people inside of your organization, then you can be your own certificate authority. For this to work, we would install our own certificate authority software inside of our organization.
We would then take the public certificate for that certificate authority, and we would install it on everyone’s computer inside of our organization. That way, everyone’s machine would trust the certificate authority we run internally, the same way that they would trust a certificate authority that was external. And you’ll find that this is relatively common for medium- to large-sized organizations that have their own internal services. They can create their own certificates using an internal CA.
There are many software packages that allow you to create your own certificate authority. Microsoft has their Windows Certificate Services that you see here. There’s OpenCA and many other third-party software packages.
So now we’ve created our own certificate authority for everything that is internal to our organization. And if we have an application or user that needs a certificate, we don’t have to go outside to a public CA. We can simply use our internal CA to create those certificates.
The process for creating a digital certificate, having the certificate authority digitally sign that certificate, and distributing it back to the end user is exactly the same as you would use with an external CA. The only difference is we’re using our internal CA to provide the trust and provide digital signatures for all of our certificates. As long as you’ve installed your internal certificate authority certificate to the trusted chain on all of your devices, it works exactly the same as an external or public CA. All of these devices will inherently trust anything they’re connecting to because you’ve digitally signed those with the internal CA.
If you’re visiting a website in your browser and you click the lock that is in the address bar, you’ll be able to see all of the details of that certificate. And if you scroll through this web server certificate, you may see a section called Subject Alternative Name. Sometimes, we refer to this as a wildcard certificate because it allows you to put the name of a domain with an asterisk associated with the name of the device. This means the certificate that we’ve created can be used for any device that happens to share that fully qualified domain name listed in the Subject Alternative Name.
For example, in this certificate, there are large number of DNS names that are listed. One of these is birdfeeder.live, which is one of my certificates. And you can see it has an *.birdfeeder.live. That means that this certificate could be used for www.certificate.live, ftp.certificate.live, mail.certificate.live, and so on.
From an administration perspective, this makes it very easy to create a single certificate and distribute that certificate to a large number of devices within your organization. As long as that device is associated with that domain name, this certificate will be valid for that service.
There may be times when we’re decommissioning a web server, and we would like that certificate to no longer be valid. Or maybe we’re concerned that an attacker has gained access to our certificates. So we would like to revoke all of those certificates and create some that are new.
One of the ways that we can provide this revocation is through the use of a CRL, or a Certificate Revocation List. This is a list of all of the certs that have been revoked. And we keep this list on the certificate authority itself. This administrative process of creating and then revoking certificates is one that is built into any certificate authority. But there might be other reasons for providing some way to revoke a certificate.
We found this out in April of 2014, when we discovered an attack that could have a web server provide a third party with the web server’s private key. We refer to this attack as Heartbleed. And it was due to a vulnerability in the OpenSSL application library. We had to revoke all of our certificates and create brand-new certificates once this OpenSSL code was updated.
All of our old certificates were moved to the certificate revocation list. And our newer certificates were then installed into all of our web servers. You can see how important it is to have some method for revoking this trust which had previously been installed onto a particular service.
You can find where this list of revoked certificates happens to be by looking into the details of your certificate. If you click the lock on the address bar of your browser, you can scroll through the certificate and find a section that’s called CRL Distribution Points. This will include a list of URIs, or Uniform Resource Identifiers, that are effectively a link to the CRL file.
So this tends to be a multistep process. Your browser connects to a third-party website. That third-party website provides your browser with its certificate. Your browser then looks through the cert to find the CRL distribution points and then follows one of those URIs to download the CRL list.
From there, your browser can look through this list and make sure that this certificate is not one that’s listed as being revoked. As long as it’s not in the list, you can continue with your browsing session. But if this certificate from this third-party website is listed in this CRL, your browser knows that is now a site that is not trusted. This certificate is not valid. And it will not allow you access to that web server.
As you can imagine, it’s not very efficient to have a single file that lists out all the revocations for a certificate authority. It would be great if we could have a more efficient process that didn’t involve us going to a third-party site and downloading a big list of revocations. Fortunately, we’ve created a protocol that does exactly that.
This is OCSP, or the Online Certificate Status Protocol. Relying on the certificate authority to provide a list of all of these revocations to anyone who might be visiting our website is inherently inefficient. To make this process more efficient, we can put the status of our certificates onto our web servers itself.
This is accomplished by sending status messages about the validity of your certificate during the SSL handshake that occurs when you first connect to a web server. This is referred to as OCSP stapling because we’re embedding the status of this certificate within the handshake of this server. We obviously can’t trust a third-party web server to truthfully tell us the status of the certificate. So this OCSP protocol uses a digital signature by the CA to validate its status.
Most browsers today support OCSP for the Online Certificate Status Protocol, which means the browser itself can handle all of the checks for revocation when you visit a third-party website. If you’re not stapling the status into the handshake message, you could use a third-party server to provide the OCSP status information. This is easily added to the certificate. And it’s much more efficient than downloading an entire certificate revocation list from your CA.
If your organization is using very outdated browsers, you may find that OCSP is not an option. And even some of the newer browsers say that they support using OCSP but unfortunately don’t implement the checks properly to be able to confirm the status of a certificate. Most modern browsers support OCSP. But you might want to check your browser and see that it really performs the validation when you connect to a website so that you can tell what the status is of those certificates.