Universities / enterprise blocking endpoints behind a LE certificate


I've been getting some reports, mostly from universities and some companies that they cannot connect to one of my servers. This server/API is behind haproxy and it uses a LE certificate, managed by me. I also use LE on an API hosted on heroku (so in that case the LE cert is not managed by me but by heroku).
It seems that the firewall tend to block the server that I manage but not the Heroku's one.

One customer told me once that the company blocks traffic coming from endpoints with an LE certificate.

Is there anything I can do to improve this by still using LE? Would a paid SSL improve this?

Thank you

1 Like

You just make people complain.

That blocking policy is overbroad. Do not negotiate with terrorists.


That sounds like a misunderstanding. Let's Encrypt has active certs covering over 80 million registered domains and over 275 million FQDNs. That's a lot of endpoints to be blocking

That said, if you share your domain name we can take a look at your certificate configuration and give further advice.


Thank you for your quick replies!
@MikeMcQ the (sub)domain in question is: couch.bomist.app

That domain name sends the alternate "short chain" from Let's Encrypt. Older Android devices will not connect successfully as they need the default long chain. Nor will any devices that have very old CA Root Certificate stores that do not include ISRG Root X1. This ISRG root is over 5 years old but we have seen cases of people having old stores. Often it is easy to instruct how to update those stores once the oper sys and version is known.

You must have chosen the short chain as the default from LE is the long chain such as used by this forum site. More info on those below.

Maybe switching to the long chain would help but realize there are tradeoffs. Some people that need to support a wide variety of old systems that cannot be updated have needed to use a different certificate authority (ideally a free one like ZeroSSL or others). Maybe have those people try connecting to https://letsencrypt.org and if that works the long chain would help you too.


The root itself is over 5 years old, but there is no guarantee it will be in trust stores younger than it.

Initially that would suggest a problem with the Chain selection that @MikeMcQ noted, however...

I would want to know exact what the customers are running that can connect and that can not connect.

  1. Those that can not connect might be running incompatible operating systems/browsers. see Certificate Compatibility - Let's Encrypt

  2. The difference in connectivity could be due to implementation details of the entire application. For example, the Heroku system might be fine because it is being accessed via Web Browsers or web libraries with updated trust stores, while this couchdb api might be accessed via a library that is relying on OpenSSL or similar. For example, a Python app might work on an updated system because Requests uses a modern certifi package, while some other calls might be relying on OpenSSL and an outdated trust store.

  3. Either of the above might also be influenced by the openssl version. This ties into the chain selection (as mentioned by others). Newer versions have patched in support for building alternate chains, while older versions do not.


(default) Renewal should have been triggered four days ago.
Which ACME client are you using, and how are the renewals being scheduled?

1 Like

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