An HTTPS certificate renewal plan should identify every covered hostname, the certificate issuer and profile, the automation that renews it, the validation method, the deploy location, and the person who receives and owns failure alerts. Test renewal before the deadline, verify the served certificate after deployment, and keep a documented recovery path. Calendar reminders alone are not enough for certificates designed to renew automatically.

Build the certificate inventory

List production hostnames, alternate names, redirect hosts, APIs, mail-related web endpoints, and temporary environments that must remain available. For each certificate, record the issuer, account, profile, current validity period, expiration, key location or managed-service owner, validation method, renewal client, deploy target, and service restart or reload requirement.

Name both a service owner and an alert backup. If the certificate is fully managed by a hosting or CDN provider, record which provider account controls it and what domain or DNS permissions the provider requires.

Confirm the actual renewal model

Let's Encrypt's Integration Guide recommends consulting ACME Renewal Information regularly and using automatic renewal with time remaining rather than waiting until expiration. It also recommends reporting renewal errors to the responsible administrator and retrying failures with backoff instead of making uncontrolled requests.

The issuer's current profile matters. Let's Encrypt's profiles documentation lists different certificate lifetimes by profile, including a classic profile and shorter-lived options. Do not copy an old 90-day assumption into a universal checklist. Read the certificate's actual dates and the issuer's current guidance.

Map validation dependencies

Document whether renewal uses HTTP, DNS, or another supported ACME challenge. Identify the web route, DNS API credential, firewall rule, account key, or provider integration that makes validation possible. A certificate can fail to renew even when the website is healthy if the validation path or permission has changed.

Review changes since the last successful renewal: DNS provider migration, proxy settings, nameserver updates, blocked HTTP routes, rotated API tokens, server replacement, container rebuilds, and access changes. Keep credentials only in the approved secret store and grant the smallest access the renewal process needs.

Test before the emergency window

Use the ACME client's documented staging or dry-run method when available. Confirm that the test reaches the correct account, validates every required hostname, writes to the intended location, and can execute the deploy or reload step. Avoid repeated production issuance merely to test automation.

Record a successful renewal event from logs or the provider dashboard. Then inspect the certificate actually served by each hostname. Compare subject names, issuer, validity dates, chain, and the service endpoint. A renewed file on disk is not proof that the web server loaded it.

Route alerts to people who can act

Send failures and upcoming-expiration alerts to a monitored team destination with a named owner, backup, and escalation time. Include the hostname, environment, issuer, failing step, last success, remaining validity, and runbook link. Test the alert path with a harmless controlled event.

Do not rely only on messages sent to the same domain whose certificate may fail. Maintain a separate management route or provider dashboard access for recovery. Review contact addresses when staff or vendors change.

Recovery checklist

  1. Identify the affected hostname and remaining validity.
  2. Check the latest successful renewal and the first failing event.
  3. Verify DNS, challenge routing, account credentials, permissions, and clock accuracy.
  4. Correct the cause and rerun through the supported client workflow.
  5. Deploy or reload the renewed certificate as required.
  6. Inspect the certificate served from outside the hosting environment.
  7. Document the cause, repair, and prevention change.

Review the inventory after a hosting move, DNS change, certificate-profile change, or staff departure. The durable outcome is not a certificate that happens to be valid today; it is a renewal system with tested automation, observable failures, clear ownership, and proof that the public endpoint received the new certificate.

Sources

  1. Integration Guide — Let's Encrypt
  2. Profiles — Let's Encrypt

Related reading