The Web PKI is the invisible backbone that keeps HTTPS connections trustworthy. Recent changes to Mozilla’s Root Store Policy (MRSP) – now at version 3.0 – raise the bar for Certificate Authorities (CAs) in three high‑impact areas: faster revocation, mandatory automation, and tighter private‑key lifecycle controls. For developers who embed TLS handling into services, CI pipelines, or email gateways, the new rules translate into concrete operational adjustments. This post walks through the most relevant updates, explains why they matter, and offers practical steps you can take today to stay compliant and improve your own security posture.

---

Why Revocation Has Been a Pain Point

TLS certificates are designed to be short‑lived, yet the reality is that many organizations still run multi‑year certificates. When a private key is compromised or a domain is abandoned, the certificate must be revoked so browsers stop trusting it. Historically, revocation has suffered from three problems:

1. Delayed propagation – CRLs and OCSP responses are often cached for hours, leaving a window of exposure.
2. Operational friction – Manual processes for re‑issuing certificates can take days, especially for large fleets.
3. Lack of clear expectations – CAs have been able to request “exceptions” to the TLS Baseline Requirements, creating an uneven playing field.

MRSP v3.0 eliminates the “exception” loophole and forces a uniform revocation timeline across all CAs that want to be included in Mozilla’s root store.

Key Revocation Changes

• No exceptions – Mozilla will not grant any waivers to the baseline revocation schedule.
• Subscriber contracts must include revocation clauses – CAs need to explicitly require their customers to cooperate with revocation timelines.
• Mass‑revocation readiness – Operators must maintain a documented, testable plan for revoking thousands of certificates within a short window, and a third‑party assessor must verify the plan annually.

Practical steps for dev teams

1. Integrate revocation checks into monitoring – Use tools like certspotter or the CRLite APIs to watch for OCSP “revoked” status in real time.
2. Automate certificate replacement – Pair ACME clients (e.g., certbot, lego) with CI pipelines that trigger a new issuance as soon as a revocation is detected.
3. Run tabletop exercises – Simulate a mass‑revocation scenario once a quarter to validate your plan and uncover bottlenecks.

---

Automation Is No Longer Optional

The policy now ties root‑store inclusion to concrete automation capabilities. To qualify for the “websites” trust bit, a CA must demonstrate a publicly accessible test site that automatically replaces its certificate at least every 30 days. The test site URL and results must be published in the Common CA Database (CCADB).

What “automation” covers

• Domain Control Validation (DCV) – Automated DNS‑01 or HTTP‑01 challenges that do not require human interaction.
• Issuance & renewal – End‑to‑end flows that can be triggered via an API or ACME endpoint without manual steps.
• Transparency – Public evidence of the automation run (logs, screenshots, or a live status page) stored in CCADB.

How to adapt your tooling

• Adopt ACME – If you haven’t already, move to an ACME‑compatible CA. Most modern CAs (Let’s Encrypt, DigiCert, Sectigo) provide full ACME support.
• Expose a health endpoint – Create a /cert-status endpoint that returns the current certificate fingerprint and the timestamp of the last successful renewal.
• Version‑control your ACME client configuration – Store the client’s configuration files in Git so you can reproduce the exact automation steps for audit purposes.

---

Separating TLS and S/MIME Roots

Dual‑purpose root CAs – those that carry both the “websites” and “email” trust bits – are being phased out. Starting now, any new root added to Mozilla’s store must be dedicated to either TLS or S/MIME. Existing dual‑purpose roots have to submit a migration plan by April 15, 2026 and complete the transition by December 31, 2028.

The rationale is simple: TLS and S/MIME have diverging compliance requirements, key‑usage policies, and threat models. By separating them, Mozilla can enforce stricter controls for each ecosystem without one set of rules dragging the other down.

Implications for developers

• Email‑security pipelines – If you rely on a CA that still uses a dual‑purpose root, you’ll need to verify the migration schedule and, if necessary, switch to a dedicated S/MIME provider.
• Certificate pinning – Hard‑coded pinsets that include both TLS and S/MIME roots will break once the separation is enforced. Use dynamic pinning or update your pin lists regularly.

---

Cradle‑to‑Grave Monitoring of CA Private Keys

MRSP v3.0 introduces “parked‑key” reporting. A parked key is a private key generated in advance of a certificate but not yet used. Previously, these keys could sit dormant for years, creating a hidden attack surface. Under the new policy, CAs must publish the public hash of every parked key in their annual audit reports. This creates a transparent audit trail and allows the community to detect unexpected key reuse.

What you should watch for

• Key‑rotation policies – Ensure your own PKI (if you run an internal CA) discards unused keys after a defined period.
• Audit logs – Pull the latest CCADB audit files and verify that the list of parked‑key hashes matches your expectations.
• Secure storage – Use HSMs or cloud‑based key‑management services that enforce strict access controls for any key that is generated but not yet exported.

---

Key Takeaways for Developers

• Revocation is now a hard requirement – No more “we’ll work with you on an exception.” Build automated revocation detection and replacement into your stack.
• Automation is a gate‑keeper – To stay in Firefox’s root store, CAs must prove automated DCV, issuance, and renewal via a public test site. Align your CI/CD pipelines with ACME to meet this expectation.
• TLS vs. S/MIME roots will diverge – Update any hard‑coded trust stores and monitor CA migration timelines.
• Parked‑key transparency – Treat unused keys as a liability; incorporate regular key‑lifecycle reviews and audit the public hashes published by your CA.

---

Moving Forward

Mozilla’s MRSP v3.0 is a clear signal that the Web PKI is moving toward more measurable, automated, and auditable practices. For developers, the policy translates into actionable changes: tighten your cert‑revocation monitoring, embrace ACME‑based automation, and audit the trust chains you depend on. By doing so, you not only stay compliant with Mozilla’s root‑store requirements but also raise the security baseline for every user who connects to your services.

If you have questions or want to share how your organization is adapting, join the discussion on the Mozilla security policy mailing list.

---

Source: Enhancing CA Practices: Key Updates in Mozilla Root Store Policy, v3.0