How do I import Let's Encrypt Trusted CA certs into Radware?

Hi guys,

We recently switched to Let's Encrypt and need to import the Trusted CA certs into Radware.
After we request the certs, we got a bunch of .cer files like cert.cer, fullchain.cer, chain.cer, chain0.cer and chain1.cer. We imported them into Radware and applied to the domains. We saw the issuer is changed to R3 however it shows only 2 certificates instead of 3. See below:

|Certificates provided|2 (2641 bytes)|
|Chain issues|None|
|#2|
|Subject|R3
Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=|
|Valid until|Mon, 15 Sep 2025 16:00:00 UTC (expires in 3 years and 3 months)|
|Key|RSA 2048 bits (e 65537)|
|Issuer|ISRG Root X1|
|Signature algorithm|SHA256withRSA|

I checked with other Let's Encrypt certified domain. It has 3 certs and includes ISRG Root X1. see below:

Certificates provided 3 (3835 bytes)
Chain issues None
#2
Subject R3

Fingerprint SHA256: 67add1166b020ae61b8f5fc96813c04c2aa589960796865572a3c7e737613dfd
Pin SHA256: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=|
|Valid until|Mon, 15 Sep 2025 16:00:00 UTC (expires in 3 years and 3 months)|
|Key|RSA 2048 bits (e 65537)|
|Issuer|ISRG Root X1|
|Signature algorithm|SHA256withRSA|
|#3|
|Subject|ISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=|
|Valid until|Mon, 30 Sep 2024 18:14:03 UTC (expires in 2 years and 3 months)|
|Key|RSA 4096 bits (e 65537)|
|Issuer|DST Root CA X3|
|Signature algorithm|SHA256withRSA|

Does that mean something got missed when imported the Trusted CA certs? which cert files I should use to import? and which cert file is Trusted CA and which one are intermediate certs?

Thanks,

Lewis

2 Likes

Hi @freebird, and welcome to the LE community forum :slight_smile:

There are two trusted LE chains.

  • the "short chain"
    This is NOT the default chain
    But it can be requested through the ACME client [or by manually editing the chain files]
    This chain ends with the self-signed LE root ("ISRG Root X1")

  • the "long chain"
    This one uses the cross-signed LE root ("ISRG Root X1")
    This complete chain also requires having the "DST Root CA X3" in the "trusted location"
    [this chain was provided to include older systems that don't already have the LE cert in their trust stores]

6 Likes

Thanks, rg305. so you meant the CA cert we got is the "short chain" with self-signed LE root and doesn't need "DST Root CA X3"?

Also do you know which cert files we should use to import to create CA and intermediate certs? I have fullchain.cer, chain.cer, chain0.cer and chain1.cer. the cert.cer file we know is used for the domain. What other .cert files do?

Thanks again!

Lewis

1 Like

No, the chain you showed seems to be the long one:

6 Likes

Self-signed "root certs" should never be sent by web servers nor CAs.
They should already be in the trusted root store [inserted by the operating system itself].
That said, whenever one does need to manually do anything like that, one must go get the root cert(s) from their trusted provider(s).
You do see "ISRG Root X1" in the chains provided because that isn't the self-signed version - that is the one signed by "DST Root CA X3" [which isn't included in the chain, because self-signed roots are never sent].

See: Chain of Trust - Let's Encrypt (letsencrypt.org)

10 Likes

I am not finding from the CA/Browser Forum nor Baseline Requirements Documents (SSL/TLS Server Certificates) how OSes stay up-to-date for the trusted root store. Did I miss it some place?

5 Likes

That's not really in scope for the CAB, especially not for the BR's.

In short, some vendors run Root Programs. Those decide which certificates they want to trust and define criteria for this. The vendors then regularly update their trust stores based on developments in the root program.

The following major root programs exist:

  • Mozilla: Mozillas root program is what the NSS/Firefox trust store is sourced from. Many other tools without their own program also source from Mozilla (Linux distributions for example). Trust store updating varies depending on the vendor, Mozilla uses regular NSS releases for new roots.
  • Microsoft: Used primarily in Windows. Microsoft has a live update mechanism to distribute new roots without requiring explicit OS updates.
  • Apple: Used in Apple products. Trust store updates only via OS upgrades.
  • Oracle: Used primarily in Java. Trust store updates via JRE updates.

There are more root programs, but these ones cover the major market. Obviously Let's Encrypts root is included in all of the above.

11 Likes

Clarifying:

The trusted CA Cert is the root certificate(s). If they do not appear in your is/library/application’s trusted root store, you can get them from LetsEncrypt’s website and import them.

When you run an acme client, you do not get those certs - but should not need them. They’re really only needed by end-users (unless your service requires them to be available).

The client obtains:

  • An end-entity or leaf certificate (your domain(s))
  • A chain certificate (the certificate(s) chaining trust from the trust root to the end entity).
10 Likes

Google has an upcoming chrome root program.

The Mozilla program is probably the most popular because other projects utilize it as @Nummer378 said. How? There are several projects that regularly extract their roots and then repackage them for language/platform usage. For example, in the Python’s ecosystem, this is done by Certifi.

10 Likes

Though also note that Mozilla wants people to be wary of just using their root list without understanding what the list of known roots is and isn't supposed to be used for:

13 Likes

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