Category Archives: Thoughts

A look at untrusted certificates

1 Reply

Today I did a blog post on how browsers show expired certificates. I figured I would take the opportunity to capture a few of the other failure cases for certificates.

 

The most severe example is that of an untrusted root certificate, for this scenario I figured the use of https://cacert.org was the most direct example.

 

There are a few cases where this error condition will come up, for example another one is if a server doesn’t include all of the intermediate certificates the clients cannot determine which Certificate Authority issued the certificate.

According to the current SSL Pulse data about 7.4% of the servers in the Alexa top one million may fall into this case.

 

Chrome

Internet Explorer

Mozilla

Opera

 

Safari

A look at expired certificates

3 Replies

Today I was on a mail thread where the topic of how browsers handle expired certificates; this is particularly relevant for a few reasons.

The first of which is that there is a large number of sites operating with expired certificates out on the Internet today, the other is that the adoption of short lived certificates (which I am a fan of) is at least in part dependent on how browsers deal with certificates that are expired.

In any event I was not sure how the most recent versions of browsers were handling these cases so I dug up an example site where an expired certificate was in use (https://www.appliancetherapy.com – it uses a certificate that expired a few weeks ago and has not as of yet been replaced).

So what did I want to find? In a perfect world I believe that the following should be true:

  1. Users are warned or prohibited from going to the site in question.
  2. The warning language used is easy to understand and explains the risks.
  3. The warning language used is related to the fact that the certificate is expired.
  4. The trust indicator does not show or is marked to indicate that there is a problem.

The good news is that for the most part browsers behaved fairly close to this, they all could have improved language but I believe Internet Explorers was the best.

The worst behaving client was Mozilla, as it doesn’t report the certificate as expired but instead indicates that it tried to make an OCSP request but got a response it was not expecting. This has two problems – the first of which being it should not have made an OCSP request for the status of an expired request.

RFC 5280 Section 5 states that:

 

   A complete CRL lists all unexpired certificates, within its scope,

   that have been revoked for one of the revocation reasons covered by

   the CRL scope.  A full and complete CRL lists all unexpired

   certificates issued by a CA that have been revoked for any reason.

 

And RFC 2560 is written largely based on OCSP responses being fed from CRLs. What this means is that it is not appropriate to ask the revocation status of a certificate that is expired.

The next problem is that Mozilla also doesn’t handle the unauthorized response in a usable way. RFC 5019 Section 2.2.3 states:

 

   The response “unauthorized” is returned in cases where the client

   is not authorized to make this query to this server or the server

   is not capable of responding authoritatively.

 

A user who receives this message would believe the issue is related to their permissions but based on the true reason for the error the failure as really that the responder in question doesn’t have the information that’s needed.

This lack of information on the server is likely due to the fact that it isn’t required to maintain information for expired certificates and the message Mozilla delivered should have been about the certificate being expired.

In any event the browsers behaved much better than I expected, IE and Chrome did the best (I really like Chromes red / over the https as a visual queue there is a problem).

 

 

Chrome

Internet Explorer

Mozilla

Opera

Safari

 

How to tell DV and OV certificates apart

Leave a reply

Introduction

There are in essence three kinds of SSL certificates: Domain Validated, Organization Validated and Extended Validated. I am not going to write about the differences here it seems that there are hundreds of articles on this topic on the Internet.

What I think has not been given sufficient coverage is how one is able to look at a certificate and determine what type it is.

One would think that this would be easy; In theory if nothing was explicitly stated it would be a Domain Validated certificate (since it is the weakest validation), otherwise someone would put something in the certificate making it clear that the certificate was either Organization Validated or Extended Validated.

Unfortunately it’s not this simple, the main issue being the historic lack of coordination within the CA industry.

Each Certificate Authority (CA) has its own unique practices relating to how they mark their certificates so with the existing deployed certificates there is no singular rule or approach can be used to definitively know what level of validation was done for a given certificate.

Thankfully it looks like that this problem is betting better thanks to the adoption of the Baseline Requirements but in the meantime we have to make do with heuristics.

Deterministic Approach

Today the only way to know with confidence that a certificate is of a specific type is to know the practices of each CA.

In X.509 the way an issuer is supposed to express something like this is via the Certificate Policies extension which is defined in RFC 5280.

This allows a CA to express a unique identifier (an OID) in their certificates that maps to a document that describes its practices associated with this certificate. This identifier can be used programmatically to do make trust decisions about a certificate or to differentiate the user interface in an application based on what type of certificate is being used.

This is exactly how browsers today can tell if a certificate is an Extended Validation (EV) certificate. In essence they have some configuration that says “I trust GlobalSign to issue EV certificates, when a certificate is presented to me from them that has this policy OID show the EV user experience”.

The Baseline Requirements use the same approach defining identifiers for Domain Validated and Organization Validated certificates, these are:

Type Policy Identifier
Domain Validated 2.23.140.1.2.1
Organization Validated 2.23.140.1.2.2

 

Having these identifiers takes us a long way towards our goal of deterministic evaluation of certificate issuance policy — that said not all CAs have adopted them which is technically alright since the Baseline Requirements do allow them to use their own Policy Identifiers.

Heuristic Approach

Since the Baseline Requirements were only established this year it will take some time for the existing install base of certificates to be re-issued to use these Policy Identifiers called about above. This doesn’t mean you can’t tell the certificates apart today, it does mean it is quite a bit messier though.

Here is some pseudo-code provided to me as an example from a friend that they used in one of their projects:

type = null;

if (cert is self-signed) then

     type = SS;        /* SS = Self-signed */

else if (cert was issued by a known “CA”) then

     type = DV;  /* DV = Domain Validation */ else if (cert contains a known EV Policy OID) then

     type = EV;  /* EV = Extended Validation */ else if (cert “Subject O” and “Subject CN” are the same or “Subject OU” contains “Domain Control Validated”) then {

     if (cert contains no Subject L, St or PostalCode) then

         type = DV;

}

else if (cert “Subject O” is “Persona Not Validated” and the cert’s issuer was StartCom

     type = DV;

if (type is null)

     type = OV;

This logic is not comprehensive but should work well enough for most uses.

Summary

Unfortunately today there is not a deterministic way to tell if a certificate was Domain or Organization Validated, that said things are changing and within a few years hopefully it will be possible.

In the mean-time there are heuristics you can use that help tell these types of certificates apart.

Updated my script for Qualified Subordination testing

1 Reply

I did some testing with ECC and SHA2 today and as such decided to update my script for testing Qualified Subordination to make it easy to get certificates that use these algorithms.

There are now several configurable variables in makepki.bat:

  • key = possible values include RSA or ECC
  • rsasize = possible values include 1024,2048,4096
  • eccsize= possible values include secp256r1,secp384r1,secp521r1
  • hash = possible values include sha1,sha256,sha384,sha512

With these its very easy to get chains to do testing with that include these algorithms, have fun.

Ryan

Using SHA2 based signatures in X509 certificates

6 Replies

It’s been an exciting decade for cryptography; as a result we see smaller key sizes and weaker algorithms getting deprecated.

One driver of such things is the U.S. Federal Government, specifically NIST.

One example of this would be NIST Special Publication 800-131A which disallows the use of SHA1 after December 2013. What this means is if you are in the U.S. Federal Government or you work with them you may have to revise your technology strategy to use SHA2 in its place.

But what if you don’t have any policy mandate forcing you to do this switch? Well it’s a good idea but it has consequences too, namely compatibility.

You see SHA2 was published in 2001 so anything produced before then will not support it. The most notable example is Windows XP which as of July 2012 has about 29% presence on the Internet.

This is important for more than just Internet Explorer users since even Chrome and Safari use CryptoAPI for certificate validation when on Windows.

The good news is that XP SP3 which was released in 2008 added support for this new suite of hash algorithms, that begs the question how many of those XP machines have XP SP3?

Unfortunately I don’t have any public references that can answer this question but let’s that 85% of all XP machines on the Internet have gotten this update (I have good confidence in this number) that means that 15% of those 29% would not be able to connect to your server over SSL if you used SHA2.

This would mean these users would see something like this:

 

 

That is pretty scary, so how long until we can use this more broadly? It’s hard to say there is a good article titled “The developers guide to browser adoption rates” that sheds some light, that and the historic gs.statcounter.com results. Based on these unless there is a sudden change (which is possible these machines are getting pretty old) I would assume that we have around 4-5 years of XP out there yet.

Hope this helps,

Ryan

Government CAs in the Microsoft Root Program

2 Replies

Microsoft was the first Root program in a browser to have an open and transparent process for becoming a CA as well as the first to have public policy, audit and technical requirements that CAs must comply with.

Today while the other browsers have joined on and even raised the bar significantly Microsoft continues to operate their root program in an open and clear way.

One example of this is the list they publish of the companies who meet their requirements; you can see this list here.

There are a number of interesting things we can gleam from this list; one of them is how many governments have their own certificate authorities.

For example as of March 11, 2011 we know that there are a total of 46 government owned and operated “Root Certificates” in the Microsoft Root Program, these include:

Current CA Owner Country Thumbprint
Government of Austria, Austria Telekom-Control Commission Austria e7 07 15 f6 f7 28 36 5b 51 90 e2 71 de e4 c6 5e be ea ca f3
Government of Brazil, Autoridade Certificadora Raiz Brasileira Brazil 8e fd ca bc 93 e6 1e 92 5d 4d 1d ed 18 1a 43 20 a4 67 a1 39
Government of Brazil, Instituto Nacional de Tecnologia da Informação (ITI) Brazil ‎70 5d 2b 45 65 c7 04 7a 54 06 94 a7 9a f7 ab b8 42 bd c1 61
Government of Finland, Population Register Centre Finland fa a7 d9 fb 31 b7 46 f2 00 a8 5e 65 79 76 13 d8 16 e0 63 b5
Government of France France 60 d6 89 74 b5 c2 65 9e 8a 0f c1 88 7c 88 d2 46 69 1b 18 2c
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) d6 da a8 20 8d 09 d2 15 4d 24 b5 2f cb 34 6e b2 58 b2 8a 58
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) e0 92 5e 18 c7 76 5e 22 da bd 94 27 52 9d a6 af 4e 06 64 28
Government of India, Ministry of Communications & Information Technology, Controller of Certifying Authorities (CCA) India 97 22 6a ae 4a 7a 64 a5 9b d1 67 87 f2 7f 84 1c 0a 00 1f d0
Government of Japan, Ministry of Internal Affairs and Communications Japan 96 83 38 f1 13 e3 6a 7b ab dd 08 f7 77 63 91 a6 87 36 58 2e
Government of Japan, Ministry of Internal Affairs and Communications Japan ‎7f 8a b0 cf d0 51 87 6a 66 f3 36 0f 47 c8 8d 8c d3 35 fc 74
Government of Korea, Korea Information Security Agency (KISA) South Korea 5f 4e 1f cf 31 b7 91 3b 85 0b 54 f6 e5 ff 50 1a 2b 6f c6 cf
Government of Korea, Korea Information Security Agency (KISA) South Korea 02 72 68 29 3e 5f 5d 17 aa a4 b3 c3 e6 36 1e 1f 92 57 5e aa
Government of Korea, Korea Information Security Agency (KISA) South Korea f5 c2 7c f5 ff f3 02 9a cf 1a 1a 4b ec 7e e1 96 4c 77 d7 84
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 63 4c 3b 02 30 cf 1b 78 b4 56 9f ec f2 c0 4a 86 52 ef ef 0e
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 20 cb 59 4f b4 ed d8 95 76 3f d5 25 4e 95 9a 66 74 c6 ee b2
Government of Latvia, Latvian Post Latvia 08 64 18 e9 06 ce e8 9c 23 53 b6 e2 7f bd 9e 74 39 f7 63 16
Government of Latvia, Latvian State Radio & Television Centre (LVRTC) Latvia c9 32 1d e6 b5 a8 26 66 cf 69 71 a1 8a 56 f2 d3 a8 67 56 02
Government of Lithuania, Registru Centras Lithuania 97 1d 34 86 fc 1e 8e 63 15 f7 c6 f2 e1 29 67 c7 24 34 22 14
Government of Macao, Macao Post Macao SAR ‎89 c3 2e 6b 52 4e 4d 65 38 8b 9e ce dc 63 71 34 ed 41 93 a3
Government of Mexico, Autoridad Certificadora Raiz de la Secretaria de Economia Mexico 34 d4 99 42 6f 9f c2 bb 27 b0 75 ba b6 82 aa e5 ef fc ba 74
Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State Portugal ‎39 13 85 3e 45 c4 39 a2 da 71 8c df b6 f3 e0 33 e0 4f ee 71
Government of Serbia, PTT saobraćaja „Srbija” (Serbian Post) Serbia d6 bf 79 94 f4 2b e5 fa 29 da 0b d7 58 7b 59 1f 47 a4 4f 22
Government of Slovenia, Posta Slovenije (POSTArCA) Slovenia ‎b1 ea c3 e5 b8 24 76 e9 d5 0b 1e c6 7d 2c c1 1e 12 e0 b4 91
Government of Slovenia, Slovenian General Certification Authority (SIGEN-CA) Slovenia 3e 42 a1 87 06 bd 0c 9c cf 59 47 50 d2 e4 d6 ab 00 48 fd c4
Government of Slovenia, Slovenian Governmental Certification Authority (SIGOV-CA) Slovenia 7f b9 e2 c9 95 c9 7a 93 9f 9e 81 a0 7a ea 9b 4d 70 46 34 96
Government of Spain (CAV), Izenpe S.A. Spain 4a 3f 8d 6b dc 0e 1e cf cd 72 e3 77 de f2 d7 ff 92 c1 9b c7
Government of Spain (CAV), Izenpe S.A. Spain ‎30 77 9e 93 15 02 2e 94 85 6a 3f f8 bc f8 15 b0 82 f9 ae fd
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) Spain a0 73 e5 c5 bd 43 61 0d 86 4c 21 13 0a 85 58 57 cc 9c ea 46
Government of Spain, Dirección General de la Policía – Ministerio del Interior – España. Spain b3 8f ec ec 0b 14 8a a6 86 c3 d0 0f 01 ec c8 84 8e 80 85 eb
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain 43 f9 b1 10 d5 ba fd 48 22 52 31 b0 d0 08 2b 37 2f ef 9a 54
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain b8 65 13 0b ed ca 38 d2 7f 69 92 94 20 77 0b ed 86 ef bc 10
Government of Sweden, Inera AB (SITHS-Secure IT within Health care Service) Sweden 16 d8 66 35 af 13 41 cd 34 79 94 45 eb 60 3e 27 37 02 96 5d
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎6b 81 44 6a 5c dd f4 74 a0 f8 00 ff be 69 fd 0d b6 28 75 16
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎25 3f 77 5b 0e 77 97 ab 64 5f 15 91 55 97 c3 9e 26 36 31 d1
Government of Taiwan, Government Root Certification Authority (GRCA) Taiwan ROC f4 8b 11 bf de ab be 94 54 20 71 e6 41 de 6b be 88 2b 40 b9
Government of The Netherlands, PKIoverheid The Netherlands 10 1d fa 3f d5 0b cb bb 9b b5 60 0c 19 55 a4 1a f4 73 3a 04
Government of The Netherlands, PKIoverheid The Netherlands 59 af 82 79 91 86 c7 b4 75 07 cb cf 03 57 46 eb 04 dd b7 16
Government of the United States of America, Federal PKI USA 76 b7 60 96 dd 14 56 29 ac 75 85 d3 70 63 c1 bc 47 86 1c 8b
Government of the United States of America, Federal PKI USA cb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5
Government of the United States of America, Federal PKI USA ‎90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia 30 70 f8 83 3e 4a a6 80 3e 09 a6 46 ae 3f 7d 8a e1 fd 16 54
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia d9 04 08 0a 49 29 c8 38 e9 f1 85 ec f7 a2 2d ef 99 34 24 07
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) Turkey 1b 4b 39 61 26 27 6b 64 91 a2 68 6d d7 02 43 21 2d 1f 1d 96
Government of Uruguay, Correo Uruguayo Uruguay f9 dd 19 26 6b 20 43 f1 fe 4b 3d cb 01 90 af f1 1f 31 a6 9d
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎dd 83 c5 19 d4 34 81 fa d4 c2 2c 03 d7 02 fe 9f 3b 22 f5 17
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎39 8e be 9c 0f 46 c0 79 c3 c7 af e0 7a 2f dd 9f ae 5f 8a 5c

 

