If certbot is ran fully automatic, all will be well anyway. If the server admin configures it manually, there’s an unknown amount of time between certificate issuance and server installation… So… How would Let’s Encrypt check that? And why is it the responsibility of Let’s Encrypt anyway?
The difference between not being installed yet, and being installed incorrectly can be detected automatically by software. If the new cert is served, but without the intermediates, that’s incorrect, if some other cert is served (or there’s nothing on 443) then the new certificate isn’t (yet) on a web server.
Let’s Encrypt have the advantage here that they do have email addresses for some subscribers, so they could email those people after say, 48 hours whereas a third party like me could only try to crawl their site for an email address and hope that helps.
On the other hand I’m not convinced this is so common that it’s worth a lot of effort to address in bulk. Individual savvy end users can and should prod server admins hey, your TLS config is wrong, fix that. Maybe certbot could add a “check I did it right” mode? I know a few commercial CAs have a web page where you can check you installed their cert correctly, basically it just connects to your server and checks the chain is well-formed. Let’s Encrypt could add one of those, or just point to one from their FAQ.
I think such a vaguely worded general mail would be unhelpful, causing needless concern and confusion. If we saw this on, say, 50% of Let’s Encrypt protected sites it might be worth doing, but my impression is it’s maybe more like 1%
It’s definitely the single most common configuration error that people mention on the forum. I would like to find more things that can be done about it, but I don’t think sending e-mail to subscribers is likely to be an ideal solution.
Apache from version 2.4.8 behaves like Nginx in terms of accepting intermediate certs in the same file with domain certificate (making SSLCertificateChainFile parameter obsolete). So giving the file name like fullchain-nginx.pem would be misleading.
Considering that 2.4.8 is dated March 2014, you could say that the two most popular web servers do not need “cert.pem” and “fullchain.pem” - they just need a straightforward named “certificate.pem” containing domain’s and issuer’s cert.
Basically kill the confusing “fullchain.pem” and put a note that for AWS Services or old Apache you would need to split the content of “certificate.pem”, and that should reduce the amount of configuration mistakes.
Why not do a few checks at renewal time? The systems are making connections at that time anyway (assuming http verification of course), and that way it’ll show up in the job output. Still assuming administrators actually read that, but there’s only so much you can do.
