Questions re: Beginning Issuance from R3

Issuance Tech
#1

Not sure if makes sense to continue this here or if I should have started a new thread, but I've got a few questions relating to what's in the announcement:

In the immediate future (earliest possible: today; latest possible: December 16th) we will begin issuance from our new R3 intermediate.

This link in crt.sh I think goes to the initally-revoked cross-signed intermediate. Should it maybe go to https://crt.sh/?id=3479778542 or https://crt.sh/?caid=183267 instead?

As usual, this will take the form of a phased rollout, beginning with us issuing a few certificates for ourselves, then allowing issuance in staging, then switching Prod to issue from R3. We will update this thread when these stages are in progress.

Can you clarify what it means that you'd be "allowing issuance in staging", when staging (I assume) wouldn't be signing from the real production R3? (Or maybe it will do "real" signing for some short length of time for testing?) Is it just that there would be new intermediates that will be started to get used in the staging environment? (And if so, I'd kind of expect that the order would be different, that staging changes would happen before issuing internal-to-Let's-Encrypt certificates?)

So since E1 isn't going to be in use just yet, I just want to confirm that elliptic curve leaf certificates will just get signed by R3 once that goes live? That is to say, the "R" just means that the key for the intermediate itself is RSA-based, but it'll still be used to sign ECDSA certificates just like X3 does?

7 Likes
Issuance on R3 vs. X3: is this configurable?
Beginning Issuance from R3
#2

This link in crt.sh I think goes to the initally-revoked cross-signed intermediate. Should it maybe go to https://crt.sh/?id=3479778542 or https://crt.sh/?caid=183267 instead?

Thanks for catching that! I've updated the post. I did specifically link to the certificate page, rather than the CA page, because the CA page helpfully links to both the IdenTrust- and ISRG-issued certificates, which again are relevant for the January change but not for this one.

Can you clarify what it means that you'd be "allowing issuance in staging", when staging (I assume) wouldn't be signing from the real production R3? (Or maybe it will do "real" signing for some short length of time for testing?) Is it just that there would be new intermediates that will be started to get used in the staging environment? (And if so, I'd kind of expect that the order would be different, that staging changes would happen before issuing internal-to-Let's-Encrypt certificates?)

Still working with SRE on the final details here. Again, watch the API Announcements thread for updates.

So since E1 isn't going to be in use just yet, I just want to confirm that elliptic curve leaf certificates will just get signed by R3 once that goes live? That is to say, the "R" just means that the key for the intermediate itself is RSA-based, but it'll still be used to sign ECDSA certificates just like X3 does?

Correct, this change will have no effect on how we issue end-entity certificates for ECDSA keys. They will come from R3 until we begin parallel issuance from E1, which is further down the line and not related to this change.

8 Likes
#3

Will the caIssuers URL in the issued certificates be changing?

That’s how some of our client logic fetches intermediates.

2 Likes
#4

The caIssuers field within the Authority Information Access extension of all end-entity certificates issued by R3 will correctly point to a URL which permanently hosts an R3 certificate. Today, certificates issued from our X3 intermediate contain an AIA caIssuers URL of "http://cert.int-x3.letsencrypt.org/", which would be incorrect for R3, so yes it will be changing.

3 Likes
#5

Just in case anybody is wondering what the first test R3 certificate was:

4 Likes
#6

Is this the expected lifetime for R3?:
image

2 Likes
#7

Yes, that is the lifetime of R3's cross-sign from DST Root CA X3, which itself expires in late 2021. The lifetime of the R3 certificate issued from our own ISRG Root X1 is much longer: https://crt.sh/?id=3334561879
image

5 Likes
#8

Off with the training wheels...

:smiley:

3 Likes
#9

if we left cross sign cert alone and create a new 90-day certificate in August, than in DST-cert's view it's a leaf certificate that with lifetime extends after CA's expire date. I'm not sure if that's allowed? I look though CA/B BR but cannot find rule that forbid this, but it still makes me worry.

2 Likes
#10

I noticed the other day that the cross-signed ISRG Root X2 is listed as an Intermediate certificate (for obvious reasons):

Screenshot_20201201-194111_Samsung Internet
Screenshot_20201201-194111_Samsung Internet1205×941 179 KB

Additionally, the self-signed ISRG Root X2 just dropped out of space (no logged at date):

Screenshot_20201201-194225_Samsung Internet
Screenshot_20201201-194225_Samsung Internet1003×153 93.2 KB

2 Likes
#11

There's an event on the API Calendar to prevent this from happening.

4 Likes
#12

Well, even once the ACME server stops serving the DST Root X3 chain to clients, one could still configure one's web server to serve the R3-signed-by-DST intermediate to users. I think that browsers will just not accept such a chain after the R3-signed-by-DST expiration, so I don't think there's actually a problem from a compliance perspective.

2 Likes
#13

Hm, did I miss the announcement?

2 Likes
#14

Yep... R3 is a go!

2 Likes
#15

Remember that all conversations about the expiration of DST Root CA X3 (and therefore the expiration of our X3 and R3 cross-signed intermediates) are really conversations about the upcoming Chain Switch, not conversations about the switch from X3 to R3. If we had not done this changeover today, all the same issues regarding expiration in mid-late 2021 would still exist with X3, so it's an orthogonal issue. We do plan to change our default chain on Jan 11th, and disallow issuance from the cross-signed R3 entirely in early summer. But please keep conversations about those events (and their necessity) to other threads, so that this one can remain clear and concise for folks who have questions about today's X3-to-R3 switch.

5 Likes
#16

The specifics of the confusion (from which this very topic came) can be found here:

2 Likes
#18

Ah, Discourse didn't give any hint of new posts in that topic. I guess the API announcement section is regarded as a regular section and I should have manually selected notifications on new posts...

Also, I'm wondering how many clients are out there with a hardcoded intermediate now setting a broken chain. No new threads up till now about that..

3 Likes
#19

We're wondering the same thing! That's one reason for the announcement thread: so that someone whose site seems to be broken by this change can see the announcement and our explanation of exactly this failure mode there.

But we're also spot-checking domains which have renewed their certs since this changeover to see if they've properly updated their full chain, and trying to identify commonalities (acme clients, hosting providers, etc) between any such domains.

7 Likes
#20

So now that R3 is live in production (hooray!), I still don't see any changes in staging. (Or at least, a staging certificate that I just issued and one I tried a couple weeks ago are both signed by the same "Fake LE Intermediate X1".) Is there still a change expected in staging relating to this change?

This guess of mine was apparently wrong, as the CPS section 7.1 still says that the CN of intermediates will be Let's Encrypt Authority X<n>. Is this a problem, or is that part of the CPS not actually authoritative but just describing the initial intermediates and not necessarily all active intermediates?

4 Likes
#21

We decided not to change the staging certificate yet. We will probably sign a new root and intermediates for staging tests when we start testing our multi-issuer support (rsa and ecdsa roots), but that is still a while away.

Good catch! I'll make sure we get that updated.

5 Likes
Timelines on new FakeRoots?
Root / Intermediate organizational questions