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?
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.
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.
--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)
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.
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