Choosing a Certificate Authority for 47-Day Certificates: The Most Reliable SSL Providers

Which SSL providers are most reliable for long-term certificate management? Until recently the question was about warranty amounts and site seals. Under CA/Browser Forum ballot SC-081 it is about something more mechanical: whether a certificate authority lets you renew eight or more times a year per hostname, without a human, and tells you when it needs you to renew early. This guide compares nine CAs on exactly that, then shows how to make any of them survivable by running two.

The CA/Browser Forum 47-day schedule, briefly

Ballot SC-081 cuts the maximum lifetime of publicly trusted TLS certificates in three steps, and the domain validation reuse period shrinks with it.

Some CAs are moving faster than the ballot requires. Let's Encrypt made 45-day certificates available on its opt-in tlsserver profile from May 13, 2026, will move its default profile to 64 days (with 10-day authorization reuse) on February 10, 2027, and to 45 days (with 7-hour authorization reuse) on February 16, 2028.

What happens when TLS certificate validity shrinks

When TLS certificate validity shrinks, every renewal step that involves a person becomes the bottleneck: issuance, domain validation and deployment all happen eight or more times a year per hostname, so anything not automated eventually expires in production.

Three consequences matter for choosing a CA:

• Validation must be automated too. With 10-day validation reuse in 2029 (and 7 hours at Let's Encrypt from 2028), a DNS TXT record someone adds by hand is on the same clock as the certificate. Your CA must support ACME challenges your infrastructure can answer, usually DNS-01 through your DNS provider's API.
• CA incidents hit you faster. When a CA mis-issues, the Baseline Requirements can force revocation within 24 hours or 5 days. With short lifetimes you are renewing often anyway, so the question becomes whether the CA can tell your client to renew now. That is what ARI is for.
• An outage at your CA is now an outage for you. If your renewal window is a few days and your only CA pauses issuance during that window, you have no margin. A second CA turns that into a non-event.

Certificate authorities compared for 47-day certificates

For automated 47-day renewal, the capabilities that matter are ACME support, ARI, whether account setup needs External Account Binding (EAB), and whether you can get OV or EV over ACME. The ARI column reflects whether each CA's public ACME directory advertises a renewalInfo endpoint, which we checked on September 24, 2026.

"None major found" means we found no distrust or mass-revocation event in public sources, not that the CA has a perfect compliance record. Every CA files incident reports; the public list is on Mozilla's Bugzilla.

What the reliability record actually tells you

No CA is immune to incidents, so the useful signal is how an incident reaches you: a short issuance pause, a forced revocation with a 24-hour deadline, or a browser distrust that ends the CA's certificates entirely.

• Issuance pauses are the mildest. Let's Encrypt's May 2026 pause lasted about two and a half hours and required nothing from subscribers whose clients retried. With a sensible renewal window (start at two-thirds of the lifetime) nobody should notice.
• Mass revocation is the one that breaks manual processes. DigiCert's 2024 event gave customers 24 hours to replace certificates. With ARI, a CA can move the suggested renewal window forward and compliant clients renew on their own. Let's Encrypt's March 2026 mass-revocation simulation (run in its staging environment) used exactly that: ARI responses telling affected clients to renew immediately.
• Distrust is the rarest and the most expensive. Chrome stopped trusting new Entrust certificates with SCTs after November 11, 2024, and new Chunghwa Telecom and Netlock certificates issued after July 31, 2025. Buypass left the TLS market on its own in 2025. In every case existing certificates stayed valid until expiry, which with short lifetimes means you have weeks, not a year, to move.

The practical conclusion: pick a CA that supports ARI, and structure things so that switching CA is a config change, not a project.

Automating 47-day certificate lifecycles

Automating 47-day certificate lifecycles means an ACME client on every endpoint (or a proxy or load balancer that holds the certificate for it), DNS-01 or HTTP-01 validation with no manual step, ARI enabled so the CA can pull renewal forward, and deployment that reloads the service without a person.

1. Use a client that speaks ARI. Certbot (4.1.0 and later), lego, acme.sh and Caddy's ACME library support it. Let's Encrypt explicitly recommends ARI in its 45-day announcement.
2. Prefer DNS-01 with scoped API credentials. It works for wildcards and hosts that are not reachable on port 80, and it keeps working as validation reuse approaches zero.
3. Renew at two-thirds of the lifetime, not at the last minute. For a 47-day certificate that is around day 31, leaving about two weeks to notice and fix a failure.
4. Store EAB credentials like any other secret. Google Trust Services, ZeroSSL, Sectigo, DigiCert, GlobalSign, SSL.com and Actalis bind ACME accounts to an external account. Losing those credentials during an incident is an avoidable delay.
5. Replace or proxy what cannot run ACME. Appliances with a certificate upload form do not survive eight renewals a year; terminate TLS in front of them instead.

Use two CAs, and authorize both with CAA

The most reliable setup for long-term certificate management is not a single best CA: it is a primary and a fallback CA, both configured in your ACME tooling and both authorized in your CAA records, so a pause, revocation or distrust at one does not stop renewals.

Many ACME clients support this directly. Caddy tries multiple issuers in order; with certbot, lego or acme.sh you can keep a second account registered and switch the directory URL. The common pairing is two free DV CAs from different operators, for example Let's Encrypt with Google Trust Services, or a paid OV CA as primary with a free DV CA as emergency fallback.

Your CAA records must name both, or the fallback CA is required to refuse:

example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issue "pki.goog"
example.com.  CAA 0 iodef "mailto:security@example.com"

Use the identity each CA publishes (the caaIdentities value in its ACME directory): letsencrypt.org, pki.goog, sectigo.com (also covers ZeroSSL), ssl.com, digicert.com, globalsign.com. If you add any issuewild record, it alone controls wildcards, so list both CAs there too. For tighter control, RFC 8657 lets a CAA record pin issuance to a specific ACME account with accounturi, which Let's Encrypt honors.

Test the fallback before you need it. Issue one real certificate from the second CA on a low-risk hostname each quarter, so you know the account, EAB credentials and DNS permissions still work.

Monitoring: the part no CA does for you

A CA can issue on time and your certificate can still expire in production, because the failure is usually in deployment: the renewed certificate never reached the CDN edge, load balancer or second server. External monitoring is the backstop, and with two CAs it also needs to know which issuers are expected.

What to watch, and where Attack Surface Scan fits:

• Certificate transparency against an authorized-CA list. Attack Surface Scan reads CT logs every 15 minutes, compares each new certificate for your domains against the CAs you have authorized, and puts anything from an unexpected issuer into an unknown-certificate queue. Adding your fallback CA to that list is part of setting it up.
• Stalled renewals. It probes the certificate each hostname actually serves, daily or every 6 hours, and flags a certificate still being served after it should have been replaced, which is the earliest outside sign that a renewal job or deployment has stopped. Expiry warnings follow at 30, 14, 7 and 3 days.
• CAA changes. CAA is among the DNS records it tracks, with an alert when they change, so a fallback CA that quietly gets removed from CAA does not surprise you mid-incident.
• Hostnames you forgot. Subdomains found in CT logs are added to monitoring automatically.

What it does not do: it does not issue or renew certificates, run your ACME client or read its logs, and it only sees hostnames reachable from the internet on domains you have verified. For the full monitoring setup see how to monitor SSL certificate expiry, and for other tools the best SSL certificate monitoring tools.

Which CA to choose

For most teams, a free ACME CA with ARI as primary plus a second operator as fallback is the most reliable combination; pay for a commercial CA when you need OV or EV, a support contract, or centralized management across many accounts.

• Web apps, APIs and SaaS on DV: Let's Encrypt primary, Google Trust Services fallback (or the reverse).
• You need OV or EV: Sectigo, DigiCert or GlobalSign over ACME with EAB, plus a free DV CA authorized in CAA for emergencies on hosts where DV is acceptable.
• You want a non-US operator: Actalis (Italy) offers free DV over ACME.
• You still use Buypass: it no longer issues; migrate and remove it from CAA.

Frequently asked questions

Sources

• CA/Browser Forum Ballot SC-081v3: schedule of reducing validity and data reuse periods
• RFC 9773: ACME Renewal Information (ARI) Extension
• Let's Encrypt: Decreasing certificate lifetimes to 45 days
• Let's Encrypt: Simplifying certificate renewals with ARI
• Let's Encrypt: 2026 mass revocation simulation
• Let's Encrypt: CAA and RFC 8657 parameters
• Let's Encrypt: May 2026 issuance halt (status history)
• Let's Encrypt ACME directory
• Google Trust Services: ARI version update
• Google Cloud: request a certificate from Public CA with EAB
• ZeroSSL ACME documentation
• Sectigo ACME directory (OV)
• Sectigo acquires Entrust public certificate business
• DigiCert: ACME integration (ACME and ARI support)
• Mozilla Bugzilla 1910322: DigiCert random value in CNAME without underscore prefix
• GlobalSign announces ACME OV certificate support
• SSL.com: order free 90-day SSL/TLS certificates with ACME
• Actalis: free and unlimited DV certificates over ACME
• Buypass: discontinues issuance of TLS/SSL certificates
• Chrome Root Program: upcoming change for Entrust CAs
• Google: upcoming changes to the Chrome Root Store (Chunghwa Telecom, Netlock)
• RFC 8659: DNS Certification Authority Authorization (CAA)
• RFC 8657: CAA record extensions for account URI and ACME method binding