SSL Certificate Renewal and HTTPS Audit Guide for Domains and Cloud Servers

Overview

An SSL certificate enables a service to establish an encrypted connection over HTTPS. In practice, teams often use “SSL” as shorthand for certificates and TLS configuration, although modern systems use TLS rather than the older SSL protocols. A certificate can be valid at the edge of a CDN while the connection from the CDN to the origin server remains misconfigured, so HTTPS checks must cover the entire delivery path.

Certificate renewal and HTTPS auditing belong in the same operational workflow. Renewal prevents an otherwise healthy website from becoming unavailable or displaying certificate warnings. An audit checks whether every hostname is covered, whether the correct certificate is being served, whether redirects and resources use HTTPS, and whether administrative processes will continue to work after a change.

Use this guide alongside a broader website launch checklist when adding a new site, moving to cloud hosting, or changing DNS. For a larger portfolio, maintain one inventory for domains, DNS dependencies, certificates, hosting locations, and owners rather than relying on browser warnings to reveal problems.

What to track

1. Build a certificate inventory

Record each certificate and every hostname it protects. Include production, staging, API, administrative, monitoring, and redirect-only endpoints where applicable. A practical inventory can use these fields:

Do not assume that a wildcard certificate covers every related hostname. A wildcard for *.example.com generally represents one subdomain level and does not automatically cover the bare domain or a deeper name such as dev.api.example.com. Confirm coverage directly in the certificate and in the service configuration.

2. Track domain and DNS dependencies

Certificate validation depends on DNS and routing. Record which DNS provider is authoritative, who can change records, and whether validation relies on a persistent DNS TXT record. Keep validation records separate from application records and document their purpose before removing anything.

For a useful reference on record types and delegation, see DNS records explained. If nameservers, registrars, or hosting providers are changing, test certificate validation as part of the migration rather than after the DNS cutover.

3. Track renewal automation

For every certificate, identify whether renewal is automatic or manual. Automatic renewal is valuable only when the scheduled job runs, validation succeeds, the renewed certificate is installed, and the service reloads the new files. Note the location of logs and the alert recipient for failures.

On a Linux cloud server using an ACME client, an operator might first run a client-specific dry run, such as certbot renew --dry-run, if Certbot is the installed tool. The exact command depends on the client, web server, operating system, and certificate authority. A dry run should be followed by an inspection of the deployed certificate and a service reload test. Never copy a command into production without checking how the current server was configured.

4. Track HTTPS behavior

Check that HTTP redirects to the intended HTTPS URL, the certificate matches the requested hostname, the certificate chain is complete, and the server supports the required TLS configuration. Test the bare domain, the www hostname, each important subdomain, API endpoints, health checks, and any alternate ports exposed to users.

Also look for mixed content: an HTTPS page that requests images, scripts, stylesheets, fonts, or API resources over HTTP. Browsers may block active content or warn about passive content. Search application configuration, templates, database content, environment variables, and third-party integrations—not only the visible page source.

Cadence and checkpoints

At least monthly

• Review certificates approaching their configured renewal warning window.
• Confirm automated renewal jobs ran successfully and produced expected logs.
• Check monitoring alerts for hostname mismatches, expiration warnings, failed handshakes, and redirect changes.
• Test newly added subdomains and services, especially after DNS or hosting changes.

Quarterly

• Compare the certificate inventory with the current DNS zone and deployed infrastructure.
• Remove retired certificates, validation records, cloud resources, and undocumented exceptions.
• Verify that the certificate served externally is the certificate the team expects.
• Test the complete CDN-to-origin path, including origin hostname selection and certificate validation.
• Review access to registrar, DNS, certificate authority, CDN, and cloud-server accounts.
• Run a restore or recovery exercise for certificate files, private keys, configuration, and deployment instructions where appropriate.

Before a planned change

Perform a focused audit before changing nameservers, transferring a domain, replacing a load balancer, moving to a new VPS, changing CDN settings, or adding a subdomain. Confirm the validation method will still work after the change. A DNS-01 renewal may depend on access to the authoritative DNS provider; an HTTP-01 renewal may depend on the web server answering correctly at a specific path. Planning around that dependency can prevent an avoidable outage.

How to interpret changes

Certificate expiration warning

First determine whether the warning concerns the certificate currently served or an unused certificate stored on the server. If the served certificate is near expiration, verify the renewal job, validation records, file permissions, deployment path, and service reload. A renewed file on disk does not prove that the public endpoint is serving it.

Hostname mismatch

A mismatch usually means the request reached the wrong virtual host, load balancer listener, CDN configuration, or default server. Check DNS resolution, the requested hostname, SNI-aware configuration, and certificate coverage. Do not solve a mismatch by adding a certificate without confirming that traffic is reaching the intended service.

CDN works but the origin fails

Some CDN configurations encrypt traffic from the visitor to the CDN but use a separate connection to the origin. Test the origin directly or through an authenticated diagnostic path. Confirm that the origin certificate matches the hostname the CDN uses for validation and that the origin accepts the configured TLS versions and ports. Keep origin access restricted where possible; direct testing should not require exposing unnecessary services.

Mixed-content errors

Start with browser developer tools to identify the blocked URL. Change hard-coded resource URLs to HTTPS or use an appropriate relative or configuration-driven URL. Check redirects carefully: an HTTP resource that redirects to HTTPS can still produce unreliable behavior, and an HTTP API endpoint may fail even when the main page is secure.

HSTS considerations

HTTP Strict Transport Security tells compatible browsers to use HTTPS for a domain after receiving the policy. It can reduce accidental HTTP access, but it also makes recovery from certificate and redirect mistakes more difficult for affected users. Introduce HSTS deliberately, verify all required subdomains and operational endpoints, and avoid broad settings until the team has confirmed that every included hostname supports HTTPS consistently. Treat preload-related settings as a separate decision requiring careful review.

When to revisit

Revisit this guide monthly for renewal status and quarterly for a complete HTTPS audit. Return immediately after adding a domain or subdomain, changing DNS, transferring a domain to a new registrar, migrating cloud hosting, replacing a CDN or load balancer, changing certificate automation, or receiving a browser or monitoring warning.

Standards, certificate authority requirements, browser behavior, ACME client commands, and hosting-panel workflows can change. Before each major renewal cycle, verify the current instructions for the certificate authority and the software installed on your server. Keep the inventory current enough that another operator can identify the endpoint, owner, validation method, and recovery path without reconstructing the system during an incident.

Quarterly HTTPS audit checklist

1. Export or review all active domains, subdomains, CDN endpoints, APIs, and public cloud services.
2. Match each hostname to a certificate, termination point, owner, and expiration date.
3. Confirm automated renewal has a recent successful result and a tested alert path.
4. Check external certificate coverage, chain delivery, redirects, and TLS handshakes.
5. Test CDN-to-origin HTTPS separately from visitor-to-CDN HTTPS.
6. Scan key pages and API clients for mixed-content or hard-coded HTTP references.
7. Review HSTS scope and confirm that every included hostname is ready for HTTPS-only access.
8. Record findings, assign owners, and set a date for remediation verification.

For related operational work, review the domain-to-cloud-hosting connection guide, the cloud-server deployment checklist, and the domain portfolio management checklist. The goal is simple: every public hostname should have a known owner, a tested HTTPS path, a monitored renewal process, and a documented response when something changes.