SSL Certificate Authority Fallback Plan for Agencies Managing Client Sites

An SSL certificate authority fallback plan is a documented way for an agency to know the current issuer, renewal method, DNS/hosting access, CAA restrictions, fallback issuance path, and escalation owner before a certificate issue becomes a client-visible outage. It is not a promise that the agency can instantly switch CAs. It is a readiness document that reduces confusion when normal renewal fails.

Use Watchtower to track SSL expiry, issuer, Certificate Transparency, and calendar workflow signals. Use the free agency audit for broader multi-domain SSL, DNS, and domain-expiry review. Use the CertPilot methodology when explaining that CertPilot checks public certificate and DNS signals but does not issue certificates or change certificate authorities.

Quick answer: certificate authority fallback plan

A fallback plan should document:

• Current certificate issuer.
• Current renewal owner.
• ACME or hosting-managed renewal method.
• DNS owner and access path.
• CAA records and allowed CAs.
• HTTP-01 or DNS-01 dependencies.
• Manual issuance option if automation fails.
• Client approval path.
• Escalation contacts.
• Review cadence.

The plan gives the agency a way to act calmly when the usual renewal path breaks.

Why agencies need a fallback plan

Agencies often inherit websites across different hosts and DNS providers. One client uses managed Let's Encrypt certificates. Another uses a CDN certificate. Another has a paid certificate from a commercial CA. Another uses a custom ACME client installed years ago.

Without a fallback plan, the team may discover too late that:

• Nobody knows who owns DNS.
• CAA allows only an old CA.
• The client controls the registrar.
• The hosting provider controls managed SSL.
• The wildcard certificate needs DNS-01.
• Manual issuance requires approval from a security team.

The 200-day SSL certificate timeline shows why shorter lifetimes make renewal planning more important.

Current certificate issuer and renewal path

Start by documenting the visible current state:

| Fallback item | What to document | Why it matters | Review frequency | |---|---|---|---| | Current issuer | CA shown on live certificate | Shows current trust path | Monthly or after migration | | Renewal method | Managed host, ACME client, CDN, manual | Determines troubleshooting path | On onboarding and after changes | | Challenge method | HTTP-01, DNS-01, or platform-managed | Defines dependencies | On renewal architecture review | | DNS owner | Provider and responsible person | Needed for CAA or DNS-01 changes | Quarterly | | CAA policy | Authorized CAs and wildcard rules | Can block fallback CA | Before renewal windows | | Escalation path | Host, DNS owner, client approver | Reduces incident delay | Every client review |

Hosting-managed certificates

Hosting-managed SSL is convenient until it fails. The agency should document:

• Which host or platform manages renewal.
• Whether the certificate is automatic.
• Whether the client plan supports SSL.
• Whether the domain points to the expected platform.
• What support channel handles certificate failures.
• Whether the platform uses Let's Encrypt or another CA.

CertPilot can show public certificate and DNS signals. It cannot log in to the host or change managed SSL settings.

ACME client-managed certificates

If a server-side ACME client manages renewal, document:

• Client software.
• Server owner.
• Renewal schedule.
• Challenge method.
• Log location.
• Account owner.
• Whether staging or production endpoints are used.
• Who can restart or repair the client.

The ACME renewal incident runbook turns this documentation into an incident workflow.

DNS-01 and HTTP-01 dependencies

HTTP-01 depends on public HTTP validation. DNS-01 depends on DNS TXT records. They create different fallback needs.

For HTTP-01:

• Port 80 should be reachable if the renewal path requires it.
• Challenge path should not be blocked.
• Redirects should not break validation.

For DNS-01:

• DNS owner must be known.
• API credentials or manual DNS process must work.
• _acme-challenge records must publish correctly.
• Wildcard certificates usually depend on this path.

Use the HTTP-01 vs DNS-01 guide for a deeper comparison.

DNS and registrar access

Fallback plans often fail because the agency lacks access:

• DNS provider login.
• Registrar login.
• Nameserver control.
• CDN dashboard.
• Host control panel.
• Client approval for emergency DNS edits.

Document who has access before an incident. The DNS record inventory guide is useful when building this map.

CAA restrictions and fallback CA choices

CAA can restrict which CAs may issue. If your fallback CA is not authorized, the fallback may fail.

