The Certificate Renews Automatically — But Who Notices When It Does Not?
Why automated TLS renewal still needs external monitoring, escalation, and a practical recovery runbook.
A green padlock in the browser feels permanent. It is not.
TLS certificates expire. Renewals fail. DNS records change. Challenge paths get blocked. New infrastructure inherits old domains only partially. The result is rarely a neat internal alert. Visitors usually see a security warning exactly where trust, enquiries, or revenue should happen.
The dangerous assumption is: “The certificate renews automatically.” Automation reduces manual work. It does not replace monitoring.
Why automated renewal still fails
ACME automates certificate issuance and management. Renewal still depends on several moving parts:
- The ACME client must be running and correctly configured.
- The domain must still point to the expected infrastructure.
- HTTP or DNS challenges must remain reachable and authorized.
- A reverse proxy, CDN, or firewall must not block validation.
- The newly issued certificate must actually be loaded by the active service.
- Wildcard, subdomain, and alternate-domain coverage must remain complete.
A successful cron job therefore does not prove that the website is serving the new certificate.
Five warning signs teams often miss
1. Renewal relies on email reminders
Reminders easily reach the wrong mailbox, a former agency, or an overloaded shared inbox. Critical infrastructure should not depend on somebody noticing one message in time.
2. Monitoring checks only the homepage
An organization may operate certificates for the main domain, www, an app, API, admin area, CDN, mail-tracking domain, or customer subdomains. One green homepage check says nothing about the rest.
3. The certificate renewed but was never activated
A common failure mode is painfully simple: the certificate exists on the server, but Nginx, Caddy, Traefik, or the application process still serves the old file or was never reloaded.
4. Nobody monitors unexpected issuance
Certificate monitoring should not stop at expiry dates. Certificate Transparency data and CAA rules can reveal unwanted or misconfigured issuance. CAA allows domain owners to specify which certificate authorities may issue for the domain.
5. Ownership is undocumented
Who responds at night or over a weekend? Who owns the ACME account? Where are account keys, DNS credentials, and the runbook? Without clear ownership, a small certificate problem becomes a hosting, DNS, and agency archaeology project.
A practical TLS self-check
- Which domains and subdomains require certificates?
- Which service issues and renews them?
- When does every active certificate expire?
- Does an external monitor inspect what a real browser receives?
- Are alerts sent at 30, 14, 7, and 3 days remaining?
- Is the public certificate verified again after renewal?
- Are ACME failures and proxy logs visible centrally?
- Do CAA records exist, and are they still correct?
- Is there a documented manual emergency path?
- Can a second person operate the process without tribal knowledge?
If several answers are missing, the main risk is not the certificate itself. It is the lack of operational readiness around it.
What reliable monitoring should include
- External TLS checks: Verify the certificate served publicly, not merely local files.
- Expiry alerts with escalation: Use several warning windows and more than one responsible recipient.
- ACME and deployment logs: Surface failures before the certificate reaches a critical expiry window.
- A hostname inventory: Include APIs, redirect domains, and rarely used subdomains.
- Post-renewal verification: Confirm that the public serial number, validity period, and chain changed.
- CAA and DNS review: Protective controls must not block the legitimate renewal path.
- A runbook: Document providers, accounts, key ownership, DNS methods, emergency contacts, and recovery steps.
What Website-Pflichtencheck would review
A technical website review can show whether certificate management is merely “somehow automated” or genuinely reliable. It can cover publicly served certificates and chains, expiry periods, hostname coverage, HSTS and HTTPS configuration, CAA records, monitoring, escalation paths, and documented ownership.
The goal is not to add another dashboard. It is to answer one embarrassingly simple question at any time: Who notices first when automated renewal fails—your team or your customers?
If the honest answer is “probably the customers,” it is time for a structured TLS and operations review.