Hi, I’m using Certbot to manage a whole bunch of certificates and renewing them with a cron-job whenever they are due. All this worked really well until when I recently turned on OCSP must-staple for the main domain (where the same cert is used for different services).
While the webserver staples the OCSP responses properly (thats why I enabled it), the mail server (postfix) does not do and does not plan to [0].
Now, I have several options:
Fix Postfix myself (not an actual option for me)
Have unstapled certs with must-staple and tell all the mail clients to deal with it (since it is not just me on the mailserver, but quite a number of people, thats also not a feasible option)
Drop the must-staple option from the cert (I’d really like to use the feature though)
Use different certs for webserver and mailserver.
Option 4 is the one I’d like to go with, and therefore I wonder whether certbot can handle more than one certificate for a domain. While the multi-purpose cert would be the one with must-staple and would include a number of subdomains, the simple non-stapling cert would need to be only for the plain domain.
Any hints on how to configure certbot how to obtain this are very welcome.
In case this is not feasible, I’d like to get suggestions on how else to obtain this (preferrably in an automatable manner, e.g. via a different ACME client for the plain cert).
OCSP (online certificate status protocol) is the smart way of certificate revocation checking.
In the beginning, we had revocation lists - basically text files the browser had to search through. This did not scale very well.
Then, people came up with OCSP, where you ask the issuing authority if the cert is still valid. This was good, but led to privacy problems and had no proper fallback when the OCSP service was not reachable (either because of downtime or because of an attacker blocking access).
Thats when people came up with OCSP stapling. Instead of putting the burden on the client, the server obtains a fresh OCSP rely and staples it to the cert, proving that the cert is still valid. It is basically a shortlived (couple of hours/days) proof of certificate validity.
Read more background in Scott Helmes blog.
I think people still mostly avoid it because OCSP stapling implementations are still a bit rough around the edges - Apache httpd for example has a lot of problems doing it properly - so it can be easy to “DoS” yourself as a server operator, if there’s an OCSP outage at the CA.
I agree that OCSP might not the ultimative solution to certificate revocation, but since it exists and works for me with nginx (we have been stapling before must-staple) I’ll use it for now, until a better solution comes along.
Lack of adoption definitely is a problem though.
on the other hand, this thread was initially less about OCSP and more about certbot and multiple certs for the same domain name. Might come in handy in other cases as well…
Oh, yes, forgot that step. Basically inscribe in the cert that it is not valid without an OCSP staple, so that if a malicious attacker strips the OCSP from the cert, it is not valid anymore.
So, if an attacker gains control of a private key, a client knows that it must receive a stapled ocsp response. Cool. And if the legitimate operator revokes the cert, the window of vulnerability is smaller (with modern clients only)
Ah, I see. Yes, to abuse the cert you would need to get hold of the private key. Only then you would want to avoid the client to find out that the cert is revoked already.
Yes, I had that issue with nginx as well initially. The problem is, that the webserver does not wait for the OCSP request to succeed and starts a connection with the client, without a staple becaus is has none.
Afterwards the OCSP response is cached and available for further replies.
How this was actually solved I don’t remember, but afaik this is not an issue anymore.