(Related to OCSP Deprecation) Timeline and end points for CRL

Issuance Policy
1

I think this more of an issuance policy question. Let me know if the "Help" category is more appropriate.

In the post here on ending OCSP support Ending OCSP Support in 2025 - Let's Encrypt it says:

May 7, 2025

  • Prior to this date we will have added CRL URLs to certificates

;tldr my questions

  1. Is the format of the CRL URL that will be added to certificates already known? Will it be http://<intermediate>.c.lencr.org like http://r11.c.lencr.org? If not do we know when this will be decided?
  2. Any update on the timeline at which CRLs will be added to certificates. It has to be pretty soon to be before the May 7 deadline. Ideally OCSP isn't dropped at the same time as CRL is added.

Background

We have consumers of our certificates that make server to server calls (not browsers) that have very locked down infrastructure. So much so that when making external calls to our website they have to allowlist the OCSP end points today so their infrastructure can check the OCSP end points. This has been difficult for us to manage as the OCSP end points are different for each intermediate. Some of these consumers refuse to allow list a wildcard domain in the form of r*.o.lencr.org or *.o.lencr.org and instead we have to carefully monitor for when new intermediates are added by Let's Encrypt to let these consumers know ahead of time what the new hosts will be.

  1. To that end. Is the format of the CRL URL that will be added to certificates already known? Will it be http://<intermediate>.c.lencr.org like http://r11.c.lencr.org? If not, do we know when this will be decided?

Related to these consumers. Something we are still trying piece together is how different server infrastructure handles certificates that have both OCSP and CRL on the cert. It seems like most of the communication out of LE is focused on browser consumers which is fair but server infrastructure handling is much more varied between code languages and server implementations. I'm not asking for help on specifics around OCSP vs CRL handling but asking:

  1. Any update on the timeline at which CRLs will be added to certificates. It has to be pretty soon to be before the May 7 deadline. Ideally OCSP isn't dropped at the same time as CRL is added.

In an ideal world I would have loved to have the ability to send something with my certificate request to have the CRL end point added to the cert in addition to OCSP end point before it was the only way it would be. That way we could test handling by different client and server libraries to how having both extensions in place working.

2 Likes
2

I don't know if this affects your setup, but have you seen the recent announcement about ClientAuth being deprecated as well?

2 Likes
3

I hadn't seen that announcement yet, but we don't have concerns on that. We aren't doing mutual TLS with Let's Encrypt certs. For mutual TLS we use private CA infrastructure.

5 Likes
4

We are actually just about to announce that timeline. We will add CRL Distribution Point URLs to certificates in March, to give a transition time. Expect an announcement in the next few days as we finalize our staging rollout and confirm a tentative March 12 date. We'll post in the API Updates category here and send an email to the Let’s Encrypt Technical Updates mailing list category shortly. Sign up to receive those updates Sign up for emails - Let's Encrypt

Yes, and the CRLs are already live at those URLs. For example, https://r11.c.lencr.org/1.crl works today. Note that we use "partitioned CRLs", so there are 128 CRLs per intermediate right now.

We are required to publish a full list of our CRLs to the Common CA Database by the Linux Foundation, so you can monitor that for a list of hostnames for our CRLs, and the CRLs of other CAs as well. See the CSV file "All Certificate Information" there, which contains the URLs in the "Full CRL Issued By This CA" and "JSON Array of Partitioned CRLs" columns.

Or just subscribe to the technical updates mailing list.

7 Likes
5

Just to add, the full list of domains is currently:

issuers = ["x1", "x2", "e1", "e5", "e6", "e7", "e8", "e9", "r3", "r10", "r11", "r12", "r13", "r14"]
domain_name       = "${issuer}.c.lencr.org"
3 Likes
6

Which would make e.g.:

wget https://{e1,e5,e6,e7,e8,e9,r3,r10,r11,r12,r13,r14}.c.lencr.org/{1..128}.crl

For x1 and x2 there's no /{1..128}.crl, just /.

2 Likes
7

Excellent. Thanks for the detailed reply!

The rest of this is just me responding with our plans. No direct questions.

We are actually just about to announce that timeline.

I'll look forward to the upcoming blog post.

Sign up to receive those updates Sign up for emails - Let's Encrypt

Yeah, we have engineers subscribed to the technical updates mailing list but it's hard to always operationalize acting on an email.

We are required to publish a full list of our CRLs to the Common CA Database by the Linux Foundation

The link to the Common CA Database is very helpful. I see the JSON Array of Partitioned CRLs column in the "All Certificate Information" spreadsheet. That's helpful.

We should be able operationalize checking that spreadsheet from time to time looking for rows with CA Owner = "Internet Security Reasearch Group" to find new entries. Using that spreadsheet should hopefully let us catch new intermediates through a monthly manual review process. We also have the stop gap of monitoring our automated certificate rotation tooling for changes to intermediate that is used to sign the leaf certificates we are issued. I see that the CAB forum only requires 24 hours after the fact notification of new CRLs. I'm assuming in most cases LE and any CA would hopefully publish in advance of the new Intermediates actually being in use.

4.9.7 CRL issuance frequency | CA/Browser Forum

[...]
Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either: - a full and complete CRL; OR - partitioned (i.e., “sharded”) CRLs that, when aggregated, represent the equivalent of a full and complete CRL.

RE: The array list in the other posts on what to allow.

Fortunately, our consumers today are limiting by hostname only. So, we can just give them the hostnames to allow and not have to worry about the URLs.

Final musing:

As much of a headache as it gives me to manage these per-intermediate hostnames I see the benefit of partitioning this backend data like CRL by intermediate in the hostname. We only have maybe 2% of our consumers that are this difficult. I think including documentation back to them from that Common CA Database should hopefully help us out too.

8

One oddity in the "All Certificate Information" is that the CRL end points are blank for number of the intermediates. These all appear to be backup intermediates. (I hid most of the columns there).

image
image1130Ă—488 11.2 KB

9

Correct, we are not currently issuing any CRLs for those intermediates. I realize now that is less helpful for what you want, since you’d want to know in advance for firewall reasons.

3 Likes
10

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