Due to concerns about insufficient ISRG root propagation on Android devices we have decided to move the date on which we will start serving a chain to our own root from July 8, 2019, to July 8, 2020.
So, I can understand that the full certificate chain (ISRG-X1 -> LEA-X3, etc) is not yet recognised by some user-agents, okay. I check this page https://valid-isrgrootx1.letsencrypt.org/ and see my user-agent / browser (Chrome) recognises the certificate as Let's Encrypt Authority X3 (LEA-X3); and not ISRG-X1. Which tracks the article announcement, however I am still trying to understand:
Does this mean that a renewed LEA-X3 SSL certificate will be recognised as issued by ISRG-X1 due on and after July 8, 2020?
Why? - Because an API I plan to depend on requires a CA from a list, one of those listed is ISRG-X1; so I can delay my charity project release to co-inside with the delay (~20 days) or try to find an alternative.
Sub-question: how might I obtain an SSL certificate issued by ISRG-X1?
I think you just checked the "Security" tab on your Chrome developer toolbar (F12), right? Like this screenshot:
However, if you look closely, you'll see this LEA-X3 intermediate certificate chains to the ISRG X1 root if you click on "View certificate" and go to the tab "Details":
So you see even though it might not be directly recognised as the ISRG root, it does chain to that root certificate.
If you mean by "recognised" "will it show the ISRG root when I open the developer toolbar and check the "Security" tab": no. It will still contain the LEA-X3 intermediate certificate, because end-leaf certificates are always signed by an intermediate and never by the root certificate.
That is not and will never be possible. The ISRG root private key is kept offline and Let's Encrypt only uses the ISRG root certificate/private key in key signing ceremonies when a new intermediate needs to be signed.
However, you can use certificates chaining up to the ISRG root by just using the other LEA-X3 certificate. Because the public/private keypairs is the same for the intermediate certificates with the same "X number", you can use whichever intermediate certificate you want to use.Don't want to wait until July 8? Change your LEA-X3 signed by the IdenTrust root for the LEA-X3 signed by the ISGR root. Don't want to chain to the ISRG root even after July 8? Manually force the intermediate certificate to be the LEA-X3 signed by the IdenTrust root.
Technically.... while no consumer 'Certificate Requests' will be signed into 'Server Certificates' by the root, the intermediate certificates are signed by the ISRG-RootX1 root.
If the OP is just looking to test the chain, there are options on Chain of Trust - Let's Encrypt
for "Certificate Authority" certs that are Cross-Signed by (Identrust) OR those only signed by ISRG Root X1.
For example, with the LetsEncrypt Authority X3 Certificate....
If you read "obtaining" exactly the same as "download an intermediate certificate", yes, you're absolutely correct. However, I read it as "get an end leaf certificate issued directly by the ISRG Root", which is not possible.
OP already found that page as his post clearly states.
Can I ask a followup question: What is the API you are planning to integrate with? Is it a webhook style API? Or something else? That will affect our answers about how it works. Also, what web server are you using?
As a brief intro: When you get a certificate from Let’s Encrypt, it will be issued by “Let’s Encrypt Authority X3.” There are two certificates with that Subject, one signed by ISRG Root X1 and one signed by DST Root X3. When you configure your web server, you can choose whichever of those certificates you want, depending on your needs. For your needs, it sounds like you should configure the one that’s signed by ISRG Root X1. It should go in the certificate “chain” (see your web server’s documentation for details). Note that your ACME client, as of right now, will autoconfigure the DST Root X3-signed version as your chain, so you will need to do a small amount of manual configuration.
Thanks @Osiris, @jvanasco and @jsha for your replies, the correction and clarifications.
@jsha indeed, the DST Root X3 is also in the supported list, and is indeed the “chain” certificate set within my Nginx web server’s configuration.
The API is a webhook style API, with LINE. Ordinarily, I would ask for the specific approach to address webhook API connectivity, however the webhook linkage has now verified as connected. I have made no changes since posting the earlier question, and 18 hrs later the connection is working.
What might cause such a problem and then solution to occur with only time passing? Thanks,
Oh interesting! I hadn't gathered from your initial question that you had already tried, and gotten an error. Did you get an error message from LINE? Without knowing what the error was it's hard to know what resolved it, or if it was even certificate related at all.
Thank you @jsha. The API-side verification tool error simply read Received incorrect HTTP code - expected 200, no other details; and I have no packet tracking records on the client-side.
My diagnostics process is: The API-side must have the DST Root X3 pem and the ISRG Root X1 pem certificates. API-side must have a working process to verify signage of certificates (except for an unlikely outtage) and establish the tokenised (channel and secret tokens) handshake before or after initialising the HTTPS channel. The tokens must have been completed a process of approval, while being issued. Client-side certificate must have been provided (via certbot into the nginx configuration) and served during a callback request. This leaves a possibility that the DNS path was not found, due to a newly set-up DNS A Record (and local subdomain configuration within nginx). Perhaps that was it, a delay in DNS record propagation.
Many thanks to your kind community for the support in helping me bounce-back ideas and clear up my understanding. ^^
Most likely, if the API tool got as far as receiving an incorrect HTTP code, it had already successfully connected and validated your certificate by then. So the problem was probably at a different level - maybe your web server served up a 404 or a 500.
