Inventory hostnames, dependencies, and ownership
List every hostname that visitors or integrations use: apex, www, subdomains, APIs, asset hosts, portals, and regional names. For each, record where TLS terminates, who can change it, certificate coverage and expiry, renewal method, and dependencies that generate URLs. A certificate must cover the requested hostname in its Subject Alternative Name list. Include the CMS, CDN, tag manager, object storage, payment provider, email templates, and third-party embeds; these commonly introduce HTTP URLs after the first HTTPS release.
Select a canonical www or apex hostname and redirect the alternative directly to it over HTTPS.
Deploy the certificate and current TLS versions
Configure the web server, reverse proxy, CDN, or load balancer that answers the public request. Install the certificate and required chain, bind them to the intended names, and verify them from outside the hosting network. The browser checks the chain, hostname, and dates; a public warning is a release blocker. Default to TLS 1.3 and retain TLS 1.2 only where compatibility requires it. Disable SSL and TLS 1.0 and 1.1. Use maintained platform guidance rather than a copied legacy cipher list, and keep the server and TLS library patched.
Limit access to private keys and record every system that shares one so replacement reaches all of them.
Redirect HTTP once and make HTTPS canonical
Return a server-side permanent redirect, normally 301 or 308, from each HTTP URL to its equivalent HTTPS URL. Avoid chains: they add delay and more failure points. Publish canonical HTTPS URLs in internal links, canonical tags, sitemaps, structured data, social tags, emails, and application-generated absolute links. Test the home page, a deep page, a query URL, error routes, and hostname variants. When TLS ends at a proxy, configure trusted forwarded-protocol handling so the application does not loop between HTTP and HTTPS.
It can remain available only to redirect or complete a certificate challenge, not to serve a separate public site.
Find and fix mixed content at its source
Mixed content is an HTTPS page requesting a resource over HTTP or another insecure protocol. Browsers may upgrade some media, but they block many risky requests, including scripts, stylesheets, frames, fetch calls, and fonts. Replace every reference with a tested HTTPS URL, a relative URL for your own content, or an approved alternative. Crawl representative templates and inspect developer tools while completing key journeys. Check CSS, JavaScript, CMS blocks, asset manifests, tag-manager entries, downloads, and vendor embeds. A secure page should not offer an HTTP download.
Automatic browser upgrading may still leave an unavailable or unsupported third-party dependency; correct the stored URL.
Automate renewal and rehearse certificate recovery
Treat renewal as an automated deployment, not a calendar reminder. It must renew, deploy to every serving tier, and safely reload the service. Test the same validation route before production expiry. Let’s Encrypt, for example, recommends renewing its 90-day certificates every 60 days; follow the lifecycle for your issuer and platform. Keep certificate names, issuer account, challenge method, automation, key location, targets, and emergency contacts in an inventory. Verify dates from the public endpoint after deployment.
For a failed renewal, check DNS, challenge routing, permissions, issuer access, rate limits, and CDN-to-origin deployment.
Use HSTS only after the HTTPS estate is ready
HTTP Strict Transport Security, or HSTS, is an HTTPS response header that tells browsers to use HTTPS on later visits to a host. Browsers then do not offer visitors a bypass for certificate errors. Send it over HTTPS only and keep the HTTP redirect because HSTS is learned after a secure response unless a preload list applies. Start with a limited max-age and lengthen it after proving renewals and required routes. Do not add includeSubDomains until every present and future subdomain can serve valid HTTPS. Preload is not part of the HSTS specification and merits a separate, long-lived commitment review.
max-age=0 works only after a browser reaches a valid HTTPS response; it cannot repair an unreachable secure host.
Release, test, and roll back without weakening transport
Capture the known-good certificate, edge, and redirect configuration before change. Define who approves a rollback, stage where possible, and change one control class at a time. Immediately check public endpoints from more than one network, follow redirects, inspect the certificate, and complete important visitor actions. Test browsers and client groups that matter to your audience. For payment or regulated flows, ask the payment provider and a qualified security professional to review applicable requirements. If a change breaks HTTPS, restore a validated secure configuration; do not make customer pages HTTP as a workaround.
Capture the hostname, time, client, error, change, and result so the next renewal or migration is easier to diagnose.