I've problem, my mobile clients using intermediate certificate for verification that stored on mobile.
Old chain
root : ISGR Root X1
ca intermediate : X3 Authority
But after updating i got new root so new intermediate certificates. New Chain
root : DST Root CA X3
ca intermediate : R3
So my clients unable to verify domain.
What can i do to solve it without updating clients ?
Is it possible to generate new certificate chain using predefined CA Root like ISRG Root X1 ?
How can i do it with certbot ?
Yes server send intermediate cert but problem that chains broken cause intermediate Old X3 doesn`t match new R3. How can i solve that ?
I've just generating new cert but it has the same new chain : DST Root CA X3 -> R3 -> domain.
On https://letsencrypt.org/certificates/ i saw that ISRG Root x1 still available so its possible to get chains:
ISRG Root X1 -> X3 -> domain.
"LetsEncrypt R-series" intermediates are now active
LetsEncrypt currently provides possible two chains for your order. Both are signed by the Private Key in "LetsEncrypt R3". The first option is the default "LetsEncrypt R3" certificate, which is signed by "ISRG Root X1"; the second option is the "Cross-Signed LetsEncrypt R3", which is signed by "DST Root X3" (which expires in 2021).
The LetsEncrypt ACME server provides all this information to clients via the API.
Your clients seem to be hardcoding the Intermediate and possibly the Root certificates. That is an error in your design. The Intermediates can change at any time, and one of the root certificates will expire shortly.
We are using different words for the same thing (my chain being your intermediate)
Deciding the correct chain/intermediate is really important for mobile clients though — ISRG is not installed on many active mobile platforms.
How is your system set up and doing that root switch? Is Firefox recognizing the LetsEncrypt intermediate has a crosssign available and substituting isrg for the dst?
There is nothing, that's the point. It's a normal Windows 2019 server with an IIS 10.
And it's only one certificate ( crt.sh | 3754094313 ), not something like "If this client, send this, if that, send that" or two certificates (RSA and EC).
Only installed (creating the pfx, loaded in the Machine\Webhosting), nothing else.
That should not be possible. You are serving the R3 intermediate that was cross-signed by DST CA Root X3, so there is no connection in that certificate chain to ISRG X1 Root. While the two intermediates share the same PrivateKey, that's it. Perhaps your version of Firefox, a plugin, or something in your computer is recognizing the cross-signed X3 intermediate and switching it to the one signed by ISRG.
Certificate viewer on OSX Firefox versions (tried legacy and current) show the correct chain.
I've long noticed that some browser user interfaces are either:
Lying about the path used to validate certificate trust, or
Have some kind of weird intermediate caching/sharing going on, where if they can find a matching public key in an intermediate encountered on a different website, they will use it to build the path.
You can have a server with a fullchain that clearly builds a path to Identrust, but the browser shows a path to the ISRG Root. Like wtf mate? I always check the path with OpenSSL now.
I think that is what is going on with @JuergenAuer's situation. On a version of my cert manager, I had been aggregating cross-signs via public keys... but I couldn't figure out how to do this with EC so killed the feature. I need to borrow a windows machine to see what is going on with Windows' Firefox.
I think the browser is effectively trying to convince you that the end-entity certificate is valid, rather than trying to help you see whether the site's configuration is correct or is what you expected. The browsers seem to have given up on the latter thing some time ago.
