Encryption is a fundamental reality on the Internet today.  Most sites use SSL/TLS for encryption, and you can identify these sites by the https:// in the address bar of your browser.  The Internet security service company Netcraft has been tracking SSL usage for over 20 years now, and their most recent data shows that there are now more than one thousand times more certificates on the web today than in 1996.  DevCentral is no exception to this SSL phenomenon…go ahead, check your browser’s address bar and notice the address for this article (or anything else on DevCentral for that matter) will start with https:// instead of plain old http://.  This SSL/TLS encryption provides a secure means of communication between your browser and the web server.  In order to make all this encryption happen, encryption keys are shared between the web server and your browser.  Encryption key exchange gets very complicated and this article is not meant to explain all the details of encryption key exchange mechanisms, but from a very high-level perspective, it’s fair to say that these keys are shared by using the web server’s SSL/TLS certificate. When a user visits a secure website, an encryption key exchange process takes place, and the resulting encryption keys are used to encrypt all communication between that user and the web server.  A certificate is a digital file that holds several pieces of information related to a particular website.  One of the pieces of information it holds is the public portion of the encryption key used to encrypt all the communications to/from the web server.  Another piece of information it holds is the effective dates of the certificate.  After all, these things are only good for a finite period of time (typically 1-2 years). In a perfect world, a web server would be issued a certificate and that certificate would never get compromised and it would be used for the full duration of the life of the certificate.  But we don’t live in a perfect world.  The reality is that certificates get compromised all the time, and when that happens, the certificate needs to be revoked.  Typically when a web server certificate is revoked, a new certificate is created and used in place of the old, revoked certificate.  But, how does a user know that a certificate has been revoked?  The Magic of CRL and OCSP Here’s how it works…when a user visits a secure website, the certificate is sent from the website to the user’s browser (Chrome, Firefox, Internet Explorer, Safari, etc).  Because certificate sharing creates significant computational overhead, many browsers simply store the certificate information from a previously-visited website in their cache so they don’t have to keep asking for a new certificate each time they visit that website.  This is nice because it significantly speeds up the user experience for loading that particular secure website, but it also presents a problem when the certificate is no longer valid.  In order to check that a given certificate is still valid, the concept of a Certificate Revocation List (CRL) was introduced.  The CRL is a digital file created by a Certification Authority (the organization that creates and distributes certificates) that contains the serial number for each certificate that has been revoked by that CA.  In order for a browser to check that a given certificate is still valid, the CRL must be downloaded and the serial number for the website you are visiting must be checked against the CRL to ensure the certificate is not revoked.  If the certificate is not revoked, all is good and the browser displays the page.  But if the certificate has been revoked, the browser should display a warning page that tells you the certificate has been revoked.  Some browsers will allow you to continue to the page anyway and others won