Document:

• Current issue records.
• Current issuewild records.
• Whether letsencrypt.org is allowed.
• Whether another CA is allowed.
• Whether validation methods are restricted.
• Who can approve CAA changes.

The Let's Encrypt CAA troubleshooting guide covers troubleshooting detail.

Manual issuance considerations

Manual issuance is sometimes the fallback, but it is rarely instant. It may require:

• Domain validation.
• DNS changes.
• CSR generation.
• Private key handling.
• Hosting upload.
• Client security approval.
• Paid CA purchase.
• Platform support.

Do not promise manual issuance as a guaranteed same-hour fix unless your agency has tested the path for that client stack.

Client communication and approval path

The fallback plan should include:

• Who approves DNS changes?
• Who approves paid certificate purchase?
• Who approves temporary platform changes?
• Who receives incident updates?
• What language should be used for client-facing communication?

Use the SSL renewal failure client communication template for incident messages.

Fallback plan template

Copy this structure into your client operations note:

Client:
Primary hostname:
Current certificate issuer:
Current renewal owner:
Renewal method:
Challenge method:
DNS provider:
DNS owner:
Hosting provider:
CAA records:
Wildcard certificates:
Fallback CA option:
Manual issuance path:
Required approvals:
Escalation contacts:
Last reviewed:
Next review:

Keep the plan short enough that support can use it during an incident.

SSL certificate fallback planning checklist

• [ ] Current issuer documented.
• [ ] Renewal method documented.
• [ ] Challenge method documented.
• [ ] DNS owner documented.
• [ ] Hosting owner documented.
• [ ] CAA policy reviewed.
• [ ] Wildcard certificate status checked.
• [ ] Manual issuance path documented.
• [ ] Client approval path documented.
• [ ] Escalation contacts documented.
• [ ] Review date scheduled.

How Watchtower and Audit fit

Watchtower helps agencies see certificate expiry, issuer, CT activity, and calendar reminders. Audit helps review multiple domains across SSL, DNS, domain expiry, and related public signals. These tools support the fallback plan by keeping public evidence current.

They do not switch CAs, issue certificates, renew certificates, or change DNS automatically.

What CertPilot can and cannot automate

CertPilot can help agencies detect renewal risk, review public certificate/DNS/CAA signals, and document client-ready monitoring workflows. It cannot issue certificates, act as a CA, replace an ACME client, log in to a host, or manage DNS hosting.

Related Resources

• SSL monitoring Watchtower guide for agencies
• Track SSL expiry across client websites
• ACME renewal incident runbook
• CAA records and client SSL renewals
• Client website health report template

Frequently Asked Questions

What is an SSL certificate authority fallback plan?

An SSL certificate authority fallback plan documents what an agency will check and who owns the next action if the usual certificate renewal path fails. It includes current issuer, renewal method, DNS owner, CAA policy, fallback CA options, manual issuance path, approvals, and escalation contacts.

Does CertPilot switch certificate authorities?

No. CertPilot does not switch certificate authorities, issue certificates, or renew certificates. It helps agencies review public certificate, DNS, CAA, and expiry signals so they can route work to the right host, DNS owner, ACME client owner, or certificate provider.

Should every agency have a backup certificate authority?

Not always as an active vendor, but every agency should know the fallback path for important client sites. For some managed hosts, the fallback is host escalation. For custom infrastructure, it may be manual issuance or another ACME path. The point is to know the path before renewal fails.

How does CAA affect fallback planning?

CAA can restrict which certificate authorities may issue for a domain. If your fallback CA is not authorized by CAA, fallback issuance may fail until DNS is changed. Agencies should review issue, issuewild, and validation-method restrictions as part of planning.

Can Watchtower prevent certificate incidents?

No tool can guarantee incident prevention. Watchtower helps agencies track expiry, issuer, CT signals, and reminder workflows. Earlier visibility reduces surprise, but the actual renewal still depends on the host, DNS, ACME method, CA, and operational owner.

How often should fallback plans be reviewed?

Review fallback plans during onboarding, after hosting or DNS migrations, after certificate incidents, and before major certificate lifecycle changes. For high-value clients, quarterly review is reasonable. The key is to update the plan whenever ownership, DNS, host, or CA policy changes.