OCSP through an outbound explicit proxy
Hey DC community, Kevin Stewart here with a fun little project I'd like to share. There have been countless questions about this over the years: how to pass LTM or APM OCSP requests through an outbound explicit proxy. We've already established that you can create a simple VIP and iRule that "proxifies" an outbound OCSP HTTP request, and that you can point the OCSP responder configuration URL directly at this layered VIP. But what if client certificates need to be validated against different OCSP responders, based on the X509 AIA extension?AIA, or "Authority Information Access" is an X509 certificate extension that identifies, among other things, the OCSP responder URL that a given client certificate should be validated against. The LTM and APM OCSP clients (as of 13.1) don't pass an HTTP Host header, and don't allow you to inject any "signaling" information into the outbound OCSP request. That means there's no easy way to get the client's real certificate AIA value over to the proxy VIP, plus you need the OCSP responder to point to the proxy VIP anyway. The answer is to signal "out-of-band" - at the application VIP, catch the certificate issuer, serial and AIA values into a table, issuer_hash:serial = AIA and at the proxy VIP, catch the issuer and serial in the OCSP request and look up the AIA URL from the table. The issuer value in the OCSP request is a SHA-encoding of the issuer value from the DER-formatted certificate. You can't just SHAhash the X509::issuer value. That'd be too easy.It's necessary then to binary parse the issuer directly from the binary certificate blob. The OCSP request is already binary, so you have to binary parse this data anyway. Before I get into the details, I should warn you that there's a lot of binary processing TCL code in these iRules, which a) isn't for the faint of heart, b) isn't great for performance, and c) isn't going to correct for every type of certificate. I did testthis with sha1WithRSAEncryption and sha256WithRSAEncryption certificate signature algorithms, across both RSA and EC certs, and these all worked. It's also worth noting that the performance loss may be neglible given that OCSP itself will be the bigger hit. However, things like TLS session resumption should keep full handshakes and OCSP validation from happening as much over a set of active user sessions. The configuration looks basically like this: Create your application VIP, pool, and client SSL profile as required. Test without client cert auth first to makes sure basic flow and functionality works as expected. Create an internal "proxy" VIP and pool that points directly at the outbound explicit proxy (ex. 192.168.2.1:3128), and attach the proxy iRule. You can also create an empty VLAN (no interfaces), attach a unique self-IP to that VLAN (ex. 11.11.11.1), and assign an IP from that subnet to the proxy VIP (ex. 11.11.11.2:80)to keep all OCSP proxy traffic internal. Also make sure the proxy VIP is listening on the correct VLAN, enables address and port translation, and SNAT as required. If using LTM OCSP, create the OCSP responder, configuration and profile. If using APM OCSP, create the OCSP responder AAAand an access policy VPE that starts with the OCSP authentication agent - the included iRules parse the certificate issuer, serial and AIA from CLIENTSSL_CLIENTCERT, so the client SSL profile needs to request the client certificate (versus the APM On-Demand Cert Auth agent). This could also be done completely within the Access context, but I'm not adding that code right now (maybe later). Point the OCSP responder URL at the HTTP proxy VIP URL (ex. http://11.11.11.2) and check "ignore AIA". If APM OCSP, set CertID Digest to SHA-1. LTM OCSP automatically uses SHA-1. Attach the application iRule to the application VIP, and attach either the LTM OCSP authentication profile or APM access policy to the application VIP. Application iRule when CLIENTSSL_CLIENTCERT { ## Get the SHA1 hash of the DER-formatted issuer value ## X509 certificates are ASN.1-formatted, which is not easy to parse. ## Based on RFC5280 (https://tools.ietf.org/html/rfc5280), the issuer field is a mandatory value in the X509 certificate ## that comes directly after the signature algorithmIdentifier value. So we'll start by finding the object identifier (OID) ## of the signature algorithm, and then walk down the ASN.1 blob to the next item, which is the issuer. if { [SSL::cert count] > 0 } { ## Start with the PEM-formatted certificate, remove the "BEGIN CERTIFICATE" and "END CERTIFICATE" header/footer, ## and base64-decode the remaining data to expose the binary (DER-formatted) certificate. set strippedcert [findstr [X509::whole [SSL::cert 0]] "-----BEGIN CERTIFICATE-----" 27 "-----END CERTIFICATE-----"] if { [catch { b64decode ${strippedcert} } string_b64decoded] == 0 and ${string_b64decoded} ne "" } { if { [catch { ## sigAlg OID (1.2.840.113549.1.1.5) = sha1WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ## sigAlg OID (1.2.840.113549.1.1.11) = sha256WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ## Find the initial offset at the position of sigAlg OID in the certificate ## Here's an online tool to convert OID to Hex: https://misc.daniel-marschall.de/asn.1/oid-converter/online.php if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ${string_b64decoded}]] > 100] } { if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ${string_b64decoded}]] > 100] } { ## Error: unknown signature algorithm } } ## Offset this position by the size of the sigAlg set newoffset [expr ${offset} + 13] ## Get the length of the issuer value - ASN.1 values start with a type and a length, so this extracts the length value. binary scan [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + 4]] H2H2 type issuer_len_hex ## Convert the length to decimal scan ${issuer_len_hex} %x issuer_len_dec ## SHA1-encode the DER-formatted issuer value - this is the value that will be present in an OCSP request binary scan [sha1 [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + ${issuer_len_dec} + 1]]] H* issuer_hash ## Store the SHA1 issuer hash:cert serial in a short-lived table with the AIA URL set AIA [findstr [X509::extensions [SSL::cert 0]] "OCSP - URI:" 11 "\n"] set serial [X509::serial_number [SSL::cert 0]] table set -subtable OCSP_AIA "${issuer_hash}:${serial}" "${AIA}" 5 5 } error] } { log local0. "error = $error" } } } } Proxy iRule when RULE_INIT { ## Static ocsp responder URL - if the client cert doesn't have an AIA or the app VIP iRule is unable to parse it, ## include this value as a default OCSP URL. You may optionally just choose to fail the connection. set static::ocsp_host "http://ocsp1.f5testlab.local/" } when CLIENT_ACCEPTED { set AIA "" TCP::collect } when CLIENT_DATA { ## Find the first offset as the position of the SHA-1 OID - based on RFC 2560 (https://www.ietf.org/rfc/rfc2560.txt), ## an OCSP request is an ASN.1-formatted binary structure that contains the following: ## - hashAlgorithm - we know this is SHA-1 because the F5 OCSP is configured to use SHA-1. ## - isserNameHash - a SHA-1 hash of the DER-formatted issuer value. This is the first value we need. ## - issuerKeyHash - a SHA-1 hash of the issuer's public key. We don't need this value. ## - serialNumber - the client certificate serial number. This is the second value we need. set offset [string first \x06\x05\x2B\x0E\x03\x02\x1A [TCP::payload]] ## Set new offset after the SHA1 OID set newoffset [expr ${offset} + 7] ## Get the issuerHash length binary scan [string range [TCP::payload] ${newoffset} [expr ${newoffset} + 8]] H2H2H2H2 t1 t2 t3 issuer_len_hex ## convert the issuerHash length to decimal scan ${issuer_len_hex} %x issuer_len_dec ## Get the issuer hash value - this is the issuer hash that we need. binary scan [string range [TCP::payload] [expr ${newoffset} + 4] [expr ${newoffset} + 3 + ${issuer_len_dec}]] H* issuer_hex ## Set new offset after the issuerHash set newoffset [expr ${newoffset} + 4 + ${issuer_len_dec}] ## Get the issuerKeyHash length binary scan [string range [TCP::payload] ${newoffset} [expr ${newoffset} + 4]] H2H2 type issuerKey_len_hex ## convert the issuerKeyHash length to decimal scan ${issuerKey_len_hex} %x issuerKey_len_dec ## Set new offset after the issuerKeyhash set newoffset [expr ${newoffset} + 2 + ${issuerKey_len_dec}] ## Get the serial length binary scan [string range [TCP::payload] ${newoffset} [expr ${newoffset} + 4]] H2H2 type len_hex ## Convert the serial length to decimal scan ${len_hex} %x len_dec ## This is the serial number that we need. binary scan [string range [TCP::payload] [expr ${newoffset} + 2] [expr ${newoffset} + 1 + ${len_dec}]] H* serial ## Look up the table entry for the issuerHash:serial set AIA [table lookup -subtable OCSP_AIA "${issuer_hex}:${serial}"] ## Optionally close the connection or doing something else if a table entry isn't found. Otherwise release. TCP::release } when HTTP_REQUEST { if { ${AIA} ne "" } { ## If AIA exists, dynamically change the URI to map to the client cert OCSP AIA URL ## This is the "proxyification" function to allow unencrypted HTTP to flow through an explicit proxy. ## Most, if not all public OCSP responders perform OCSP over unencrypted HTTP, so there's no need ## to deal with messy HTTP CONNECT logic. HTTP::uri "${AIA}" } else { ## Otherwise use the system default OCSP URL HTTP::uri $static::ocsp_host } } To recap, an OCSP responder configuration (LTM or APM) points to a local "proxy" VIP (and ignores AIA). The application VIP iRule first grabs the client certificate AIA URL, serial number, and issuer hash, and throws those values into a table. Upon client certificate authentication, the OCSP responder client issues an OCSP request that flows to the proxy VIP. The proxy VIP grabs the issuer hash and serial number from the OCSP request, looks up the AIA URL in the table, and dynamically changes the HTTP URI value in the outbound request to the explicit proxy, to effectively proxify the OCSP request. As stated, this should work withsha1WithRSAEncryption and sha256WithRSAEncryption certificates. If you come across a certificate that uses something else, please let me know. Thanks. - Kevin Edit: If you want to do this completely inside APM, using an On-Demand Cert Auth agent: Insert an iRule event agent between the On-Demand Cert Auth agent and the OCSP Auth agent in the VPE. Use "GETISSUER" as the iRule event agent ID. Switch out the application VIP with the following: Access Application VIP when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "GETISSUER" } { set strippedcert [findstr [ACCESS::session data get session.ssl.cert.whole] "-----BEGIN CERTIFICATE-----" 27 "-----END CERTIFICATE-----"] if { [catch { b64decode ${strippedcert} } string_b64decoded] == 0 and ${string_b64decoded} ne "" } { if { [catch { ## sigAlg OID (1.2.840.113549.1.1.5) = sha1WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ## sigAlg OID (1.2.840.113549.1.1.11) = sha256WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ## find the position of sigAlg in the certificate if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ${string_b64decoded}]] > 100] } { if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ${string_b64decoded}]] > 100] } { ## Error: unknown signature algorithm } } ## offset this position by the size of the sigAlg set newoffset [expr ${offset} + 13] ## get the length of the DER-formatted issuer value binary scan [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + 4]] H2H2 type issuer_len_hex ## convert the length to decimal scan ${issuer_len_hex} %x issuer_len_dec ## SHA1-encode the DER-formatted issuer value binary scan [sha1 [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + ${issuer_len_dec} + 1]]] H* issuer_hash ## Store the SHA1 issuer hash:cert serial in a short-lived table with the AIA URL set AIA [findstr [ACCESS::session data get session.ssl.cert.x509extension] "OCSP - URI:" 11 "\n"] set serial [ACCESS::session data get session.ssl.cert.serial] table set -subtable OCSP_AIA "${issuer_hash}:${serial}" "${AIA}" 10 10 } error] } { log local0. "error = $error" } } } }Configuring OCSP Stapling on BIG-IP
When setting up an SSL connection the cert tells you its expiration, but how do you tell if the SSL Cert has been revoked? There are multiple ways to do this. The first is the Certificate Revocation List (CRL). When the client requests the CRL, the cert provider will send a list of revoked certificates. The problem is that over time this list becomes very large as certs are added. Case in point, heartbleed casued a spike in the number of certs added to CRL list. To get around these large lists when all the client is looking for is one cert is the Online Certificate Status Protocol (OCSP.) This allows the client to query the CA for the validity of the cert in question. There are still problems, for example there can be a large number of clients that query the OCSP responder. If the OCSP responder takes too long and times out, then most clients will ignore the problem and move on. With OCSP stapling the client can ask the server to staple the OCSP response with the SSL server certificate response from the server. This allows the server to deal with the OCSP message and not require the client to query the OCSP responder. Doing this offloads the process from the OCSP server to the server, spreading the load around, making it quicker in most cases and limiting OCSP timeout. Once the server gets the OCSP response it can cache the response for the valid period, so one request to the OCSP server will serve many responses to the client. Requirements for OCSP Stapling on BIG-IP The OSCP responder for the cert in question.In this case startSSL.com allows you to generate a real cert for the test. The OSCP responder is http://ocsp.startssl.com You need to make sure the cert has the full chain for the client and f5 to trust Test both the responder and the chain with the following openssl command To test the SSL chain run the following command: openssl verify -CAfile \:Common\: \:Common\:"cert in question" The output should be like the following :Common:"cert in Question": OK Now test OCSP response from openssl openssl ocsp -issuer \:Common\: -cert \:Common\: -text -header "HOST" "host name of ocsp" -url http:/// -CAfile \:Common\: You should get an output like below: OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Class 1 DV Server CA OCSP Responder Produced At: Jan 14 18:19:02 2016 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 5168159AB1999B3A55E860C022C9D519E0303D29 Issuer Key Hash: D7914E01C4B0BFF8C86793449CE733FAAD930CAF Serial Number: 346F8F9596F4A3AEB2B0C3AE693B5A7F Cert Status: good This Update: Jan 14 18:19:02 2016 GMT Next Update: Jan 18 18:29:02 2016 GMT Once you have tested and know the cert and CA are correct you can connect to the correct OCSP responder now it time to setup the f5. BIG-IP Configuration Steps First we need to Create the DNS resolver this is located in Network -> DNS Resolvers. The defaults are fine here you just need to add a name Next you will need to create a forward zone.For the name put . and enter the DNS server that the unit should use. Now we can create the OCSP Stapling profile. For the DNS Resolver put the one in that you setup in the steps above For the Trusted Certificate Authorities this is the CA file you test with earlier Responder URL us the URL from earler that the f5 will direct all OCSP requests to. By default Sign Hash is set to SHA256 there responders that will not work with this and it will need to be set to SHA1 Timeout is the amount of time till the f5 drop the connection to the OCSP server. This has to be smaller them the Handshake timeout in the SSL Profile. Status Age is the age of the from this update, most servers will have a range that this update is good for. By default the f5 1 day make sure you check your server to make sure the Status Age is large enough to handle this Cache Timeout this is how long the f5 will cache the response, default is Indefinite this allows the f5 to cachethe request for the length of the validity period the server sets Next step is to create the SSL profile and add the Stapling Profile Now after the ClientSSL profile is add to the VIP you are ready to test. Testing it out If your site is open to the Internet you can use tools like Qualys SSL Labs, or you can test with OpenSSL with the following command: certificate_d # openssl s_client -connect VIP IP:443 -tls1 -tlsextdebug -status | grep -i "ocsp response" -B 5 -A 10 The output from a successful OCSP stapling OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Class 1 DV Server CA OCSP Responder Produced At: Jan 14 18:19:02 2016 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 5168159AB1999B3A55E860C022C9D519E0303D29 Issuer Key Hash: D7914E01C4B0BFF8C86793449CE733FAAD930CAF Serial Number: 346F8F9596F4A3AEB2B0C3AE693B5A7F Cert Status: good Much thanks to Richard Harlan, one of F5's fine field systems engineer for contributing this write up!Security Sidebar: My Browser Has No Idea Your Certificate Was Just Revoked
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’t…it just depends on the browser. The CRL check method is computationally expensive because the browser has to download the CRL every time it needs to check a certificate (which happens very frequently), and it also has to search through the CRL for a match of the serial number of the certificate it is using (CRL files can get extremely large). In order to avoid frequent CRL downloads and searches, some browsers will cache the CRL for a given period of time and simply check the cached CRL instead of downloading a new one each time. This helps speed things up, but what if the CRL changed since the last time it was cached in your browser? This situation became a big enough problem that a new, faster solution was introduced. The Online Certificate Status Protocol (OCSP) was developed in 1999 and it is a solution that queries an online database of serial numbers for revoked certificates. Rather than host CRL files, CAs can instead setup an OCSP server and include its URL in issued certificates. Clients that support OCSP can then query the database to see if a given certificate has been revoked, instead of downloading the entire CRL file. OCSP is a much more efficient solution than the CRL method. Here’s a quick view of the certificate issued to f5.com. Notice it was issued by the Entrust Certification Authority, therefore Entrust is the one who manages the CRL file for all their revoked certificates and they also manage the list of serial numbers used in the OCSP queries. The picture on the left is the detailed view of the f5.com certificate with the CRL location listed. This is the URL where the browser can go download the CRL from Entrust. Keep in mind that this CRL is just the one managed by Entrust. I took the liberty of visiting the URL where the CRL is located, and the details for the CRL are shown in the picture on the right. Notice that the CRL is simply a big list of serial numbers with revocation dates and reasons for revocation. The following screenshot is the OCSP portion of the f5.com certificate. Notice the URL listed in the details section at the bottom of the screenshot. This is the URL that the browser will visit in order to check the current certificate serial number against the database of revoked serial numbers managed by Entrust. So Many Certificates, So Little Time… Now that we understand how a browser checks to see if a certificate is still valid, let’s take a little deeper look at the different types of certificates available today. There are three types of certificates you can purchase today: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). The DV certificate is the cheapest and most popular type of certificate. Each CA makes up its own rules as to what they require from an organization before they will issue the DV certificate. Typically it’s a very simple (and many times, automated) process like the CA sending you a file and you placing that file on the webserver at the domain in question…just something simple to let the CA know that they are issuing a certificate for a given domain to the actual owner. There are, of course, many different ways to hack this process and get a DV certificate for a domain that you don’t own. But, that’s a topic for another day. The OV certificate is more expensive than the DV, and it takes things a bit further with respect to the CA checking that the requesting organization actually owns the domain name. There are some other organizational vetting procedures that a CA might take in order to more fully understand that the requestor is the owner. In addition to what they would do for a DV certificate, maybe they’ll make a few reference phone calls and do some simple background checks. But, then again, it’s totally up to the individual CA to develop their own procedures for vetting an organization prior to issuing an OV certificate. The EV certificate is the most expensive, and it requires the most amount of background checking and validation from a CA before it is approved. In fact, the process for vetting an organization prior to issuing an EV certificate is governed by the CA/Browser Forum. This organization has developed a robust list of requirements that must be met before a CA can issue an EV certificate. Companies that want the EV certificate do so because they want to show the world that they are serious about the security of their online presence. The reality is that users visit these secure sites via an Internet Browser (Chrome, Firefox, Internet Explorer, etc), so it’s interesting to see how these different browsers handle certificate revocation and also how they treat the different kinds of certificates. The top 3 browsers on the Internet today are Google Chrome (70.4%), Mozilla Firefox (17.5%), and Microsoft Internet Explorer (5.8%). Almost 94% of all Internet traffic is displayed by one of these three browsers. Let’s take a quick minute to see how these check for certificate revocation. Google Chrome Google Chrome is by far the most popular browser today. When it comes to certificate revocation checking, Chrome blazes its own trail and does its own thing. The CRL and OCSP methods of certificate revocation checking are the industry standards, but Google isn’t standard in this space. It has created what’s known as a CRLSet to check for certificate status. A CRLSet is Google’s own list of revoked certificates that it compiles and updates when it crawls the CRLs from the major CAs around the world. Instead of checking an OCSP responder or a CRL, Google Chrome simply checks its own CRLSet for certificate status when visiting a secure website. Google claims that this is faster and safer for the user than the traditional CRL or OCSP methods. Some people think this approach is good because it’s faster to check a locally stored list than using the traditional methods and you also don’t have to worry about OCSP responder or CRL distribution point availability. But others are skeptical because the CRLSet is only comprised of certificates that Google deems worthy to include. What if the certificate you need to check isn’t on the CRLSet list? Also, the CRLSet file size is explicitly limited to 250KB. If something happens and lots of certificates are suddenly revoked causing the CRLSet to get bigger than 250KB (Heartbleed for example), then certificates are deleted from the CRLSet so that it stays at the 250KB max size. What if the certificate status you need gets deleted from the CRLSet during one of these bloat sessions? Mozilla Firefox Firefox allows you to check for revoked certificates via the OCSP method, but it doesn’t use the CRL at all. If a given certificate includes an OCSP address in the Authority Information Access (AIA) portion of the certificate, then Firefox will query the OCSP server to make sure the certificate is not revoked. If the OCSP server isn’t available or if the OCSP address is not present in the AIA field of the certificate, then Firefox won’t check revocation status and will present an error message (which the user can click through to proceed anyway). Check out the screenshot below for the settings in Firefox (version 46.0.1). Microsoft Internet Explorer Interestingly, Microsoft lE conducts the most comprehensive certificate revocation check of these leading browsers. The default setting is like Firefox…it checks the OCSP responder if the address is present in the AIA field of the certificate. But, if the OCSP server is not available or if the OCSP address is not present, it will then check the CRL (it checks the CRL loaded in cache if possible so that it doesn’t have to continually download a large CRL file). If neither of these is available, it will present a warning page and give the user an option of either proceeding forward with an unknown certificate status or closing out of the browser. The following screenshot shows the settings for certificate revocation checks in IE: You can see that each browser handles certificate revocation a little different than the next. So, it’s entirely possible that a revoked certificate could fall through the cracks if Google decided not to add it to their CRLSet, Firefox couldn’t contact the OCSP server, and Internet Explorer had an outdated version of the CRL stored in cache. Be careful out there...