With a closer look we see that these 46 certificates are operated by 33 different agencies in 26 countries.

 

Wikipedia tells us there are 207 governments and now we know apparently 14% of them operate their own globally trusted root.

 

Though I love to travel and I consider myself a citizen of the world I have never needed to communicate with any of these governments using their private PKIs so I personally have marked them as “revoked” in CryptoAPI, I also manage which of the commercial root CAs I trust manually.

There are some other interesting observations we can gleam from the Root Program membership also, I will do more posts on these later.

Serving OCSP POST responses on a CDN

Leave a reply

The other day I did a blog post on how we are using a CDN to front our OCSP services, the CDN we are using is CloudFlare who is one of our partners.

In that blog post I mentioned that POSTs requests from an OCSP client would normally be a cache miss for a CDN and this introduces additional latency in serving these responses.

Even though the response times we were getting had this additional latency the performance was still acceptable but we wanted to do better so a few weeks ago I went to the CloudFlare office and worked with them on making their services OCSP aware.

Specifically we made it so that when they get an OCSP POST they can determine what cached response to return (for example from a prior GET) instead of going back to our responders to have our responder do that for them.

As of today this change has gone live, as you know I love numbers which is why I have been publishing these repository performance numbers. What you will see if you look at those is that our worldwide average is right around 100ms, if we take out china and Australia that figure drops to around 60ms.

