TLS certificates can become invalidated typically in one of two ways \u2014 certificate expiration<\/a> and revocation. The TLS certificates can become invalidated typically in one of two ways \u2014 expiration and revocation. The certificate clearly mentions the expiration date, and browsers generally won\u2019t connect to a website with an expired certificate. But what if the certificate is revoked before its assigned expiration date? Browsers have a few different ways of dealing with this, including checking a CA\u2019s certificate revocation list (CRL), their online certificate status protocol (OCSP) responses, and the related process known as OCSP stapling.<\/p>\n\n\n\n In future articles, we\u2019ll look at OCSP and OCSP stapling more in depth. But for now, we\u2019ll focus on learning and exploring everything \u201cCRL\u201d in this article.<\/p>\n\n\n\n A certificate revocation list is an indelible list of websites that have been revoked by the certificate authorities (CAs) that issued them prior to their assigned expiration dates. Basically, it\u2019s a list of certificates that\u2019s continually updated to warn browsers and operating systems that something is wrong and that they should avoid visiting those websites because they\u2019re not secure.<\/p>\n\n\n\n Once a certificate is added to the list, it can never be removed. The whole point is for the list to serve as a permanent record.<\/p>\n\n\n\n Let\u2019s take a quick peek at what a CRL looks like. We\u2019ll use Sectigo\u2019s certificate revocation list (CRL) as an example:<\/p>\n\n\n\n Still feeling a bit unclear on all of this? Think of a certificate revocation list as something akin to U.S. recalls.gov website<\/a>. This site contains lists of various categories of products that have been recalled by manufacturers due to safety, health, or other critical concerns. Basically, this list informs you that there\u2019s something wrong with specific items and that you should avoid using them.<\/p>\n\n\n\n Like products listed on the government recall list, websites on the CA\u2019s list of revoked certificates are not trustworthy. Certificate authorities release their CRLs containing details about revoked certificates at regular intervals, which vary based on each individual CA\u2019s policies. Once a certificate is revoked, it will always remain on the CRL.<\/p>\n\n\n\n Based on the information contained in the CRL, if a website certificate is valid, the browser will allow the connection. If the certificate is revoked, the browser will show a warning similar to this:<\/p>\n\n\n\n A CRL can contain a lot of information:<\/p>\n\n\n\n However, most certificate revocation entries typically just include the serial number and revocation date.<\/p>\n\n\n\n The following screenshots show the CRL generated and published by Adobe CA. You can see that there are two boxes in the first screenshot. The first shows the basic information, the second box shows more details.<\/p>\n\n\n\n There are three boxes in the second screenshot. The first provides an overview of all the revoked certificates the CA has and the corresponding date and time each was revoked. If you click on a particular serial number, you will see more details for that individual certificate displaying in the second box. The third box shows additional information about the certificate or the reason why it was revoked.<\/p>\n\n\n\n A CA can revoke a TLS certificate for one of several reasons and the reason is recorded in the CRL with a code. In the screenshot above, we can see that the CRL reason code is ‘Superseded (4).’ But what are these codes and what do they mean?<\/p>\n\n\n\n Let\u2019s take a quick peek at the certificate revocation reason codes<\/a> listed in the IETF\u2019s RFC 5280 and what they mean:<\/p>\n\n\n\n Note: <\/strong>Did you notice that there\u2019s no number seven on the list above? Good catch. RFC 5280 doesn\u2019t specify why the number seven isn\u2019t used. All we know is that it wasn\u2019t included.<\/p>\n\n\n\n CRL verification is the simplest way to verify the revocation status of TLS certificates. The figure below explains the process:<\/p>\n\n\n\n As you can see, CRL verification is carried out by the client browser.<\/p>\n\n\n\n The online certificate status protocol (OCSP) is another way to verify the status of TLS certificates online. In the OCSP verification process, the status of a particular certificate is requested (whether it is good or not). With a CRL, the list of all the revoked certificates is requested and then the browser confirms that the particular site\u2019s TLS certificate is not on list (meaning, it\u2019s thought to still be valid and hasn\u2019t been revoked early).<\/p>\n\n\n\n When we compare CRL verification with OCSP, OCSP is the clear winner in terms of efficiency and security. Still, the CRL method does have a couple of things going for it:<\/p>\n\n\n\n CRLs have several disadvantages compared to OCSP, including:<\/p>\n\n\n\n CRL verification takes up more network resources as the browser must download the whole list of revoked certificates, then parse the list for the certificate of the site it is attempting to access. This process is also more time-consuming than with OCSP.<\/p>\n\n\n\n Unlike OCSP, CRLs don’t offer real-time results as they are updated hourly, daily, or weekly. So, there is always a chance that a CRL could be outdated and the website it is trying to connect to has its certificate revoked since the last update.<\/p>\n\n\n\n If the certificate authority that issues the certificate revocation list doesn\u2019t have a strong, reliable infrastructure, then you\u2019re going to run into trouble. If the CA experiences a lot of downtime and other availability-related issues, it makes it hard to get a hold of the CRL. However, the same can also be said about the OCSP server responses as well.<\/p>\n\n\n\n (This is where OCSP stapling can help \u2014 but that\u2019s a whole other topic that we aren\u2019t going to get into here. Be sure to check back over the next few weeks for our upcoming article on OCSP stapling.<\/p>\n\n\n\n Many sites offer free tools to check the revocation status of websites. Let’s see what happens if we try it for SectigoStore.com using a tool on<\/a> certificate.revocationcheck.com<\/a>:<\/p>\n\n\n\n As you can see, the certificate is valid. This particular CRL is updated once a week by the certificate\u2019s issuing CA (Sectigo) and lists 1,295 revoked certificates (at the time this article was written). Does this sound like a high number? Just remember that this list is a permanent list, so it\u2019s no surprise that a CA that\u2019s been around since 1998 would have revoked certificates.)<\/p>\n\n\n\n Image caption: A screenshot of the certificate revocation list information for Sectigo.<\/p>\n\n\n\n A certificate revocation list contains information about all the websites with certificated revoked by the CA before their expiration date. The CA generates and issues the CRLs at intervals from once per hour to once a week. CRLs have played an important role in keeping us secure online since their introduction, but due to their cumbersome nature and the issues we mentioned earlier, the internet community is moving towards OCSP and OCSP stapling.<\/p>\n","protected":false},"excerpt":{"rendered":" In 2014, Mozilla moved away from using certificate revocation lists (CRLs) to check the validity of TLS certificates with the release of Firefox 28.0. So, do CRLs still matter? Yes,…<\/p>\n","protected":false},"author":19,"featured_media":2995,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[1],"tags":[256,257],"class_list":["post-2981","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-security","tag-certificate-revocation-list","tag-crl","post-with-tags"],"yoast_head":"\nWhat Is a Certificate Revocation List? CRLs Defined and Explained<\/h2>\n\n\n\n
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2022\/05\/revoked-certificate-crl-example.jpg\")
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2022\/05\/revoked-certificate-warning-message-example-1024x593.png\")
What Information Does a CRL Contain?<\/h2>\n\n\n\n
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2022\/05\/adobe-ca-revocation-list-1.png\")
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2022\/05\/adobe-ca-revocation-list-2.png\")
Why Do TLS Certificates Get Revoked?<\/h2>\n\n\n\n
How Does CRL Verification Work?<\/h2>\n\n\n\n
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2022\/05\/how-a-crl-works-illustration-1.png\")
Advantages of CRL Verification<\/h2>\n\n\n\n
Disadvantages of CRL Verification<\/h2>\n\n\n\n
Taxing on Network Resources<\/h3>\n\n\n\n
No Real-Time Updates<\/h3>\n\n\n\n
CRLs Require a Good CA Infrastructure<\/h3>\n\n\n\n
How to Check a Certificate\u2019s Revocation Status<\/h2>\n\n\n\n
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2022\/05\/sectigostore-certificate-revocation-status-check-example.png\")
<\/figure>\n\n\n\nFinal Thoughts on Certificate Revocation Lists or CRLs<\/h2>\n\n\n\n