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?
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.
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 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.
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.