Would you use the
ISRG Root X1 signed certificates in your chain already than?
Would you use the
Server could signal which certificate he trust. And an client can not. It would not be an good idea to replace it.
But it would be an great option if there is an acme way to request X1 intermediate. It would be possible to use it
via ssl fingerprint and deliver it only to these nightly firefox versions. Like some people propose it with legacy validated certificates.
Or they should do what Comodo does for browser compatibility
The private key for
ISRG Root X1 is held offline most of the time, and requires a fair amount of preparation and planning to bring it online with proper procedures. We’ve been working on that, and will do it.
Note that we will continue to recommend that you serve the
DST Root X3-signed intermediates for some time to come, because are still much more broadly trusted.
Providing an alternate Intermediate means setting up a bunch more systems, probably real hardware not just a VM too since a public CA like Let’s Encrypt keeps the actual keys in physical devices (Hardware Security Modules) to protect them from being stolen by some sophisticated software attack on the CA.
Once the current Intermediates are signed, you can (though I advise you should not due to compatibility risk) show either of their certificates to a client to form a complete chain, because those certificates have the same Subject (e.g. “Let’s Encrypt Authority X3”) and the same Public Key Information, and it matches the key which signed your certificate.
@jsha I’m just curious, isn’t the same work required to sign the CRL of the root with the root itself? If I remember correctly the CRL is updated (and signed) every three months, why the new certificates wasn’t signed with the last update of the CRL? There was some legal rather than technical issue?
Why is there no public announcement that you have signed X3 and X4 with ISRG Root X1?
I found it only because I found the website code on GitHub and watched the commits
Not valid before: Thursday, 6 October 2016 15:43 UTC
Quite enought time for an public announcement I think. Also I only found out that you have ECC enabled in the production environment by a tweet on google. You should really made this more clear by blogging more about such important thinks or something else.
Oh I’m a derp, that was the change to the website.
Did some tests
It appears having both the ISRG root and the LetsEncrypt root works fine like I described the proposal above.
Browsers are pretty forgiving towards broken certificate chains. Running something like curl with GnuTLS might not go as well (though i certainly haven’t tried personally).
I’ve never used GnuTLS personally for anything I do.
Tested GnuTLS installed on OS X 10.11, got verify failures unless it was installed on the order shown here.
- Certificate info: - subject `CN=REDACTED', issuer `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', RSA key 4096 bits, signed using RSA-SHA256, activated `2016-10-06 REDACTED', expires `2017-01-04 REDACTED', SHA-1 fingerprint `REDACTED' Public Key ID: REDACTED Public key's random art: REDACTED - Certificate info: - subject `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', issuer `O=Digital Signature Trust Co.,CN=DST Root CA X3', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', SHA-1 fingerprint `e6a3b45b062d509b3382282d196efe97d5956ccb' - Certificate info: - subject `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', issuer `C=US,O=Internet Security Research Group,CN=ISRG Root X1', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-10-06 15:43:55 UTC', expires `2021-10-06 15:43:55 UTC', SHA-1 fingerprint `1b23675354fcad90119d88075015ea17add527d8' - Certificate info: - subject `C=US,O=Internet Security Research Group,CN=ISRG Root X1', issuer `C=US,O=Internet Security Research Group,CN=ISRG Root X1', RSA key 4096 bits, signed using RSA-SHA256, activated `2015-06-04 11:04:38 UTC', expires `2035-06-04 11:04:38 UTC', SHA-1 fingerprint `cabd2a79a1076a31f21d253635cb039d4329a5e8'
Could you give me the link to the ECC stuff? Because end-leaf certs with a ECC public/private keypair was already possible and in the Upcoming Features-page there’s no mentioning of this…
@josh is our man for this.
Second problem I found ist that the Google Icarus Log only accepts ISRG Root X1 and not the cross-signed from IdenTrust. So I currently need to separate the process of adding the trust path because Icarus log reject my cert if I supplies more then one chain even if booth of them are valid and accepted from the log. https://bugs.chromium.org/p/chromium/issues/detail?id=632753
Here is the ECC announcement: https://twitter.com/letsencrypt/status/697504441075798016
But on Windows, Mac, Android and iOS I needed to trust the root leaf.
@jtl What “method”? Let’s Encrypt just sends the leaf certificate plus the X3 intermediate signed by ISRG Root X1. The second path you’re seeing on SSL Labs is figured out by SSL Labs itself: the leaf certificate mentions
http://cert.int-x3.letsencrypt.org/ for potential download to complete the chain. While this isn’t necessary (the X3 signed by ISRG Root X1 is send by the server already), it does enable clients to complete the second chain.
I’m sure this is something that happened “by accident”, as all leaf certificates have the URL to the X3 intermediate signed by DST Root X3 embedded into them.
I think he means serving both LEAX3(ISRG Root X1) and LEAX3(DST Root X3) as part of the chain. Tecnically an RFC5246 violation, but it works. That way we can demo serving a cert that chains to ISRG Root X1, but also make sure the site validates if people visit in a browser that doesn’t yet include ISRG Root X1.
I understand the RFC5246 violating method, but @jtl says “seems like (…) uses I [sic] method I suggested”, while SSL Labs clearly states the X3 intermediate chaining to DST Root CA X3 has to be downloaded. So Let’s Encrypt servers don’t send it So as a result it doesn’t uses the method @jtl suggested methinks.