They did it!
(Can't see the cert yet on crt.sh unfortunately: crt.sh | Serial#03b0b015c1a4e2641611731a711b711de0ef)
Edit: Hm, crt.sh seems to be b0rk3d badly: https://crt.sh/monitored-logs. All (relevant) logs are red and have a last get-sth-call of "2025-02-19 17:49:58" which is more than 24 hours ago..
Time to get an account at Censys
I have (had?) one, but crt.sh is easier as it doesn't require an account and/or login.
Interestingly enough, helloworld.letsencrypt.org
does not actually use that certificate, at least not at the moment.
Excellent!
Now let us issue some
Well no, the top of the blog post said that they revoked it right away. (But wait, I thought that one of the points of short-lived was that they didn't have revocation information?)
At least in staging, please? I just tried it (now that lego has support) and got an error that my account is not permitted to use certificate profile "shortlived"
, so it looks like they're only issuing to themselves even in staging for now.
Did not read that
It even has the OCSP URI
Not yet, according to the various Boulder issues omitting revocation information for those certs is work in progress:
There are still a bunch of rough edges around short-lived (i.e. ARI doesn't work properly for them right now) certificates that need to be ironed out. Maybe they want to fix some of that first, before opening up to the test audience more.
Couldn't find an open (or closed) issue with a feature request for ACME profiles on the Certbot Github repo.. So I opened one..
Their new Profile page says (emphasis mine):
which means they do not need to contain any revocation information
But elsewhere they've said their short-lived certs won't have it so I am guessing this is just temp during the rollout.
Yeah, I didn't think it was against the rules. I guess I'm just confused why they said they were testing the revocation lifecycle if the plan is for these (upon full release) to just not have revocation information.
As an aside, both shortlived
and tlsserver
profiles in the directory are noted as limited availability.
The blog post never said revocation lifecycle (but just cert lifecycle), so I thought this is really about the cert itself: How ARI works for those, how the DB shards them into the expired corner compared to normal 90 day certs and such, not a particular revocation test. They do have some state tracking for certs beyond doing OCSP signing (which is going away anyway).
Yes, but in staging tlsserver works and shortlived doesn't. (I haven't tried prod, but I assume classic is the only option the public can use there.)
Sure, but the "(…) then immediately revoked it so (…)" (especially the last part of that snippet) suggests that revocation had some big deal in that cert lifecycle testing.
I guess this is just some preliminary testing, as this obviously is not the final short lived profile cert with the OCSP URI still included.. And with that I don't see this as a big deal, really.. Sure, it's nice they have it partly working, but it's just preliminary.. We'll probably have to wait many months until it's publicly available. Not sure if it was worth a blog post
Huh, I'll have to try that. I got thrown off seeing this from staging 'directory'
[profiles] => Array
(
[classic] => https://letsencrypt.org/docs/profiles#classic
[shortlived] => https://letsencrypt.org/docs/profiles#shortlived (not yet generally available)
[tlsserver] => https://letsencrypt.org/docs/profiles#tlsserver (not yet generally available)
)
I saw it too, I just didn't let it stop me from trying.
Yes, there's lots of work to do before this is "done", including a lot of things around revocation.
The biggest reason we revoked it immediately is that if there was some sort of compliance problem discovered in our post-issuance review, we wouldn't have to rush and go revoke it.
Wouldn't that only be necessary if for some strange reason the lifetime was too long so that it wouldn't be a short-lived cert? Or do short-lived certs still require revocation for things like misissuance?