Create certificate using predefined ca root

Help
#1

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 ?

#2

Hi @hsnamed

that's

the old root certificate, from DST, not from ISGR.

May be your server doesn't send the new intermediate certificate.

What's your domain name with that problem?

#3

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.

#4

Your server sends the wrong intermediate certificate.

Your question is already the answer.

#5

The question is "how can i get new chain with
root: ISRG Root X1
intermediate: X3
exactly using certbot ?"

#6

No, that's not the question.

Your server has to send the correct intermediate. And the old intermediate will not longer work.

So your configuration is buggy and that's something you have to fix.

PS: Read the documentation - --preferred-chain allows a switch.

But the new ISRG Root X1 may use the new R3 too - so you have exact the same problem with the ISRG root.

3 Likes
#7

Thanks for all, I've read that intermediate Let’s Encrypt Authority X3 is retired , so impossible to get it with --preffered-chain, that`s sad.

#8

An intermediate can change at any time.

So don't rely on them.

3 Likes
#9

Indeed, hardcoding the X3 intermediate in your mobile client was a serious design flaw.

1 Like
#10

Just adding to what others said:

  • "LetsEncrypt X-series" intermediates are retired.
  • "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.

2 Likes
#11

Additional:

Normally, it's not required to select one chain.

server-daten.de has a new R3 certificate.

My FireFox says, ISRG is the root. OpenSSL says, "DST Root" is used. Same with Chrome running under Windows.

Installing the correct intermediate certificate is always required.

1 Like
#12

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?

1 Like
#13

There is nothing, that's the point. It's a normal Windows 2019 server with an IIS 10.

And it's only one certificate ( https://crt.sh/?id=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.

Then checked with FireFox and OpenSsl.

1 Like
#14

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.

Screen Shot 2020-12-11 at 5.38.12 PM
Screen Shot 2020-12-11 at 5.38.12 PM579×605 21.9 KB

1 Like
#15

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.

2 Likes
#16

It's the standard Windows FireFox, nothing else.

And that behaviour isn't new, that FireFox shows the ISRG root.

The old InternetExplorer 11 shows the DST root.

#17

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.

#18

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. :frowning:

3 Likes
#19

I just wanted to clarify that the information cited above is not entirely accurate. It should read:

Old Chain
Intermediates:

  • Let's Encrypt Authority X3 signed by DST Root CA X3 (cross-signed)
  • Let's Encrypt Authority X3 signed by ISRG Root X1

New Chain
Intermediates:

  • R3 signed by DST Root CA X3 (cross-signed)
  • R3 signed by ISRG Root X1

DST Root CA X3 expires 14:01:15, Sep 30, 2021 GMT.

#20

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