Issuance on R3 vs. X3: is this configurable?

Issuance Tech
#11

The part where you're mixing two separate "events". You keep talking about root certificates, which is differently in total from the X3 vs. R3 intermediate certificate event.

Also, the part where OP talks about "additional alternate link relation" and you consequently talk about the ACME client doing something is confusing again. That's more related to the root event, where the ACME client can choose the chain to the root certificate (i.e., cross-signed or non-cross-signed intermediate), while the X3 vs. R3 event is an ACME server decision. Not up to the client at all.

4 Likes
#13

Jan. 11 is when the default chain will change which root is signing the intermediate. There's no date yet published that I know of on when the intermediate will be changing. It's possible that they'll do it the same date if that makes things easier for them, but I think the plan is to do it sooner.

Now:
IdenTrust Root → LE X3 → Leaf cert
(with "alternate" available for ISRG Root X1 → LE X3 → Leaf cert)

"Soon" I think:
IdenTrust Root → LE R3 → Leaf cert
(with "alternate" available for ISRG Root X1 → LE R3 → Leaf cert)

As of Jan. 11:
ISRG Root X1 → LE R3 → Leaf cert
(with "alternate" available for IdenTrust Root → LE R3 → Leaf cert)

(All assuming that the intermediate switch happens before Jan. 11, and only talking about RSA certs. At some point they'll put E1 and Root X2 into the mix as well for elliptic curve certs.)

6 Likes
#15

Yes, everything currently in use is ISRG Root X1 signed and IdenTrust DST Root X3 cross-signed. Although R3 currently isn't in use, it is signed by both roots too.

3 Likes
#16

If you'd like to see it for yourself, https://valid-isrgrootx1.letsencrypt.org/ is a test site currently signed by X3 and serving the intermediate which is signed by ISRG Root X1. There's nothing special or unique that Let's Encrypt needed to do in order to set this up; you could do it yourself if you started serving the intermediate signed by ISRG Root X1 on your own web site. The only difference on Jan. 11 is them changing the default chain returned by the ACME server.

3 Likes
#17

And just to be clear because in all our discussion I want to be sure this question actually gets answered:

No, your client has no control over which intermediate Let's Encrypt uses for signing, and in theory it shouldn't care one way or the other. The root matters in terms of which operating systems and browsers trust it (which is why the "alternate" link gives you a choice for that), and your ACME client needs to download the intermediate because your web/mail/etc. server needs to send it along with its own leaf certificate. But Let's Encrypt should be able to change its intermediates every day without you or browsers really caring which one is used. (In practice I suspect the auditing requirements and logistics of doing so would make it a real pain for them to actually change it daily, though, I'm just saying that while it'd matter to them, it shouldn't matter to you.)

3 Likes
#18

While R3 isn't active yet, I suspect that it's going to go live very soon™.

The cross-sign variant of X3 (the IdenTrust one) expires on Mar 17 16:40:46 2021 GMT. Since Let's Encrypt leaf certificates are always 90 days valid, and a leaf certificate can't be valid for longer than the intermediate, the X3-cross sign variant cannot sign any 90-days certificates after 17.12.2020, exactly this day next month.

Therefore I suspect that the switching to R3 is going to happen within the next 30 days. Since this is before the Jan 11 date, R3 will initially be served with the cross-sign variant and later switched to the ISRG variant by default.

8 Likes
#19

As I understand it, (2) matters for the following reason: the X3 intermediate expires Mar 17 16:40:46 2021 GMT. So, that means as of Dec 17 or so certs issued from this will have lifetimes longer than the intermediate from which they were issued, which I've been told is a CA/B forum violation. I hope someone can at least confirm that the switch to R3 will happen before then.

3 Likes
#21

The intermediates (both X3 and R3) are both signed by DST Root X3 and ISRG Root X1, yes. But this is talking about the certificate chain being served, usually called fullchain.pem. This file consists of "your" certificate (signed by the intermediate) and the intermediate (signed by a root). You can't generally serve both signatures (actually maybe you can put them both in the fullchain file, but it's not the standard way to do it), so you can pick which intermediate signature you're using. You can use either one before Jan. 11, and you can use either one after Jan. 11. The only change happening that day is which one you get from the ACME server by default, and the other one is "hidden" behind an "alternate" link.

3 Likes
#23

Well, before Jan. 11 the served certificate chain only leads to DST Root X3. Afterward, the chain only leads to ISRG Root X1. In both cases it only goes to one root, they're just changing which root it is (but you can choose to use the other chain if you want to).

3 Likes
#25

