SSL Certificate Renewal: A Checklist for Preventing HTTPS Outages

Overview

An SSL certificate enables a website to use HTTPS and helps browsers establish an encrypted connection with the server. In practice, renewal involves more than obtaining a new certificate. You also need to confirm that the certificate covers the correct hostnames, complete the required domain validation, install the renewed certificate and its private key, reload the web server, and test the result from outside your infrastructure.

Most certificate outages are preventable when renewal is treated as a monitored process rather than a date on a calendar. Record the certificate owner, hosting environment, validation method, renewal mechanism, and expiry date in one inventory. Include certificates for the main domain, www, APIs, staging environments, mail-related services, and any subdomains that terminate TLS separately.

The exact controls depend on your hosting setup. A managed cloud hosting platform or hosting panel may request approval and renew certificates automatically. A self-managed VPS, container platform, reverse proxy, or load balancer may require scheduled jobs and explicit certificate deployment. If the site has recently moved servers, changed DNS providers, or changed its domain structure, review the certificate process before the next renewal window. The related domain, DNS, SSL, and email setup guide can help map those dependencies.

What to track

Certificate scope and expiry

For every certificate, record:

• The certificate subject and all names listed in its Subject Alternative Name (SAN) field.
• The issuing certificate authority and certificate type, such as single-domain, multi-domain, or wildcard.
• The start and expiry dates, plus an internal renewal deadline that comes before expiry.
• Every server, CDN, load balancer, container, or hosting panel where the certificate is installed.
• The person or team responsible for renewal and the location of relevant credentials or configuration.

Do not assume that a wildcard certificate covers every hostname you use. A wildcard normally covers one level beneath a domain, while a deeper hostname or a different parent domain may need separate coverage. Check the names presented by the live endpoint instead of relying only on the filename of a certificate.

Validation and DNS dependencies

Certificate authorities commonly validate control of a domain through DNS, HTTP, or email-based methods, depending on the certificate process. DNS validation uses a designated TXT record. HTTP validation requires a token to be available at a specific path on the requested hostname. Track which method is configured and who can change the relevant DNS zone or webroot.

Pay particular attention to DNS changes during a migration. A stale validation record, an incorrect authoritative nameserver, a proxy that does not pass the validation request, or a redirect that interferes with the challenge can prevent renewal. For wildcard certificates, DNS-based validation is often the practical choice, but confirm the requirements of the certificate authority and tool you use.

Automation and deployment

Automated SSL renewal is only reliable when the entire chain is automated. Check that the renewal client runs, can complete validation, installs the new files, reloads the service, and reports failures. A successful certificate request does not guarantee that every production endpoint is serving the new certificate.

On a Linux server using Certbot, an administrator might inspect configured renewals with:

sudo certbot renew --dry-run

The exact command and supported options vary by operating system, web server, package, and certificate authority. Treat a dry run as a test of the renewal path, not as proof that all load balancers or replicas have been updated. For an Nginx or Apache deployment, confirm that the service reload hook is configured and review its logs after a test.

Monitoring and user-facing behavior

Monitor certificate expiry from outside the server network and check each important hostname over HTTPS. The monitor should identify the hostname, expiry date, certificate-name mismatch, trust-chain problem, and connection failure separately where possible. Also track application-level symptoms such as redirect loops, mixed content, failed API calls, and payment or login requests that fail after an HTTPS change.

Cadence and checkpoints

Use a layered schedule rather than one reminder. The following cadence is a practical starting point; adjust it to your certificate lifetime, change-management process, and risk tolerance.

• At least quarterly: review the certificate inventory, ownership, renewal method, DNS access, and monitoring contacts.
• Monthly: inspect expiry alerts, failed renewal attempts, certificate-authority notifications, and changes to hosting or DNS.
• Before the internal renewal deadline: run a renewal test, confirm that validation records are present, and verify that deployment reaches every production endpoint.
• After renewal: test the public website, important subdomains, API clients, redirects, static assets, and any service that uses the certificate directly.
• After infrastructure changes: repeat the checks whenever you change nameservers, DNS records, hosting, a CDN, a reverse proxy, a load balancer, or a domain name.

For a command-line inspection of a public endpoint, this OpenSSL example displays the dates and names presented by the server:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

Replace the hostname with the endpoint you need to test. Run the check against each important hostname and, where relevant, against each load-balanced origin. A browser check alone may not reveal that one backend still has an older certificate.

How to interpret changes

A renewal failure should be classified before anyone changes production configuration. If validation fails, inspect DNS delegation, TXT-record spelling, propagation, HTTP challenge paths, redirects, firewall rules, and proxy behavior. If renewal succeeds but users still see an old certificate, inspect the deployment hook, service reload, CDN configuration, and every backend behind the public address.

If the browser reports that the HTTPS certificate has expired, first confirm the error from an independent network and check the live certificate with a command such as the OpenSSL example above. Then identify whether the problem affects one hostname, one server, or the entire service. Avoid deleting the existing private key or certificate files until you have established a rollback path and confirmed which configuration is active.

A name mismatch usually means the requested hostname is absent from the certificate SAN list, not that the certificate is simply too old. A trust error can indicate an incomplete certificate chain, an untrusted issuer in the client environment, or a misconfigured endpoint. Mixed-content warnings are different: they occur when an HTTPS page requests insecure HTTP resources. Renewing the certificate will not fix those URLs; update application configuration, templates, or asset links separately.

After a successful fix, record the cause and the preventive change. For example, document a DNS permission problem, add an alert for the validation record, or make the deployment hook reload every service. If certificate rotation is part of a larger hosting move, pair this work with a tested recovery plan such as the cloud backup and restore testing workflow.

When to revisit

Revisit this checklist monthly or quarterly, depending on how many domains and environments you manage. Perform an additional review immediately after changing hosting providers, nameservers, DNS records, CDN settings, reverse proxies, load balancers, domain ownership, or certificate automation. Also review it when a certificate authority changes its validation process or when your hosting panel or deployment tooling introduces a new renewal workflow.

If a certificate has expired, use this incident sequence:

1. Confirm the affected hostname and the certificate currently served from the public endpoint.
2. Check whether an unexpired certificate is already available in the hosting panel, certificate store, or renewal client.
3. Restore the last known-good certificate configuration if it is still valid and deployment is the immediate problem.
4. If renewal is required, correct DNS or HTTP validation and issue the replacement certificate through the approved process.
5. Install the certificate on every relevant endpoint, reload services safely, and verify the public result.
6. Check redirects, mixed content, APIs, login flows, and business-critical transactions.
7. Document the root cause, add or correct monitoring, and schedule a follow-up test.

Keep this article with your domain and hosting runbook. Before each renewal cycle, confirm the names on the certificate, the validation path, the renewal job, the deployment targets, and the alert recipient. That short review turns SSL certificate renewal from an emergency response into a repeatable part of secure website operations.