We have a service running behind https and we are using SSL certificates from Let's Encrypt. The problem is that one of our clients distrusts Let's Encrypt CA and on certificate renewal it requires to us to send the newly generated certificate in order to add it to the trust chain.
Is this a common practice?
Which are the reasons to distrust certificates from Let's Encrypt?
This is an old policy.
Getting a certificate was difficult and expensive, which prevented malicious people from getting it, which made it an easy way to identify "trusted" sites.
Because LE allows anyone to get a certificate, then it allows malicious people to get a certificate and get that "green lock" and the symbol of "trust". In response, some organisations added a rule to not accept LE certificates so that sites that used them would not be "trusted".
As misguided as this is.
Very large corporate sites now use LE, so this policy makes no sense.
So, I would work with the client to change their policy. From my experience, organisations that added this rule quickly rescinded it and I have not heard of an organisation with it still in place.
There are three classes of certificates:
Domain validated certs are just that: you simply need to demonstrate control over a domain e.g. by a presenting a specific HTTP resource.
For OV and EV, there are additional requirements of the CA to verify ownership of the domain. An EV certificate requires the most proof. It requires proof of identity of the requestor and verification of their employment at the company that owns the domain.
As you have likely surmised if you are familiar with Let's Encrypt, it issues Domain Validated certs.
I think the most illustrative example of the potential risk of DV certs (relative to OV and EV certs) is an attack against a Brazilian Bank and its customers that involved the attackers issuing Let's Encrypt certificates for the bank's domain.
In a nutshell, the attackers compromised a DNS registrar account for the bank. This allowed them to register IPs under their control to the banks domain. They then used this to get Let's Encrypt issued certificates for the domain. When customers then went to their bank's website, they were directed to a proxy site which presented a 100% valid certificate for the bank.
Requiring an OV or EV certificate prevents/mitigates the above approach. Getting a fraudulent certificate of these classes would require much more effort and risk on the part of the attackers than simply remotely gaining control of a single account.
Unfortunately (IMO) browsers have moved away from distinguishing between these and more and more people assert that DV certs are just as good as OV and EV certs.
I think there may be some confusion as to how this applies to the original question. If my company wants to call web services that your company hosts (or I require mTLS for you to call mine), my servers are going to be configured to point to a specific endpoint. There's no browser or lock icon involved. When my client calls the webservice, it will verify that the certificate is good and in this case, that it's an EV cert from a CA I trust. If an attacker is able to take control of my DNS, they can add a new host and get me to go there but unless they have a valid cert for the domain, the call will terminate before any data is passed. If I allow DV certs, it's game over: the attacker simply get's an LE cert and my web service client will happily transmit data to the attacker's server.
certificate renewal it requires to us to send the newly generated certificate in order to add it to the trust chain
This is called 'certificate pinning'. The reason they are insist on this is that if someone were to issue a fraudulent DV cert from LE, they would not trust it. They are depending on a trusted representative of your company to verify its authenticity. Likely, they are in a situation that if they trust LE as a CA, they become vulnerable to these domain-based/DV attacks on all of their similar dependencies. It occurs to me that using LE to sign your certificate is pointless here. It's essentially a self-signed cert.
SSL certificate doesn't confirm validity, reliability or credibility of the related party. It has sole purpose of encrypting data transaction between two terminals. (Like one being a server which hosts a web site and another one being your browser by which you browse that website.) (A note: there is also Extended Validation (EV) SSL but that's another point.)
So there is absolutely no reason to distrust Let's Encrypt SSL because there is absolutely nothing different between Let's Encrypt and any other certificates you paid for, in terms of what they do.
And for that matter, there is also nothing different between self-signed certificate and any SSL you bought. For example there are many public and government intranet applications which use their self-signed certificates, just to encrypt data between terminals. In the end, if you can trust yourself, then you can issue yourself a certificate, can't you? Your application can perfectly work with this certificate just like it would with Let's Encrypt or a paid one.
The only difference with using your own-forged (i.e. self-signed) certificate is that your system will probably require you to store your Certificate Authority (CA) certificate in the certificate pool of your system; because the system won't recognize you as a CA automatically. Systems are set to use a predefined list of these authorities to "automatically trust" the certificates they issue. This is the only difference.
I am not saying "you can use self-signed certificates in your web site". And I am not saying we can use our own certificates and everyone should add us as a CA in their pools. I am just saying there is no technical difference in the certificate. As there are many intranet applications of which the authority usually asks you to add them as a trusted CA in the user's pool. Like for example a government agency uses a self-signed certificate for their application and asks their users to download and include their CA certificate in their pools. I know some entities do it for even public applications.
If your client had an old system which required more manual work, once they add Let's Encrypt as CA in their system, they shouldn't be asking you to send the certificate each time after renewal; because their system should recognize the issuer already. There must be something very specific to their system. So no, it's not common practice.
You can understand from here that it is not important that the browser is warning you that your certificate is insecure. Because it doesn't actually warn you about the certificate itself; it is warning you that it didn't recognize the issuer. (Of course we are talking about a valid self-signed certificate here.) To test this, just change your computer date to 50 years from now. And refresh this very page and your browser will tell you the certificate of Stack Exchange, this very site, is insecure. Well, is it? It was secure a second ago? The site and the certificate didn't change; but the browser recognized the validity period and thought that it is expired.
This is also why you don't usually use self-signed certificates on web sites. Because you can't hardcode yourself as a CA on the browser's list. That's the only reason why you wouldn't use it; but as you see, there is technically no reason why you can't.
To sum up, let alone distrusting Let's Encrypt, I think that it is a very very long overdue that the internet community didn't have it before. Free and automated SSL certificates should have been a standard years ago.