No, the last part is not correct. While you are correct all currently available (in use or not) are signed by the ISRG root as well as IdenTrust, the "thing" you're quoting here, the event happening, is just which intermediate is sent by the ACME server as default and which is sent as alternative. The "only" part doesn't make sense in that sense.

This is what's happening around January 11th assuming R3 had been put into use:

Before:

  • end-leaf cert signed by private key R3
  • default intermediate: R3 signed by DST Root CA X3
  • alternative intermediate: R3 signed by ISRG Root X1

After:

  • end-leaf cert signed by private key R3
  • default intermediate: R3 signed by ISRG Root X1
  • alternative intermediate: R3 signed by DST Root CA X3

For me, the "only" isn't applicable in this event.

4 Likes
#27

No, the change in defaults is correct, but I typed IdenTrust where I should have typed ISRG. It was late here, sorry! Now its correct.

2 Likes
#29
Let's Encrypt Authority X3
Signed by ISRG Root X1
Let's Encrypt Authority X3
Cross-signed by IdenTrust
R3
Signed by ISRG Root X1
R3
Cross-signed by IdenTrust
E1
Signed by ISRG Root X2
2 Likes
#31

If you really want to include the word "only" in your sentences (you really want to do that, it seems), you should also say that for the current situation, ACME clients will, by default , serve a certificate chain that only leads to DST Root CA X3.

Otherwise the word "only" still doesn't make sense.

Ah, missed this post just in a few seconds :stuck_out_tongue:

3 Likes
#32

I beat you to my correction and scolding, brother. :slightly_smiling_face:

2 Likes
#33

Perhaps it clarifies even more, I dunno :stuck_out_tongue:

3 Likes
#34

My guess is that (one of the things) they're working on before bringing the new intermediates into service is updating the CPS. Section 7.1 only mentions the X<n> certificates, so I'm guessing they need to add at least the R<n> certificates there before they can be used. So keep your eyes peeled there if you want another hint of when they're about to use the new intermediates.

(And there are even more changes they need to make before using the E<n> intermediates. Actually, it seems weird to me that 1.1 has been updated to say it includes Root X2, while the rest of the document, like section 6.1.5, still says that roots are RSA keys. It's things like that which make me think that updating all the "paperwork" is what's holding up the use of the new intermediates, though I'm just a "layman" and I'm sure I don't know all the steps involved.)

5 Likes
Questions re: Beginning Issuance from R3
#35

And now yet another hint, from the blue "Service status: Planned Maintenance" bar at the top:

We are performing maintenance on our OCSP infrastructure in preparation for our new intermediate certificates. No disruption is expected.

So they're certainly working on it, there are probably just a lot of pieces they need to put into place. But it still looks like "soon" to me.

5 Likes
#36

Hi everyone! For all of you guessing that issuance would begin from R3 "soon", you're right! See the announcement post here: Beginning Issuance from R3

To answer the original question: No, you will not be able to configure whether your end-entity certificate is issued by R3 or issued by X3. When we begin issuance from R3, it will be replacing X3, not co-existing side-by-side.

Some additional context and detail, to help remove any pieces of confusion brought up in this thread:

As @_az pointed out, there are two separate events coming up: changing our issuance from X3 to R3, all while continuing to chain up to IdenTrust's DST Root CA X3 trust anchor; and then changing our chain from DST Root X3 to our own ISRG Root X1 trust anchor. The former is time-constrained by the expiration of our X3 intermediate (it was issued with 5 years of validity back in 2016); the latter is effectively time-constrained by the expiration of DST Root CA X3 (it was issued with 21 years of validity back in 2000). Although these events seem related and are happening at around the same time, conceptually they are wholly orthogonal and could happen in either order, completely independently.

When we talk about chains of trust, it is really easy to get confused about what it means to be "issued by" something. Remember that certificates do not issue other certificates: private keys issue certificates. The acme client does not have control* over what private key is used to issue the requested end-entity certificate. But, there might be multiple certificates which all say "I trust this intermediate public key", signed by various different root private keys. In our case, all of our issuing private keys (e.g. X3 and R3) have two certificates indicating trust in them: one each signed by IdenTrust's DST Root CA X3 and by ISRG's Root X1. Our ACME API provides as a courtesy the ability to control which of those two certificates you get bundled with your new end-entity certificate. But at the end of the day, they both represent the same private key which issued your new cert.

* It will have some control when we begin parallel issuance from E1: the ability to choose between R3 (RSA) and E1 (ECDSA). But that's a separate conversation.

8 Likes
#37

3 posts were split to a new topic: Questions re: Beginning Issuance from R3

#38

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.