The problem with these numbers is they only test the GET variant of the protocol, that is because neither Pingdom nor Monitis let me simulate binary POSTs (which is what the OCSP POST variant looks like).

With that said we can extrapolate what the numbers look like fairly easily; from my current network location (which is slow) this is what I see:

 

 

What I want you to notice here is that over 15 requests when I do a POST to the CDN instance of our responder I get the same response time average as I do when I perform the same test with the GET variant.

What this tells us is that POST is performing the exact same as a GET which from this we can safely say that in our case the performance numbers I have been publishing for GET are also accurate for POSTs.

What you will also see that our responder is slower to server via POST, this is because it is designed around nonced OCSP requests and as such isn’t optimized as much as it could be for caching them.

I should also note that our decision to put a CDN in front of our OCSP responder does not break clients that want to send nonced requests (no browsers do by default btw), these are simply treated as a cache miss.

Ryan

How to seed the CryptoAPI URL cache with an OCSP response

Leave a reply

It is possible to “staple” an OCSP response into higher level protocols such as TLS. This concept has been supported in Windows since Windows VISTA, shortly after it was added to OpenSSL/Apache and soon it will also be in Nginx.

When “stapling” is used the subscriber (the web server in the TLS case) requests the status of his own certificate from the OCSP responder his CA operates to get a time valid OCSP response for his own certificate.

