internetstandards
Deployment certificate improvements
Currently the setup is a single 4K RSA certificate from Let's Encrypt (LE): https://github.com/internetstandards/Internet.nl/blob/118b8b87fa9d1b6f0898bf16de9027012d403347/docker/webserver/certbot.sh#L45-L60
Also, at first a certificate for only the main domain is requested (to prevent blocking if one of the subdomains is not configured), but this gives an extra certificate, even if the setup is done correct: https://github.com/internetstandards/Internet.nl/blob/118b8b87fa9d1b6f0898bf16de9027012d403347/docker/webserver/certbot.sh#L36-L38
It could be improved for increased support, better performance and robustness by:
- Dual certificate RSA + EC in nginx (use full RSA and EC chain).
- Dual certificate from different root (e.g. LE and ZeroSSL (Sectigo): funny fact is that they use LE on their website), more details about the currently 5 free ACME providers: https://acmeclients.com/certificate-authorities/
- Use accounturi in CAA for Let's Encrypt (waiting for #1107).
- For robustness it would be great if the certificates do not expire on the same dates but the 'not After' is 45 days shifted with the other certificate (e.g. by prematurely renewing one of the certificates the first time).
Cons:
- Larger ServerHello in TLS handshake.
- More complex docker code.
Additional: certbot should refresh the certificate if the list of additional domains changes, to account for removal of hostnames.
Discussed with @aequitas & @mxsasha: the current behavior of a two-stage request is desired, note to perform the Live tests as specified in the documentation after a deployment (linked in Deployment > Testing your installation).
After thoughts: could also change from two-stage to optimistic approach and explicitly report the FAILED_DOMAINS, and have an overwrite / fallback to root domain only, if this of course doesn't add endless complexity to the shell scripting.
Also discussed the alerting fatigue of the (not yet setup) Let's Encrypt certificate alerts. And concluded that a full endpoint check on the deployed certificate is best. I noted I liked the cert_check of mailcow, note they also have a acme_check which alerts on ACME errors in the log, might be useful too. Related:
- #1264
- #1272
Update on this: dual certificate setup can fail if one of the certificates fails, since the server will pick on of the chains (related to the cipher support). So it's only more robust if on the server side:
- Expiry is checked (and filtered)
- Check for (draft RFC) Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension, which is supported by Let's Encrypt since 2023-03-23.