Can you share exactly how you issued the cert? i.e. did you spin up a version of Boulder in the cloud that was only accessible to ISRG, was this done locally without ACME, or some other method?
I am just curious about the planning put into this.
4 Likes
The profiles are live in production, with an allowlist of accounts, and they can be seen by the directory.
This was done by the real boulder, in production, via our public API. We used the latest lego release to issue a cert off the shortlived profile. The primary purpose of that test was to verify everything works end-to-end in production, and it did.
We used DNS-01 validation, copying the token into DNS for helloworld manually.
We probably didn't need to revoke it, including the argument about not needing revocation for short-lived certs, but that's not a compliance path we have trodden yet. There's still a number of open questions compliance-wise here we have with various root programs to figure out some of the details. But yeah, what if the dates were mis-encoded somehow? Or there was some other problem with the cert we hadn't predicted? Also of course making sure OCSP works properly, even if we plan to not have these GA until after OCSP is sunset.
11 Likes
certbot renews by 30 days before expiry: it'd broken badly renewing every thing cron run on six day certs
2 Likes
The rule is that short-lived certs don't need to include revocation information (OCSP or CRL URLs). But if they do, then those mechanisms need to work properly.
We haven't finished removing revocation info from short-lived certs yet, so as long as they embed that info, it makes sense to test it, too.
8 Likes
Any chance to join the allowlist 
No, we are still only in early testing, and need to make several additional changes before we are ready for any external users.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.