Since the OCSP response is signed by the CA it can be relayed by the web server for the duration in which that OCSP response is time valid to save the client of the web server (the relying party, aka the browser) the need to make an additional socket connection back to the CA.

This has both performance and privacy benefits.

You can apply the same concept to other PKI related protocols/applications as well, for example in a document signing application like Adobe Acrobat. In such an application the subscriber might sign the document, timestamp it using a timestamp protocol like RFC 3161 and then attach a time valid OCSP response to it so that the document is verifiable at a later date.

This scenario is important not only for its performance and privacy benefits but because it is a practical necessity because CAs do not typically maintain revocation information (OCSP responses and CRLs) for expired certificates.

By stapling the OCSP response to the signed and time-stamped document the relying party can verify the signature, the certificates and the revocation status of the certificates in the context of the timestamp that was attached to the document.

But how do you do that with CryptoAPI?

It’s actually pretty straight forward, as the relying party when you call CertGetCertificateChain to validate the associated certificate you need to:

  1. Once you have verified your timestamp is cryptographically valid and trusted, take the time it and pass it in as pTime.
  2. On the CERT_CONTEXT there is a CERT_INFO structure that contains an array of CERT_EXTENSION, here you create an extension of type CERT_OCSP_RESPONSE_PROP_ID and in there you put a basic signed OCSP response .

