Certbot certificates for multiple domains

One certbot lineage validates every -d name together—one offline SAN blocks renewal for the whole set.

When this happens

Renew fails naming a host you retired months ago. Acquisition adds brands still listed on a legacy certbot -d line though their DNS now CNAMEs to parking pages. Acquisition integrations frequently append new -d names without migrating DNS off parking pages, so the first renew after M&A fails on the acquired hostname.

Marketing microsites share a cert with apex and API hosts on different DNS providers. Parking pages on unused SANs still require working HTTP-01 or DNS-01 proof. Marketing campaigns spin up vanity hostnames mid-quarter without updating certbot, so renewal week is the first time those names appear on the lineage.

First response

One certbot certificate with many -d names fails if any SAN breaks validation—trim SANs or split lineages.

Searches for certbot multiple domains certificate usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For Certbot certificates for multiple domains, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

One certificate with twelve SANs fails renewal when the forgotten staging hostname stops resolving. Multi-domain certbot runs fail atomically: one bad name blocks reissue for all. Prune SAN lists to names you still control before you chase rate limits. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius. Pause destructive retries until you can cite the last Boulder error type and the challenge mechanism in use; random package reinstalls rarely fix presentation gaps.

See also ACME DNS-01 challenge propagation delays and ACME HTTP-01 challenge failed 403.

Why renewal failed

Boulder validates identifiers atomically for the requested SAN list. Rate limit math is per registered domain; stuffing unrelated brands into one lineage increases duplicate-cert pressure when you reissue repeatedly. Atomic validation means organizational coordination—not just DNS or HTTP technique.

HTTP-01 needs port 80 for each host; DNS-01 needs TXT per applicable zone. HTTP redirects from apex to www do not satisfy validation on both names unless each identifier serves its own token without cross-host shortcuts. Decommission workflows must include removing hostnames from certbot lineages.

Splitting lineages limits blast radius when one team breaks challenges. Split customer-facing and internal admin hostnames across lineages to reduce cross-team SAN churn. Escalate with timestamps, hostnames, and serial comparisons attached so the next engineer does not repeat already-failed renew attempts.

Certbot -d flags accumulate into a single lineage. Boulder validates every identifier. HTTP-01 requires each host reachable; DNS-01 needs each label's token published. Adding -d without updating vhosts leaves unused names that still must pass come renewal. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs. Large SAN sets encourage organizational debt; finance should see SAN count as operational risk like open ports, not merely a CA pricing discussion.

Multiple domains on one cert is not the same as wildcard coverage—you still need DNS-01 for *.example.com. Separate certs per hostname can limit blast radius when one challenge breaks. SAN bloat is an operational risk: every hostname on the lineage becomes a single point of failure for validation weekend noise across unrelated product teams.

Common causes

These patterns drive most certbot multiple domains certificate tickets. They explain why automation logs look green while browsers or APIs still break.

Decommissioned microsite left in certbot conf. Mergers leave acquired domains on one lineage while DNS still points at legacy parking—validation fails for the acquired SAN first. Partner APIs listed on the cert but routed through zero-trust proxies may fail HTTP-01 in production while partners test with static challenge tokens in staging only.

Mixed DNS providers: apex at Route53, legacy www still at registrar.

Copied certbot command from wiki including demo.example.org. Load balancer SNI default cert renewed while per-host certs lag when SAN list mixes shared IP customers.

Diagnose

Read the failing domain name from Boulder JSON in letsencrypt.log. Walk the SAN list in renewal conf and run a lightweight reachability check per hostname before blaming Boulder; one parked domain in the list blocks everyone else on the lineage.

certbot certificates
certbot renew --dry-run

Identify which domain Boulder lists first in failure JSON; fix or drop that name, then dry-run again. Sort failing hosts alphabetically in the ticket; Boulder often validates in deterministic order helpful for bisecting SAN lists. Sort failing hostnames alphabetically and fix the first failure before re-running dry-run; Boulder validation order is stable enough for bisection.

Fix step-by-step

Follow this sequence for certbot certificates for multiple domains. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. Export current SAN list from certbot certificates.
2. Compare against live DNS and product inventory.
3. Remove decommissioned -d entries or fix their challenges.
4. Split unrelated hostnames into separate lineages if needed.
5. Update vhosts to reference correct live paths.
6. Dry-run renew.
7. Verify openssl SAN extension matches expectations.
8. Automate SAN inventory from CMDB.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.
11. Record the final SAN list and owners in the CMDB entry for this lineage.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname on the certificate. Run the same command after any reload or deploy change; acceptance means notAfter moved forward and serial changed versus the incident-opening capture.

How to read the output

Check openssl SAN extension lists every live customer hostname; remove ghosts from certbot configuration before renew. Loop openssl across representative SAN entries from the certificate; the earliest expiring presentation among them is what breaks user trust, even if apex looks fine.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Run certbot certificates and diff SAN list against production DNS inventory. Stakeholder sign-off on SAN diffs should precede any certbot reissue touching more than three unrelated teams.

Reissue with trimmed -d set or split into multiple lineages intentionally. Communicate SAN changes to every team owner before reissue to avoid surprise validation failures Friday night.

Automate CMDB-driven SAN lists for renewals. Publish a short post-incident note listing which hop served stale TLS and which command proved the fix so the next renewal inherits a checklist.

What to automate

Alert when renewal logs mention unknown identifiers before rate limits hit. CMDB-driven SAN lists should gate certbot -d changes through code review.

ssldays checks each public name on the cert because users hit them independently. ssldays checks every hostname on busy SAN certificates independently. ssldays can watch each SAN independently so one broken microsite does not hide behind a healthy apex.