Lots of people Incorrectly configuring Lets Encrypt on their servers

So yeah.

Pretty sure this ties into https://github.com/certbot/certbot/issues/2026

Mind you this happened when i went to wget Multiverse for my minecraft server (meaning i’m not hosting the server i’m trying to get the files from.)

From what i’ve read this issue is caused by people using cert.pem instead of fullchain.pem as the publicly available ssl certificate.

And i do not get this issue on my domain and i’m using fullchain.pem which means that people are incorrectly configuring their websites.

If you guys can notify people somehow that they are incorrectly configuring their websites, that would be great.

Originally posted On github. Issue number #3159

1 Like

How did you have that in mind?

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.


As far as I know, certbot recommends checking your server with SSLLabs, so that’s already covered.


I mean like a global email saying that many people still have incorrectly configured servers.
Or is that not feasible?

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.

Why not add a copy of fullchain.pem as fullchain-nginx.pem and make clear in docs

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.

1 Like

true maybe chain-nginx.pem, chain-apache22.pem and chain-apache24.pem :slight_smile:

Something like certOnly.pem, chainOnly.pem and cert+chain.pem might be better.

1 Like

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.

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