When CryptoAPI does the chain validation it will try to use the OCSP response you passed in, if it finds a problem with the provided response it may go online to get a new one that is “OK”.

This online behavior can be controlled by indicating to CertGetCertificateChain you do not want online revocation checking (see CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY).

Ryan

CryptoAPI, Revocation checking, OCSP and the Unknown certStatus

1 Reply

In CryptoAPI one can use the CertGetCertificateChain API to do the path building and basic chain validation, this validation may include revocation checking depending on which flags you pass via dwFlags; for example these flags control if revocation checking occurs, and if so, on which certificates:

  • CERT_CHAIN_REVOCATION_CHECK_END_CERT
  • CERT_CHAIN_REVOCATION_CHECK_CHAIN
  • CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT

Typically you would specify CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT which ensures the whole chain is checked (where possible – e.g. one shouldn’t bother asking the root if he considers himself revoked).

But in the context of OCSP what are the potential revocation related returns we might see?

  1. Revoked – I have received a signed response from the CA or have had policy pushed to me that tells me that this certificate is not to be trusted.
  2. Not Revoked – I have received a signed response from the CA that says this certificate was not revoked.
  3. Unknown – I have received signed response from the CA that says it doesn’t know anything about this certificate.
  4. Offline – I was unable to reach the responder to verify the status of the certificate.

