Hi;
I configured OCSP stapling and it works great when the certificate's OCSP status is "good". However, when the certificate is revoked, the site stops sending OCSP certificate responses and browsers take time before recognising this certificate as revoked.
Is there a way around this issue? and is there a way to disable the OCSP result when the server consults the OCSP responder. This way the server always checks with the responder?
Kindly
Wasfi
The behavior of OCSP Stapling is entirely up to the server implementation. It would help to know what server you are using.
NGINX Server using ubuntu
Some very popular browsers never check OCSP status. Maybe the server is doing the right thing but the browser is not. What Browser are you seeing this with?
Firefox, but when the certificate is revoked, NGINX stops sending OCSP status although it checks with the responder and gets a revoked certificate result.
nginx does ocsp stapling as cache, it only staples if it see valid state.
Assuming ssl_stapling_verify is on, yes. Otherwise it passes it through unchecked.
I would advise @wbounni against turning off stapling verification though (as that makes the stapling prone to caching bogus responses as well) and ask what use case is being solved here.
X.509 certificate revocation is broken. The technology has fundamental issues - certificates not being seen as revoked when they are is very common. Many implementations do not check for online revocation at all (e.g. Chrome does not talk to OCSP servers, nor does it fetch CRLs live). Therefore, what you're seeing is often expected: A server will typically not send a "bad" (i.e. revoked) stapled OCSP response (why should it? That would just break the connection) and an increasing number of clients won't bother doing OCSP themselves.
Firefox is one of the browsers that offers a live OCSP query, but it's a best-effort implementation that is cached, so you won't always see revoked certificates immediatly. This feature is also disabled by default IIRC.
Browsers are currently implementing some sort of stopgap by making CRLs popular again (A New Life for Certificate Revocation Lists - Let's Encrypt, Firefox CRLite + Chrome CRLSets). However, for the long term future we will likely push towards very short certificate lifetimes which gives us passive revocation (Good certificates die young: what's passive revocation and how is it implemented?).
I would generally advise to never rely on working certificate revocation for anything. It's nice to have the option to revoke certificates, but it is far from being a reliable method.
Thank you Nummer. In this case, if my certificate needs to be revoked as its associated private key is compromised, can I rather than revoke it, can I renew it using certbot. I mean I will not revoke it but simply renew it. Would certbot in this case generate a new private key and request the certificate from let's encrypt? Or would it still use the old CSR associated with the compromised private key?
Certbot's default is to create a new private key. Here are the parts from its docs
--reuse-key When renewing, use the same private key as the
existing certificate. (default: False)
--no-reuse-key When renewing, do not use the same private key as the
existing certificate. Not reusing private keys is the
default behavior of Certbot. This option may be used
to unset --reuse-key on an existing certificate.
(default: False)
--new-key When renewing or replacing a certificate, generate a
new private key, even if --reuse-key is set on the
existing certificate. Combining --new-key and --reuse-
key will result in the private key being replaced and
then reused in future renewals. (default: False)
I marked you answer as the solution although all answers should be marked this way. Thank you all.
For a compromised key, the best way is to first replace the certificate using a new key. Then, once the new certificate is in place, revoke the old one.
Is that also the case when the OCSP response is stapled?
Now that I think about it, if a server doing OCSP stapling sees that its current cert is revoked, it should probably just abort that request and refuse to serve anything else using the same certificate until it gets a new certificate (either by the server administrator updating it or by an integrated ACME client automatically getting a new certificate for it). Sending the client a stapled revoked response doesn't make any sense, but really neither does sending no stapled response at all but continuing anyway since you know your communication may be compromised. I suspect most servers aren't that smart about things, though.
Well, I was not thinking of stapling when I wrote that even though the title of the thread clearly stated it. My bad. I was more interested on what browser was used to get a fuller picture of their query.
I think Nummer's response on this is more complete.
In my defense 
... I don't think nginx stapling support is very good so I would never think to use it.
Server and browser config and interactions for stapling is a complex topic.
Agreed
Various traditional webservers (nginx, Apache) are written in a "the administrator is above all else"-setting. They don't care what certificate they're serving: Be it self-signed, expired, revoked, corrupt or whatnot. They don't usually make assumptions about their intended use: Perhaps the administrator wants to use revoked certs for a weird experiment? Who knows. These traditional webservers also don't have a way of obtaining new certificates*, so there's nothing they can reasonably do. Refusing to outright start may cause outages, which is something they never want to do. "Run at all costs" is the premise here. I mean, nginx doesn't even verify OCSP responses by default and will happily pass through "revoked" stapled responses unless explicitly configured to "not do that". Doing any kind of cert status checks is way above them, really.
Stuff like this is something for modern webservers that actually have some integration into the cert ecosystem. Caddy for example actively watches for revoked certificates and immediatly replaces them if it detects that an in use certificate is revoked.
*Ignoring Apache's mod_md here, because it's an addon written much more recently
In addition to very nice cert support, mod_md also has much better stapling support than the base Apache (which is poor)
I should mention this is a great example of why we need acme clients embedded into the servers.
Caddy, for instance (yes I made it yada yada) staples OCSP automatically, and when it sees a Revoked status, will automatically replace the cert and rotate the key if the reason is Key Compromise.
Caddy also caches staples to disk and reuses them in case responders go down and shares staples across a cluster. All this happens automatically.
But as mentioned above, revocation is broken and we actually need shorter cert lifetimes instead.
This is the way 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.