SC-081v3: 47-day TLS certificates, why it matters and how to prepare
By CaptainDNS
Published on March 19, 2026
- SC-081v3 adopted: maximum TLS certificate lifetime drops from 398 days to 47 days by March 2029, in 3 phases (200d in 2026, 100d in 2027, 47d in 2029)
- DCV reuse also shrinks: from 398 days to 10 days, requiring near-continuous domain revalidation at each renewal
- Automation is no longer optional: without ACME or an equivalent, manual renewal every 47 days is unsustainable
- Also read how SC-085v2 mandates DNSSEC validation by CAs, a complementary measure that took effect on the same day
March 15, 2026 marks a tipping point for the TLS ecosystem. Two CA/Browser Forum ballots take effect simultaneously: SC-085v2, which requires certificate authorities to validate DNSSEC when issuing certificates, and the first phase of SC-081v3, which reduces the maximum TLS certificate lifetime from 398 to 200 days. The timing is no coincidence: both texts are part of the same overhaul of trust on the web.
SC-081v3 was adopted by the CA/Browser Forum in April 2025 with overwhelming support: 25 votes in favor, 0 against, 5 abstentions. Apple, which originated the proposal, was joined by Google, Mozilla, and Microsoft. The message is clear: the era of one-year certificates is over. By March 2029, the maximum TLS certificate lifetime will be 47 days, and the reuse of domain control validation (DCV) evidence will be limited to 10 days.
This article covers the full history of lifetime reductions, the details of Ballot SC-081v3, the technical rationale behind the change, the outages that accelerated the decision, ACME automation, the role of Let's Encrypt, the impact on paid certificates, the interaction with SC-085v2 and DNSSEC, and a practical guide to prepare your infrastructure.
Is your certificate renewal automated?
From 10 years to 47 days: a history of reduction
TLS certificate lifetimes have been shrinking ever since the system was created. Every reduction was met with resistance, then rapid industry adaptation. The pattern is consistent: one player forces a change, the ecosystem adapts, and nobody looks back.
Before 2012: up to 10 years. Early versions of SSL certificates imposed no strict lifetime limit. Certificates valid for 8 to 10 years were common. Revocation relied on CRL lists that were rarely checked. The risk of compromise over such a period was substantial, but the cost of certificates (several hundred dollars) incentivized maximizing their validity.
2012: 5 years (Baseline Requirements v1). The CA/Browser Forum published the first version of the Baseline Requirements. The maximum lifetime was set to 60 months. This was the first global standardization of TLS certificate issuance practices.
2015: 39 months. Ballot 193 reduced the lifetime to 39 months. The industry adapted without major incident. Three-year certificates became the norm for enterprise customers.
2018: 825 days. A further reduction to 825 days (roughly 27 months) via the revised Ballot 193. Two-year certificates became standard. Let's Encrypt, launched in 2015, had already popularized 90-day certificates and demonstrated that automation works at scale.
2020: 398 days (Apple's unilateral decision). Apple announced unilaterally in February 2020 that Safari would no longer accept certificates longer than 398 days issued after September 1, 2020. Google and Mozilla followed within weeks. The CA/Browser Forum did not need to vote: browser vendors enforced the change through their root programs. The industry grumbled but adapted within months.
2023: Google proposes 90 days. In its "Moving Forward, Together" roadmap, Google proposed reducing the maximum lifetime to 90 days. The proposal did not go to an immediate vote but launched the debate.
2024: SC-081v1 withdrawn, v2 fails. The first version of the ballot was withdrawn before a vote. SC-081v2 went to a vote but failed to achieve the required supermajority. Several CAs opposed the timeline as too aggressive. Ballots SC-22 and 185, which aimed at similar reductions, had already failed in prior years.
April 2025: SC-081v3 adopted. The third version found consensus. The timeline is spread across 4 phases between 2026 and 2029, giving the industry time to adapt. The vote: 25 in favor, 0 against, 5 abstentions.
The pattern is clear: every reduction was fought, then adopted, then considered insufficient a few years later. The direction is irreversible.
Ballot SC-081v3: what changes in practice
SC-081v3 does not merely shorten certificate lifetimes. It also reduces the DCV (Domain Control Validation) evidence reuse period, forcing near-continuous revalidation.
The 4 phases of the reduction
| Phase | Effective date | Max. certificate lifetime | Max. DCV reuse |
|---|---|---|---|
| Phase 0 (current) | Before March 15, 2026 | 398 days | 398 days |
| Phase 1 | March 15, 2026 | 200 days | 200 days |
| Phase 2 | March 15, 2027 | 100 days | 100 days |
| Phase 3 | March 15, 2029 | 47 days | 10 days |
Understanding DCV reuse
Domain Control Validation (DCV) is the process by which a CA verifies that the applicant controls the domain. Currently, DCV evidence can be reused for 398 days: if you validate your domain today, the CA can issue a new certificate within the next 398 days without requiring fresh proof.
SC-081v3 reduces this reuse window in tandem with certificate lifetimes. In Phase 3, DCV reuse drops to 10 days. In practice, every certificate renewal will require a new domain validation, since a 47-day certificate must be renewed before expiration and the DCV evidence will only be valid for 10 days.
Why 47 days and not a round number?
The number 47 is not arbitrary. It corresponds to a 30-day renewal cycle with a 17-day buffer. The idea: if the ACME client renews 30 days before expiration (as most clients recommend), 17 days remain as a safety margin in case of failure. One renewal per month, with a safety net of more than two weeks.
What stays the same
SC-081v3 applies to all types of public TLS certificates: DV (Domain Validation), OV (Organization Validation), and EV (Extended Validation). There is no exception for OV or EV certificates, despite what some commentators had hoped. The DV/OV/EV distinction concerns the level of organizational identity verification, not the certificate lifetime.
Failed attempts
SC-081v3 is not the first attempt at a reduction. Several ballots had failed over the years. Ballot 185 (2017) proposed a move to 13 months and was rejected. Ballot SC-22 attempted a reduction to 397 days and failed. SC-081v1 was withdrawn before a vote. SC-081v2 did not achieve the required supermajority on the CA side. The v3 succeeded by spreading the timeline and adding a sufficient buffer at each phase.
Why shorter certificates?
Reducing certificate lifetimes addresses several structural problems in the TLS ecosystem. None of them can be solved by current mechanisms.
Revocation is broken
The mechanism designed to invalidate a compromised certificate does not work in practice. Certificate Revocation Lists (CRLs) reach hundreds of megabytes: Let's Encrypt's CRL exceeded 300 MB before OCSP was dropped. OCSP (Online Certificate Status Protocol) suffers from the soft-fail problem: if the OCSP server does not respond, the browser accepts the certificate by default, rendering the check useless. Chrome replaced OCSP with CRLSets, a compact list covering only about 2% of revoked certificates. Let's Encrypt officially dropped OCSP in late 2024, acknowledging the mechanism's failure.
With 47-day certificates, revocation becomes less critical. A compromised certificate expires naturally within a few weeks, limiting the exploitation window without relying on a broken revocation mechanism.
Crypto-agility and post-quantum migration
Short-lived certificates facilitate migration to new cryptographic algorithms. NIST published the final standards for post-quantum cryptography in August 2024: ML-KEM (Key Encapsulation) and ML-DSA (Digital Signatures). Transitioning to these algorithms will require replacing existing certificates. With 47-day certificates, the entire ecosystem migrates within 47 days at most, compared to over a year with 398-day certificates.
Reduced compromise window
A compromised 398-day certificate can be exploited for over a year. With 47 days, the maximum exploitation window drops to under 7 weeks. That is an 88% reduction. If a private key is stolen, the attacker has a few weeks instead of over a year to exploit it.
Forced automation reduces outages
Paradoxically, shorter certificates reduce expiration-related outages. The reason: they force automation. A 398-day certificate can be managed manually (poorly), forgotten, then expire abruptly. A 47-day certificate leaves no choice: without automation, renewal is impossible to sustain. Organizations that automate no longer suffer expiration outages.
Alignment with the zero trust model
The Zero Trust model relies on continuous verification. A 398-day certificate grants implicit trust for over a year, which contradicts the principle. Short certificates enforce frequent re-verification of the server's identity, aligning web PKI with Zero Trust principles.
The outages that changed everything
Several major incidents demonstrated the consequences of manual certificate management. Each outage strengthened the case for automation and shorter lifetimes.
Equifax (2017): 147.9 million people exposed
In March 2015, Equifax let an SSL certificate expire on a network traffic inspection appliance. This certificate, expired for 19 months, prevented detection of an active intrusion. Attackers exploited an unpatched Apache Struts vulnerability for 76 days, exfiltrating the personal data of 147.9 million people. The total cost exceeded $1.38 billion. The investigation revealed that the company managed over 300 certificates manually, with no centralized inventory.
Ericsson/O2 UK (2018): 32 million users without service
On December 6, 2018, an Ericsson intermediate certificate expired on the O2 UK network infrastructure. The expiration caused a total mobile network outage for 32 million subscribers for over 12 hours. SoftBank in Japan experienced an identical outage the same day. The estimated cost exceeded $133 million. The certificate, with a 15-year lifetime, had been installed and forgotten.
Microsoft Teams (2020): 3-hour global outage
On February 3, 2020, Microsoft Teams suffered a 3-hour outage during the COVID-19-driven surge in usage. The cause: an expired authentication certificate. The incident affected millions of remote workers at a time when Teams had become a critical tool for thousands of businesses.
Let's Encrypt (2021): a historic root certificate expiration
On September 30, 2021, the DST Root CA X3 certificate, used by Let's Encrypt for backward compatibility with older devices, expired. Millions of devices running Android 7.1 and earlier lost access to sites using Let's Encrypt certificates. The incident highlighted the complexity of root certificate management and the need for agile trust chains.
The common thread across these incidents: every outage involved a manually managed certificate that was forgotten, or whose lifetime far exceeded operational needs.
ACME and mandatory automation
With 47-day certificates and 10-day DCV reuse, manual renewal becomes physically impossible for any infrastructure with more than a handful of certificates. ACME (Automatic Certificate Management Environment) is the protocol that makes automation possible.
The ACME protocol (RFC 8555)
ACME standardizes the dialogue between a client (your server) and a CA. The process follows three steps: the client proves it controls the domain (challenge), the CA verifies the proof, then issues the certificate. Three challenge types exist:
- HTTP-01: the client places a file at a specific URL. The CA verifies the file is accessible. Simple but incompatible with wildcard certificates.
- DNS-01: the client publishes a TXT record under
_acme-challenge.captaindns.com. The CA queries DNS. Wildcard-compatible, ideal for automated environments. - TLS-ALPN-01: the client configures a temporary certificate with a specific ALPN extension. Useful when you control neither DNS nor the web server.
ACME clients
The ACME client ecosystem is mature and covers all environments:
- Certbot: the reference client, maintained by the EFF. Compatible with Linux, macOS, Windows. Plugins for Apache and NGINX.
- acme.sh: a pure shell script with no dependencies. Over 150 DNS APIs supported for the dns-01 challenge.
- Lego: a Go client, popular in containerized environments and CI/CD pipelines.
- Caddy: a web server with built-in ACME. Obtains and renews certificates automatically, with zero configuration.
- Traefik: a cloud-native reverse proxy with built-in ACME. Manages certificates for all backends.
ACME in the cloud
Major cloud providers integrate certificate automation:
- AWS Certificate Manager (ACM): free certificates with automatic renewal for AWS services (ALB, CloudFront, API Gateway).
- Google Cloud Managed Certificates: automatic renewal for GCP load balancers.
- Azure App Service Managed Certificates: free, automatically renewed certificates.
- Cloudflare: automatically managed edge and origin certificates, with support for 15-day certificates.
ACME renewal information (ARI, RFC 9773)
ARI is an ACME extension that lets the CA communicate the optimal renewal window to the client. Instead of renewing at a fixed percentage of remaining lifetime, the client queries the CA for the ideal timing. This allows the CA to smooth out load and signal early renewal in case of key compromise. Let's Encrypt has supported ARI since 2024.
NGINX and the native ACME module
In August 2025, NGINX released a native ACME module that allows the web server to obtain and renew its certificates directly, without an external client. This integration significantly simplifies deployment for environments running NGINX as a frontend.
Enterprise solutions
For large organizations managing thousands of certificates, CLM (Certificate Lifecycle Management) solutions orchestrate renewal at scale:
- HashiCorp Vault PKI: a PKI engine built into Vault, with automated issuance and rotation.
- Venafi / CyberArk: an enterprise CLM platform (CyberArk acquired Venafi for $1.54 billion in 2024).
- Keyfactor: a certificate lifecycle and machine identity management platform.
- Sectigo Certificate Manager: CLM with built-in ACME, covering both public and private certificates.
Let's Encrypt as trailblazer
Let's Encrypt did not wait for SC-081v3 to push the industry toward shorter certificates. The free, automated certificate authority holds approximately 63.9% market share of web TLS certificates and issues over 10 million certificates per day. Its influence on the ecosystem is considerable.
6-day certificates in production
Since January 2026, Let's Encrypt has offered 6-day certificates in general availability. These ultra-short certificates target highly automated environments (CDNs, cloud platforms, CI/CD) where renewal is fully driven by ACME. The goal: to prove that very short lifetimes work at industrial scale.
Toward 45-day certificates by default
Let's Encrypt has announced a transition plan toward 45-day certificates by default. The timeline includes an opt-in phase starting in May 2026, followed by a switch to a 45-day default in February 2028. This anticipation of the SC-081v3 timeline (which mandates 47 days in March 2029) gives the ecosystem a one-year head start to validate automation pipelines.
Dropping OCSP
In late 2024, Let's Encrypt announced the gradual phaseout of OCSP, completed in 2025. The reason: OCSP does not work (soft-fail in browsers, privacy issues, server load). This decision accelerated the industry's rethinking of revocation and reinforced the case for short-lived certificates. If revocation does not work, the only alternative is to limit certificate lifetimes.
Let's Encrypt proves every day that automation at scale is viable. Over 400 million websites use its certificates. The transition to 47 days will not be an issue for already-automated environments: it will be a non-event.
Impact on paid certificates and the CA ecosystem
SC-081v3 transforms the business model of certificate authorities and calls into question the value proposition of paid certificates.
OV and EV: still relevant, but shorter
OV (Organization Validation) and EV (Extended Validation) certificates remain available. Organization validation (verifying the company's identity, address, registration number) continues to provide distinct value beyond simple domain validation. But the certificate lifetime is reduced in the same way: 200 days in 2026, 100 days in 2027, 47 days in 2029. A 47-day EV certificate imposes the same renewal cadence as a DV certificate.
The pivot to subscriptions and CLM
Paid CAs are pivoting their business model. Instead of selling individual certificates with a fixed term, they offer annual subscriptions with unlimited renewals and a built-in ACME client. DigiCert, Sectigo, and GlobalSign all provide CLM (Certificate Lifecycle Management) platforms that automate ACME renewal for OV and EV certificates.
CA market consolidation
CyberArk's acquisition of Venafi for $1.54 billion in 2024 illustrates the consolidation of the market. Value is shifting from certificate issuance to lifecycle management. CAs that do not offer integrated automation are losing market share to Let's Encrypt and CLM solutions.
Wildcards and multi-SAN
Wildcard certificates (*.captaindns.com) and multi-SAN certificates (multiple domains on a single certificate) require the DNS-01 challenge for validation. With renewals every 47 days, automating the dns-01 challenge via your DNS provider's API becomes essential. Major DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) all offer APIs compatible with ACME clients.
Automation levels the playing field for paid certificates
ACME automation evens the playing field. A free Let's Encrypt DV certificate, automatically renewed every 47 days, provides the same level of encryption as a paid EV certificate. The difference is limited to the browser address bar (which no longer displays the organization name since 2019) and the financial warranty associated with the certificate. For the vast majority of websites, this difference no longer justifies the premium.
Interaction with SC-085v2: DNSSEC and frequent renewals
SC-081v3 and SC-085v2 take effect in the same month and create a multiplier effect on the DNS trust chain. For a detailed look at SC-085v2, see our dedicated article.
The multiplier effect
With SC-085v2, every domain control validation (DCV) now includes a DNSSEC check. With SC-081v3 Phase 3, a 47-day certificate means roughly 8 renewals per year instead of 1. Each renewal triggers a DCV, and each DCV checks DNSSEC. The number of certificate-related DNSSEC checks is therefore multiplied by 8.
Outage scenario: broken DNSSEC + short certificates
Consider a concrete scenario. Your TLS certificate expires in 15 days. Your ACME client attempts renewal. The CA performs dns-01 validation and checks DNSSEC per SC-085v2. But a DNSSEC key rollover failed: the DS record at the TLD no longer matches the KSK published in your zone. The CA's resolver returns BOGUS, the DCV fails, and the certificate is not renewed.
With a 398-day certificate, you have months to detect and fix the issue. With a 47-day certificate, you have at most 17 days (the buffer built into the renewal cycle). If the DNSSEC issue persists, your certificate expires and your site becomes unreachable.
DANE/TLSA rotation and short certificates
If you use DANE to authenticate your TLS certificates via DNSSEC-signed TLSA records, TLSA record rotation must keep pace with certificate renewals. With a 47-day certificate, the TLSA record must be updated at every renewal (unless you use DANE-EE 3 1 1 with SPKI, which survives renewal as long as the public key stays the same). See our DANE/TLSA guide for rotation strategies.
Unified pipeline: the recommendation
The SC-081v3 + SC-085v2 combination requires a unified approach. The certificate renewal pipeline should integrate:
- ACME renewal of the TLS certificate
- Pre-check of the DNSSEC chain
- DANE/TLSA record update if needed
- Continuous monitoring of all three components
Handling these elements separately multiplies the points of failure. A unified pipeline that checks DNSSEC before triggering the ACME renewal, then updates TLSA after issuance, significantly reduces the risk of an outage.
Practical guide: preparing your infrastructure
The transition to 47-day certificates unfolds in 4 phases over 3 years. Each phase imposes stricter constraints. Here are the 6 steps to prepare your infrastructure.
Step 1: inventory all your certificates
Before automating, you need to know what you manage. Use multiple sources to build a complete inventory:
- Certificate Transparency logs: query CT logs (crt.sh) to list all certificates issued for your domains.
- Network scanning: use tools like
sslyzeornmapto discover active certificates on your infrastructure. - CLM tools: platforms like Keyfactor or Venafi Discovery scan your network and clouds to identify unregistered certificates.
- Our DNSSEC Checker: verify the DNSSEC chain of trust, essential for certificate renewal since SC-085v2.
For each certificate, document: the domain, the issuing CA, the expiration date, the type (DV/OV/EV), the renewal method (manual or automated), and the responsible party.
Step 2: deploy a suitable ACME client
Choose an ACME client suited to your environment:
- Standalone web server: Certbot with the appropriate plugin (Apache, NGINX) or Caddy with built-in ACME.
- Containerized environment: cert-manager for Kubernetes, Lego for CI/CD pipelines.
- Cloud infrastructure: AWS ACM, Google Cloud Managed Certificates, or Azure App Service Managed Certificates.
- Mixed environment: acme.sh for its flexibility and compatibility with over 150 DNS APIs.
Test renewal with a dry-run before going to production. Verify that the client can renew without human intervention.
Step 3: automate DNS validation
For the dns-01 challenge (required for wildcard certificates), your ACME client must be able to create and delete TXT records via your DNS provider's API. Configure API access with minimal permissions: creation and deletion of TXT records under _acme-challenge only.
If your DNS provider does not offer an API, migrate to one that does. In 2026, the absence of a DNS API is a blocking factor.
Step 4: verify your DNSSEC chain
With SC-085v2, a broken DNSSEC chain blocks certificate renewal. Verify:
- The presence and validity of the DS record at the TLD
- Consistency between the DS and the KSK published in your zone
- The validity of RRSIG signatures (expiration dates)
- Automated rotation of ZSK and KSK keys
See our guide on the DNSSEC chain of trust for the technical details. Use the DNSSEC Checker for a complete diagnostic.
Step 5: set up monitoring
Deploy alerts along three axes:
- TLS certificate expiration: alert at 30 days, 14 days, and 7 days before expiration.
- DNSSEC signatures (RRSIG): alert when signatures approach their expiration date.
- DANE/TLSA records: verify that TLSA records match the active certificate.
Monitoring is the safety net that catches automation failures before they become outages.
Step 6: plan a progressive migration
Do not wait until March 2029 to switch to 47 days. Adopt a progressive plan:
- Now: automate all certificates with 90-day lifetimes (Let's Encrypt default).
- 2026: test Let's Encrypt's 6-day certificates on a staging environment.
- 2027: move to production with certificates of 100 days or less.
- 2028: enable Let's Encrypt's 45-day certificates (opt-in) to validate your pipeline before the deadline.
- 2029: the switch to 47 days is a non-event, your infrastructure is ready.
Action plan: prepare your infrastructure
- Inventory all your certificates: discovery via CT logs, network scanning, CLM tools
- Deploy an ACME client: Certbot, acme.sh, or Lego depending on the environment
- Automate DNS validation: DNS provider API for the dns-01 challenge
- Verify DNSSEC: valid chain of trust, automated key rotations
- Set up monitoring: alerts for certificate expiration + RRSIG + TLSA
- Test with short-lived certificates: Let's Encrypt 90d then 6d to validate the pipeline
FAQ
What is CA/Browser Forum Ballot SC-081v3?
SC-081v3 is a ballot adopted in April 2025 by the CA/Browser Forum that progressively reduces the maximum lifetime of public TLS certificates. The lifetime drops from 398 days to 200 days (March 2026), then 100 days (March 2027), then 47 days (March 2029). It also reduces the DCV (Domain Control Validation) evidence reuse period to 10 days in the final phase.
When do 47-day certificates become mandatory?
47-day maximum certificates become mandatory on March 15, 2029 (Phase 3 of the ballot). Before that date, two intermediate phases apply: 200 days maximum starting March 15, 2026, and 100 days maximum starting March 15, 2027. Certificates issued before each cutoff date remain valid until their natural expiration.
Will my existing certificates be revoked?
No. Already-issued certificates remain valid until their expiration date, regardless of the current phase. SC-081v3 applies only to new certificates issued after each effective date. A 398-day certificate issued on March 14, 2026, will remain valid for its full duration.
Why 47 days and not a round number?
The number 47 corresponds to a 30-day renewal cycle plus a 17-day buffer. If the ACME client renews 30 days before expiration (the recommended practice), 17 days remain as a safety margin in case of renewal failure. This buffer allows time to detect and fix issues before the certificate actually expires.
Are EV and OV certificates affected?
Yes. SC-081v3 applies to all types of public TLS certificates, including DV, OV, and EV. There are no exceptions. The distinction between these types concerns the level of organizational identity verification, not the certificate lifetime. An EV certificate will be limited to 47 days just like a DV certificate starting in March 2029.
What is the DCV reuse reduction?
DCV (Domain Control Validation) reuse allows a CA to reuse proof of domain control to issue multiple certificates without requesting fresh validation. SC-081v3 reduces this window from 398 days to 10 days in the final phase. In practice, every certificate renewal in Phase 3 will require new proof of domain control.
Do I need to switch to Let's Encrypt?
Not necessarily. Let's Encrypt is a solid option for automated DV certificates, but other CAs also support ACME: DigiCert, Sectigo, GlobalSign, and ZeroSSL all offer ACME endpoints. If you need OV or EV certificates, you will need to stay with a paid CA, but with an ACME client for automated renewal.
How does ACME work for automatic renewal?
ACME (RFC 8555) automates the dialogue between your server and the CA. The ACME client proves you control the domain (via an HTTP-01, DNS-01, or TLS-ALPN-01 challenge), the CA verifies the proof, then issues the certificate. The client then schedules automatic renewal before expiration. The entire process runs without human intervention.
What is the connection between SC-081v3 and SC-085v2 (DNSSEC)?
SC-085v2 requires CAs to validate DNSSEC during DCV. SC-081v3 increases the frequency of DCV by shortening certificate lifetimes. Combined, these two ballots create a multiplier effect: 8 renewals per year (47 days) mean 8 DNSSEC checks instead of 1. A broken DNSSEC setup therefore blocks certificate renewal more quickly and more frequently.
Are internal certificates (private PKI) affected?
No. SC-081v3 applies only to certificates issued by publicly trusted CAs (those whose root certificate is included in browser trust stores). Certificates issued by an internal private PKI within your organization are not subject to the CA/Browser Forum Baseline Requirements and are not affected by this reduction.
Glossary
- CA/Browser Forum: a consortium of certificate authorities and browser vendors. It publishes the Baseline Requirements, the normative framework that all public CAs must follow for their certificates to be accepted by browsers.
- Ballot: a proposal to amend the Baseline Requirements submitted for a vote by CA/Browser Forum members. A ballot must achieve a supermajority on the CA side and unanimity on the browser side to be adopted.
- DCV (Domain Control Validation): the process by which a CA verifies that the certificate applicant actually controls the domain. Common methods include DNS-01, HTTP-01, and email. DCV reuse allows existing proof to be reused for subsequent issuances.
- ACME (Automatic Certificate Management Environment): a standardized protocol (RFC 8555) for automating the issuance and renewal of TLS certificates. Used by Let's Encrypt, certbot, acme.sh, Lego, and cert-manager.
- CRL (Certificate Revocation List): a list of revoked certificates published by a CA. CRLs are large (several hundred MB) and rarely checked by browsers, which limits their effectiveness.
- OCSP (Online Certificate Status Protocol): a protocol for real-time verification of a certificate's revocation status. In practice, browsers ignore OCSP errors (soft-fail), rendering the mechanism ineffective. Let's Encrypt dropped OCSP in 2025.
- Crypto-agility: the ability of a system to rapidly migrate to new cryptographic algorithms. Short-lived certificates facilitate this migration by limiting how long an obsolete algorithm remains in service.
- DANE/TLSA: a protocol for publishing the expected certificate for a server in DNS (via DNSSEC-signed TLSA records). Eliminates the dependency on CAs for certificate authentication.