Each of these cases are clearly represented in the API that is used by CertGetCertificateChain to perform the revocation check, this API is CertVerifyRevocation. The higher level CertGetCertificateChain however only has two possible returns: Revoked and Unknown outside the “not revoked” case.

One might assume the OCSP Unknown would get mapped into the Revoked state, this unfortunately is not the case, it is returned as unknown, as does the Offline error.

This means that if OCSP was used you cannot tell what the actual status was, this is especially problematic since IE and Chrome both default to modes where they ignore “Unknown” revocations due to concerns over Revocation responder performance and reliability.

It is possible to work around this platform behavior though — the problem is that it’s not documented anywhere, let’s take a quick stab at doing that here.

First since CertGetCertificateChain doesn’t tell us what method was used to do revocation checking we have to use heuristics to figure it out. Thankfully to enable OCSP stapling in higher level protocols like TLS the OCSP response is passed back to the caller if OCSP was used; to get that we need to know:

1. The CERT_CHAIN_ELEMENT in the returned CHAIN_CONTEXT points to the following revocation information:

  • PCERT_REVOCATION_INFO pRevocationInfo;
  • PCERT_REVOCATION_CRL_INFO   pCrlInfo;
  • PCCRL_CONTEXT           pBaseCrlContext;

2. For an OCSP response, the CRL_CONTEXT is specially created to contain the full OCSP response in the following critical extension szOID_PKIX_OCSP_BASIC_SIGNED_RESPONSE.

  • The presence of this extension indicates an OCSP response was used.
  • The Issuer name in the CRL is the name of the OCSP signer.
  • The signature algorithm is sha1NoSign.
  • ThisUpdate and NextUpdate contain the response validity period.

With this we can take the OCSP response from the CRL_CONTEXT and then look at the “ResponseData” within it, you will need to look within the “responses” here,  you will need to find the right “SingleResponse” based on its “CertID”.

NOTE: Some responders will return the status of multiple certificates in a response even if the status of only one was requested.

You now can determine what the responder said the status of the certificate was by inspecting “certStatus” element.

This is a fair amount of work unfortunately but it does enable you to do the right thing with authoritative “Unknown” responses.

Ryan

Serving OCSP on a CDN

5 Replies

So last week we moved our revocation repositories behind a CDN, this has a number of great benefits but it does have downsides though, for example.

  1. Cache misses result in a slower response – About a 110ms in my tests.
  2. OCSP clients that create POSTs get a slower response – This is because they are treated like a cache miss.

Our CDN provider mitigates much he first issue by having a pre-loader that ensures its cache is pre-populated based on request history.

Addressing the second issue requires the CDN provider to be aware of OCSP protocol semantics, specifically the fact that one can compute what a GET request would look like by simply Base64 encoding the binary body of the POST variation.

A CDN with knowledge of this can optimize out the POST derived cache miss, our CDN has done this the change has not yet propagated to all of their datacenters but where it has POST performs the same as a GET.

Hopefully this optimization will have propagated to all their datacenters by next week, when this logic is fully deployed the clients that generate POST based OCSP requests (without a nonce) will also have ~100ms response times.

I should probably ad that in our case almost all of the POST based OCSP requests we receive come from Firefox and do not contain a nonce, hopefully soon Firefox will move to using GET for requests without a nonce like other clients.