ISRG Root X1 added to Firefox for next release

ISRG/Organizational
21

Would you use the ISRG Root X1 signed certificates in your chain already than?

22

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.

23

Or they should do what Comodo does for browser compatibility :slight_smile:

24

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.

25

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.

26

@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?

3 Likes
27

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

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.

2 Likes
28

It’s here too
https://letsencrypt.org/certificates/

1 Like
29

Oh I’m a derp, that was the change to the website.

1 Like
30

Did some tests

It appears having both the ISRG root and the LetsEncrypt root works fine like I described the proposal above.

31

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).

32

I’ve never used GnuTLS personally for anything I do.

33

OK

Tested GnuTLS installed on OS X 10.11, got verify failures unless it was installed on the order shown here.

- Certificate[0] 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[1] 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[2] 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[3] 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'
34

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…

35

@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.

36

8 posts were split to a new topic: Cross-signing followup

37

Seems like the new LetsEncrypt root test site uses I method I suggested :slight_smile:

iAPPmV9.png1570×1216 195 KB

1 Like
38

@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.

39

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.

1 Like
40

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 :wink: So as a result it doesn’t uses the method @jtl suggested methinks.