Why can't LE supply the users the Root Certificates for uploading to devices. I need to put it on my Fortinet 61F firewall. I found a E5_CA_Cert.cer that is good till 2027. Godaddy supply us the Intermediate and Root Certificate, when we download the certificate from them.
You can find all of our roots on Chains of Trust - Let's Encrypt
4 Likes
How do I download them?
Visit the page linked by @mcpherrinm then click on the links on that page to download the certs.
4 Likes
As you've already been shown, they do. But really, it should be a vanishingly-rare circumstance where users have a need for this. That's the purpose of a publicly-trusted certificate of the sort that Let's Encrypt issues: it's signed by a root certificate (through intermediates) that is already universally trusted. That's why nobody needs to download or install a root cert to browse to any of the millions of websites using Let's Encrypt certs.
(remainder of post censored)
6 Likes
Fortinet needs to fix it on their end. SSL Labs report showed I was missing the CA certificate chain. I needed to add it to the Fortinet. Which is strange because Fortinet allows Let's Encrypt Certificates to be created on the firewall. I will be contacting Fortinet about it.
Just because Let's Encrypt uses certain standards and believes in its product, doesn't mean Godaddy, Fortinet and others follow your standards. It would be great if everyone worked together. I was on Godaddy for over a decade. I switched because Fortinet adopted it in FortiOS.
Maybe they need to make it more obvious where it was on that page who be my only suggestion. Also, add the openssl code to extract it from the fullchain.
openssl s_client -showcerts -verify 5 -connect wikipedia.org:443 < /dev/null |
awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){a++}; out="cert"a".pem"; print >out}'
for cert in *.pem; do
newname=$(openssl x509 -noout -subject -in $cert | sed -nE 's/.*CN ?= ?(.*)/\1/; s/[ ,.*]/_/g; s/__/_/g; s/_-_/-/; s/^_//g;p' | tr '[:upper:]' '[:lower:]').pem
echo "${newname}"; mv "${cert}" "${newname}"
done
I was able to use this script to extract the pem files from fullchain.pem. E5.pem and my certifcate.pem.
....IOW, you were missing the intermediate cert. You didn't need to download the root cert to get that, as I said:
That the intermediate cert was the issue is further demonstrated by the fact that you were able to extract it from fullchain.pem (though there was likely no reason to do so; ordinarily you'd also have cert.pem and chain.pem files that would do the trick).
This has nothing to do with Let's Encrypt's "standards;" it's the way the web PKI works. Root CA certificates (which are what you started this topic by asking about, but you've now shown them to be irrelevant to your problem) are embedded into every OS/browser--that's how they know what certs to trust. If you could just serve any root CA cert, and client software would automatically trust it, it would completely defeat the purpose of a publicly-trusted CA. The root cert is thus not a part of the fullchain.pem file or any other output from most ACME clients (certainly not from any of the most-popular ones).
Some explanation in case this distinction isn't clear: AFAIK, no public CA today signs leaf certs (i.e., the certs for your particular device or domain) using its root certificate. Instead, the root cert signs a handful of intermediate certs, and then is kept offline for security reasons. Those intermediate certs are then used to sign leaf certs and/or other intermediate certs (which in turn sign leaf certs). Everyone trusts the root, the root signs the intermediate, that intermediate might sign another intermediate (there's only one intermediate in any given chain with LE, but other CAs might use two or more), the intermediate signs a leaf cert. A server (your firewall, in your case), needs to serve every intermediate cert in the chain and the leaf cert, but should not serve the root cert (and it should be ignored by any client devices). Again, none of this is specific to Let's Encrypt; this is web PKI 101.
If their software will obtain certs from Let's Encrypt, and then fail to serve the intermediate cert, that's a definite bug on their end.
5 Likes
So you fall into the trap of would of, could of, should of. LE isn't the industry standard yet. Fortinet barely supports it fully. LE is free. Linux is free. Manufacturers don't make money off of free. I have been doing networking since 1982. I was there in the beginning. I installed Torvald's first version of Linux. I have seen it all.
My web servers are behind my Fortinet 61F. The Let's Encrypt certificate was created as a Deep scan certificate on the 61F for the virtual web sites. In order to get SSL Labs to work and get A+ score on the each site, I had to add the E5 CA to the 61F. That was the solution. It doesn't matter what LE position is. I had to add the E5 certificate to the 61F. Fortinet doesn't have it in their vast CA store for and unknown reason. I will take that up with Fortinet. Fortinet doesn't do IPv6 very well either. It does do a great job protecting my servers and home. SSL Labs reported the broken chain because Fortinet didn't provide it properly from fullchain.pem. Extracting the E5.pem file and installing it on the 61F, fixed the issue. Godaddy provides their intermediate and root certificates as part of the package. I have 11 NFRs (New Feature Requests) at Fortinet.
I spend a lot of time on cyber security sites because it is my job. You don't need to quote the LE Bible. I wished everything worked and was made easy.
So far, I like LE other than having to extract the certificates every 2 months to upgrade the Fortinet. I will spend time on scripting to move the web servers certificates to Fortinet in the future. I can be done.
Intermediate or root cert?
Because the required intermediate is perfectly send by Let's Encrypts ACME server.
If the ACME CLIENT messes up the handling of this, then you can hardly blame Let's Encrypt for that, right?
So please don't blame Let's Encrypt for the failures of others.
4 Likes
The E5 is an intermediate ECDSA cert. Let's Encrypt will randomly issue your ECDSA leaf using E5 or E6. What you are describing is what is called "pinning" of an intermediate and that is not good practice.
The chains are described here: Chains of Trust - Let's Encrypt
Are you willing to post the domain name you are having problems with? We can probably give a more precise explanation.
4 Likes
Or does the CA/Browser Forum set the standards to which all publicly trusted CAs must adhere, including Let's Encrypt?
3 Likes
No, it's a perfectly well-known reason, and one which I've already explained to you: the E5 cert is an intermediate cert. It should be served along with the leaf cert. Every CA operates this way. If your Fortinet device is not serving that intermediate, it's either user error (you're pointing your device to the wrong cert file), or a bug with Fortinet.
But you seem either unwilling or unable to learn from me--carry on.
4 Likes
Using this online tool https://chainchecker.certifytheweb.com/ yields one interesting result
Let's Encrypt Modern Chain (May not support some older devices)
This Let's Encrypt chain uses the newer ISRG Root X1 root, which is trusted by current operating systems. This chain may cause issues for some old devices, particularly Android 7.1 and lower.
Edit
Also here you can find Deprecated curves in RFC 8422, several of which are being shown used here ( search for Supported Named Groups) SSL Server Test: www.scsiraidguru.com (Powered by Qualys SSL Labs)
3 Likes
Intermediates are required by the "Baseline Requirements" - https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.1.2.pdf
This is clearly implied by sections 5.2.2 and 6.1.1, there may be some explicit declarations as well. They state the Root Certificate Private Key for every CA's Trusted Root is required to be securely stored offline and with minimum access. Every CA is required to sign certificates with Intermediates, which must be generated by a compliant key ceremony that is audited by a certified third party.
LetsEncrypt often has the smallest number of intermediates (1 in most situations), Commercial CAs often utilize multiple levels of intermediates for internal business reasons.
I am just posting the above for clarification to @danb35. I want to remind everyone to not interact with arguments, and to please consider not interacting at all when conversations have clearly run their course.
5 Likes
Thank you for the clarification. I figured LE had just one CA because the pem file had 2 sections only. Godaddy has 3 for cert, intermediate and root.
Also here you can find Deprecated curves in RFC 8422, several of which are being shown used here ( search for Supported Named Groups) SSL Server Test: www.scsiraidguru.com (Powered by Qualys SSL Labs)
Thanks for the information on RFC 8422
1 Like
Yes, however Let’s Encrypt has two Root CAs as shown in the Chains of Trust - Let's Encrypt
Namely ISRG Root X1 (RSA 4096) and ISRG Root X2 (ECDSA P-384) already shown
by @mcpherrinm here Download Root Certificates for LE - #2 by mcpherrinm and @MikeMcQ here Download Root Certificates for LE - #10 by MikeMcQ
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.