April 18, 2026, 8:59pm 1

kinda curious, how exactly are the Root certs handled, is that something the public is allowed to know?

while I assume that it is not QUITE as extreme as the DNSSec Root keys I would assume there is a similar idea, fully offline multiple people who have to be together to unlock different levels of access which are all needed to in the end get to however the root cert is protected right?

for reference, the DNSSec Process:
https://www.cloudflare.com/learning/dns/dnssec/root-signing-ceremony/

Something like that as far as I know indeed. So called "root signing ceremonies". Look it up, there's probably info about it out there related to the web PKI too.

1 Like

The legal requirements that all public certificate authorities have agreed on - Let's Encrypt included - are documented in the Baseline Requirements from the CA/Browser Forum. Some excerpts:

6.1.1.1 CA Key Pair Generation
the CA SHALL:

1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the
   entire CA Key Pair generation process, and
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during
   its Key and Certificate generation process and the controls used to ensure the integrity and
   confidentiality of the Key Pair.

In all cases, the CA SHALL:

1. generate the CA Key Pair in a physically secured environment as described in the CA’s
   Certificate Policy and/or Certification Practice Statement;
2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple
   person control and split knowledge;
3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and
   business requirements as disclosed in the CA’s Certificate Policy and/or Certification Practice
   Statement;
4. log its CA Key Pair generation activities; and
5. maintain effective controls to provide reasonable assurance that the Private Key was
   generated and protected in conformance with the procedures described in its Certificate
   Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

4.3.1.1 Manual authorization of certificate issuance for Root CAs
Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA
system operator, system officer, or PKI administrator) to deliberately issue a direct command in
order for the Root CA to perform a certificate signing operation.

Effectively, this boils down to a) having auditors present when you do critical things, b) storing your key securely, c) having access controls (multi-person, security etc) in place. This involves putting them on a Hardware Security Module, and additionally you may want to keep them offline when they're not needed. Precise details are not usually public.

As stated in the BRs, a CA must describe their practices in their Certification Practice Statement. As such, you will find some further information there. Quoting from Let's Encrypts CPS:

5.2.2 Number of persons required per task
A number of tasks, such as key generation and entering areas physically containing operating ISRG PKI systems, require at least two people in Trusted Roles to be present.

6.7 Network security controls

ISRG implements reasonable network security safeguards and controls to prevent unauthorized access to CA systems and infrastructure. ISRG complies with the CA/Browser Forum's Network and Certificate System Security Requirements. Identified vulnerabilities are responded to within 96 hours of review, and remediated within a timeframe based on their risk profile: critical vulnerabilities within 96 hours, high-risk within one month, medium-risk within three months, and low-risk within six months.

ISRG's network is multi-tiered and utilizes the principle of defense in depth. Firewalls and other critical CA systems are configured based on a necessary-traffic-only allowlisting policy whenever possible.

ISRG Root CA Private Keys are stored offline in a secure manner.

4 Likes

I've seen a post about those in here, not that much details though, not sure if the procedures are different between making and signing new roots vs just handling intermediates and CRLs.

I have been very intrigued how insanely specific the DNSSec root process was even up to the level that the proces is fully public including video footage.

4 Likes

Depends what you mean with "handling intermediates" and "handling CRLs".

The intermediates are continuously used to sign leaf certificates, so they are "online" all the time (if in use). But to sign an intermediate, the root is required and that one needs to be kept offline and requires a ceremony, also to make sure the new intermediates aren't tampered with.

With regard to CRLs: the end leaf CRLs are signed by the intermediates, so no issue there. The intermediate CRLs are signed by the root certs, but only once to maybe twice a year (maybe? I dunno TBH, CRL is valid for a year after signing, but maybe they update it earlier to mitigate the risk if something goes wrong), so that'll require the root to be "activated" so most likely would require some sort of ceremony perhaps? Not sure how "big" and how much risk of tampering there would be.

Most likely, sure.