Multiple certificates for single domain

Help
#1

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:

  1. Fix Postfix myself (not an actual option for me)
  2. 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)
  3. Drop the must-staple option from the cert (I’d really like to use the feature though)
  4. 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).

Thanks for reading so far
Georg

[0] http://postfix.1071664.n5.nabble.com/OCSP-stapling-td93718.html

1 Like
#2

You could do two certs, one with Must-Staple and one without:

certbot --apache --cert-name example.com -d example.com --must-staple

and

certbot certonly --cert-name example.com-no-staple -d example.com \
-a apache --deploy-hook "service postfix reload"

so you’d end up with: /etc/letsencrypt/live/{example.com,example.com-no-staple}

2 Likes
#3

Thanks, that was an easy one it seems.
Very quick!

1 Like
#4

What does must-staple actually do? Why do you like it so much?

1 Like
#5

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.

1 Like
#6

The must-staple flag says: “A valid OCSP-response is required”.

So it requires a working OCSP-stapling of a webserver.

I use it with the *.server-daten.de certificate.

After a OS reboot FireFox complains with a special error message -> hitting F5 helps.

Must wait some hours, then I can copy the error message from the test system.

PS: Checked my list of certificates from “check-your-website”:

0 66329
1 182

182 certificates use OCSP must staple.

66329 not.

0,27 %.

2 Likes
#7

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.

1 Like
#8

213,614 trusted Let’s Encrypt certificates with status_request value for TLS Feature extension out of 249,712,332 total = 0.86% according to Censys - pretty close to your number.

1 Like
#9

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…

Thank you all for your thoughts and contributions

#10

I get why staple, and I think is good. I don’t understand why must-staple.

#11

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.

#12

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)

#13

I’m not sure if you are not actually missing the point.
The question is not if the private key is compromised, but if the cert is revoked or not.

#14

I was going a step ahead, to “steal” a certificate you need access to the private key.

#15

PS: Now I have the error message:

If the webserver is fresh, FireFox complains:

MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

and blocks the connection. Because the server didn’t sent the required Staple.

Hitting F5 is enough (if the certificate isn’t revoked).

1 Like
#16

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.

#17

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.

#18

Yes, that’s an one-time - problem.

My test system stops if it isn’t used -> cached OCSP response is deleted.

New start some minutes later -> FireFox complains.

The productive system runs -> no problem.

#19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.