CertMike Explains Revoking Digital Certifcates

Key Takeaways

Hi there, I'm Mike Chapel and in this CRM Mike Explains video, we're going to talk about certificate revocation, the process of making sure that compromised or invalid digital certificates can't be used to impersonate their rightful owners. We'll also cover how to make this process more efficient with certificate stapling. The security of a digital certificate depends upon the protection of the private key associated with that certificate. If the certificate owner's private key becomes compromised, the owner must revoke the certificate so that no one can use it to impersonate the certificate owner. Now, there are two methods for revoking a digital certificate. The use of certificate revocation lists and the online certificate status protocol. The certificate authority that issued the digital certificate manages both of these methods. The original method for handling revocation is the use of a certificate revocation list or CRL. A CRL is just a list published by the certificate authority that contains the serial numbers of all the certificates that authority has revoked. As you can see here, each digital certificate includes a CRL distribution point field that tells clients where they can download this list. Here's an example of a real CRL. When the CA revokes a certificate, it adds that certificate serial number to its CRL. Before trusting a certificate, the client must fetch the CRL from the issuing certificate authority and then check whether the certificate serial number appears on that list. If the number is listed, the certificate is no longer valid and the client should reject it. While this process ensures that revoked certificates can't be trusted, it does come with drawbacks. CRLs grow over time as more certificates are revoked, meaning that clients often have to download large files just to check the status of a single certificate. There can also be a delay between the moment a certificate is revoked and the time that clients actually see that replication reflected in the CRL. The second approach is the online certificate status protocol or OCSP. In this approach, before relying on a certificate, the client sends a status request for that certificate serial number to the CA or an authorized responder. The responder returns a signed statement that says whether the certificate is valid, revoked, or of unknown status. certificates include an authority information access field that tells clients where to send these OCSP requests. This approach reduces overhead and gives nearrealtime status. Now OCSP works well, but there are still ways we can make it even more efficient, and I'll explain those in just a moment. But before we get into that, I want to take a moment to invite you to visit my website at certmike.com. On that site, I have free study plans put together to help you earn your next certification. The plans tie together the content that you'll find in study guides, video courses, and practice tests to help you prepare for your next certification exam and pass that test on the first try. Also, if you're enjoying this Mike Explains video, please take a moment to click on the like button below to help other people discover it. If you subscribe to my channel, you'll be among the first to see my new videos as they come out. Now the primary issue with OCSP is that it places a significant burden on the OCSP servers operated by certificate authorities. These servers must process requests from every single visitor to a website or other user of a digital certificate, verifying that the certificate is valid and hasn't been revoked. Certificate stapling is an extension to the online certificate status protocol that relieves some of the burden placed upon certificate authorities by the original protocol. Let's look at how certificate stapling works for a web server. When a user visits a website and initiates a secure connection, the website sends its certificate to the end user, who would normally then be responsible for contacting an OCSP server to verify the certificate's validity. With certificate stapling, the web server contacts the OCSP server itself and receives a signed and timestamped response from the OCSP server, which it then attaches or staples to the digital certificate. Then when a user requests a secure web connection, the web server sends the certificate with the stapled OCSP response to the user. The user's browser then verifies that the certificate is authentic and also validates that the stapled OCSP response is genuine and recent. Because the CA signed the OCSP response, the user knows that it's from the certificate authority and the timestamp provides the user with assurance that the CA recently validated the certificate. From there, communication may continue as normal. Now, that might sound like it's just as much burden on the CA server as if the user requested the certificate, and it is for that first time. The savings come when the next user visits the website. The web server can simply reuse the stapled certificate without reconting the OCSP server. As long as the timestamp is recent enough, the user will accept the stapled certificate without needing to contact the CA's OCSP server again. Now, it's common to have stapled certificates with a validity period of 24 hours. That reduces the burden on the OCSP server from handling one request per user over the course of a day, which could be millions of requests, to handling one request per certificate per day. That's a tremendous reduction. I hope this video helped you better understand certificate reputation and certificate stapling. If it did, please click the like button below and subscribe to my channel for more IT certification content.