SSL Certificate Checklist for Website Migrations and Deployments

Overview

Use this guide as a practical SSL deployment checklist for website migrations and new releases. The goal is simple: make sure HTTPS works cleanly before, during, and after deployment.

For most teams, SSL and TLS work is not just about installing a certificate. It touches DNS, load balancers, CDNs, reverse proxies, application redirects, cookies, HSTS, asset URLs, and certificate renewal workflows. That is why SSL issues often surface during platform changes, CDN swaps, web server upgrades, blue-green rollouts, or domain migrations.

A reliable process starts with a few assumptions:

• You know which domains and subdomains the site will serve.
• You know where TLS terminates: CDN, ingress, load balancer, proxy, or application server.
• You have access to DNS, certificate management, and deployment configuration.
• You can test in a non-production environment that resembles production behavior.

Before you begin, document the current state and the target state. That single step reduces a surprising number of mistakes.

Document the current state

• Primary domain and any alternate domains
• WWW and non-WWW behavior
• All subdomains used by the application, API, assets, admin panels, and status pages
• Where certificates are currently issued and renewed
• Current redirect rules from HTTP to HTTPS and between hostnames
• Existing HSTS configuration
• Cookie settings that depend on secure transport

Document the target state

• Final hostname strategy
• Certificate scope: single-domain, SAN, or wildcard
• Validation method: DNS, HTTP, or platform-managed
• Termination point for TLS in the new architecture
• Who owns renewals and alerting
• Rollback path if certificate validation or issuance fails

If your migration also includes DNS changes, review DNS timing and propagation alongside SSL planning. This is especially important when certificate validation depends on DNS records or when cutover timing matters. Related reading: DNS Changes During Website Deployments: TTL, Propagation, and Cutover Planning.

Checklist by scenario

This section gives you a reusable HTTPS checklist by deployment scenario. Use the relevant list, then finish with the shared post-deployment checks.

Scenario 1: New website or first HTTPS setup

• List every hostname that must be covered by the certificate.
• Decide whether you need a single hostname, multiple SAN entries, or a wildcard certificate.
• Confirm where TLS will terminate and who manages certificates there.
• Choose a validation method your team can reliably repeat.
• Issue the certificate before launch day when possible.
• Install the full certificate chain correctly on the serving layer.
• Force HTTP to HTTPS with a simple redirect rule.
• Update canonical URLs, sitemap URLs, and internal links to HTTPS.
• Set secure cookie attributes where required.
• Test homepage, login, checkout, forms, APIs, and static assets over HTTPS.

Scenario 2: Domain migration or hostname change

• Inventory old and new domains, including marketing pages, app endpoints, and legacy subdomains.
• Issue certificates for the new domain before traffic is switched.
• Keep valid certificates on the old domain long enough to serve redirects safely.
• Plan redirects from old URLs to new HTTPS destinations without chaining.
• Update CDN, reverse proxy, load balancer, and application hostname configuration.
• Check that validation records and issuance steps are compatible with the new DNS provider.
• Update CSP, CORS, webhook endpoints, OAuth callbacks, and API clients that reference old domains.
• Retest all flows that cross domains or rely on third-party redirects.

For the environment side of this work, it helps to separate testing, preview, and production behavior clearly. See Staging vs Preview vs Production Environments: What Every Team Needs.

Scenario 3: Infrastructure migration with the same domain

• Verify whether the existing certificate can be reused or if the new platform requires reissuance.
• Confirm private key handling and access controls if you are moving certificates manually.
• Test TLS configuration on the new load balancer, ingress, or proxy.
• Match redirect behavior between old and new environments.
• Check ALPN, HTTP/2, and proxy forwarding settings if relevant to your stack.
• Make sure health checks do not bypass the HTTPS behavior you expect users to receive.
• Prepare rollback steps that preserve certificate validity on both old and new targets.

Scenario 4: CDN, WAF, or reverse proxy change

• Confirm whether the edge platform terminates TLS, re-encrypts to origin, or both.
• Check origin certificate requirements separately from public browser-facing certificates.
• Validate the hostname presented at the edge and the hostname expected at the origin.
• Review redirect rules in both the edge layer and the application to avoid loops.
• Confirm caching rules do not preserve old redirect responses after cutover.
• Retest asset delivery from CSS, JS, fonts, and images over HTTPS.

Scenario 5: Kubernetes or container-based deployment

• Confirm whether certificates are handled by ingress, service mesh, external load balancer, or cert management tooling.
• Check secret names, namespaces, and mount references carefully.
• Verify the ingress host rules exactly match the certificate hostnames.
• Confirm automation for renewal updates the active secret and triggers reload behavior if needed.
• Test blue-green or rolling changes without replacing a valid secret with an incomplete one.
• Make sure the application trusts forwarded proto headers so redirects and secure links are generated correctly.

If you are combining certificate changes with rollout strategy work, pair this with Blue-Green vs Canary vs Rolling Deployments for Web Apps and Zero-Downtime Deployment Guide for Websites and Web Apps.

Shared post-deployment HTTPS checklist

• Open the site in a private browser session and confirm the certificate is valid.
• Check the certificate covers the expected hostname.
• Test both HTTP and HTTPS entry points.
• Test both WWW and non-WWW if both are in scope.
• Visit common landing pages, account flows, form pages, and static asset URLs.
• Verify no mixed-content warnings appear in the browser console.
• Run a redirect check and remove extra hops.
• Confirm APIs, webhooks, and callbacks still negotiate HTTPS correctly.
• Review server logs, CDN logs, and error monitoring for TLS or redirect anomalies.
• Verify certificate renewal ownership, expiry alerts, and documentation before closing the deployment.

For broader release coordination, this pairs well with Website Deployment Checklist for Production Releases and CI/CD Pipeline for Websites: Best Practices by Stack.

What to double-check

These are the details teams most often assume are fine. They are worth checking explicitly every time.

1. Certificate coverage

A valid certificate is not enough if it does not match the hostname a user is visiting. Check every host that matters:

• example.com
• www.example.com
• app.example.com
• api.example.com
• assets.example.com

Be especially careful when a wildcard is expected to cover a root domain. Wildcards and apex domains do not always behave the way teams assume.

2. Redirect design

You want a clean path from any old or insecure URL to the final HTTPS URL. Double-check:

• HTTP to HTTPS redirects exist.
• Old domain to new domain redirects exist if applicable.
• WWW to non-WWW, or the reverse, is consistent.
• There are no loops between app, proxy, and CDN layers.
• Redirects are not chained through multiple intermediate URLs.

3. Mixed content

Even when the main page loads over HTTPS, browsers may block insecure scripts, styles, fonts, images, or API calls. Check:

• Hard-coded http:// links in templates or CMS content
• Asset URLs embedded in CSS or JavaScript
• Third-party embeds and tags
• Legacy image libraries or static content stores
• API endpoints referenced by the frontend

4. Application awareness of HTTPS

Many frameworks need to know the original request was secure, especially behind a proxy or load balancer. If that trust is misconfigured, the app may generate incorrect redirects, insecure links, or cookies without secure flags. Confirm:

• Forwarded headers are set correctly.
• The application trusts the proxy layer where appropriate.
• Canonical URLs and generated links use HTTPS.
• Session and auth cookies use secure settings.

5. Renewal path

A working certificate at launch is only half the job. Double-check the long-term maintenance path:

• Who receives expiration alerts?
• Is renewal automatic or manual?
• Does DNS validation depend on records that might be removed later?
• Does renewal require a server reload or pod restart?
• Is renewal tested in a way the team understands?

6. Staging and preview behavior

Staging often hides SSL issues because it uses different hostnames, temporary certificates, or relaxed browser trust assumptions. Test in an environment that reflects production routing as closely as possible. If production uses a CDN and proxy combination, try to validate that path before launch rather than only checking the application directly.

Common mistakes

This section is a short list of failure patterns worth keeping near your runbook.

Installing a certificate for the wrong hostname

This often happens during migrations where teams issue a certificate for the new app endpoint but forget the public hostname users actually enter.

Removing the old certificate too early

If the old domain still needs to redirect users to the new one, it still needs valid HTTPS. Redirect targets do not help if users cannot establish a secure connection to the old host first.

Splitting redirect logic across too many layers

One redirect at the edge and another in the application may be fine. Three overlapping rule sets across CDN, load balancer, and app usually invite loops or inconsistent behavior.

Forgetting non-page endpoints

Teams commonly test the homepage and a few UI routes, then miss API hosts, webhook receivers, file upload endpoints, asset buckets, or admin paths.

Ignoring mixed content in old content or templates

Legacy blog posts, CMS blocks, theme files, and embedded scripts are common sources of browser warnings after an otherwise clean HTTPS launch.

Assuming auto-renewal means no monitoring

Automation reduces manual work, but it still needs visibility. Renewals can fail because of DNS changes, platform permissions, secret update issues, or altered validation paths.

Setting HSTS too aggressively during a migration

HSTS can be useful, but it is safer to enable or expand it only after you are confident all hosts and redirects behave correctly. During a migration, an overly aggressive setting can make recovery harder if a hostname is misconfigured.

Not documenting ownership

Certificates tend to break at team boundaries: platform manages the load balancer, security owns DNS approval, app teams own redirects, and no one owns expiry alerts. Clear ownership is part of the SSL checklist, not a separate administrative task.

When to revisit

SSL setup is not a one-time project. Revisit this checklist whenever the inputs change, especially before release windows or infrastructure updates.

Revisit before:

• Domain migrations or rebrands
• CDN, WAF, or DNS provider changes
• Load balancer, ingress, or reverse proxy replacements
• Kubernetes ingress or secret management changes
• Moving from VM-based hosting to containers or platform services
• Enabling new subdomains, APIs, or regional endpoints
• Seasonal release cycles with higher traffic or reduced staffing
• Changes to CI/CD workflows or certificate automation

Run a light review every quarter:

• List active domains and subdomains.
• Confirm certificates still match what is live.
• Check expiration monitoring and alert recipients.
• Verify redirect behavior has not drifted.
• Spot-check for mixed content on critical templates.
• Review HSTS, cookie, and proxy-related settings after infrastructure changes.

Keep a short operational runbook:

• Where certificates are issued
• How validation works
• Who owns renewals
• How to test pre-production
• How to roll back safely
• What logs and monitors to review after deployment

The simplest way to make this article useful long term is to turn it into your team’s own preflight checklist. Add your real domains, your termination points, your certificate provider, your redirect rules, and your alerting owners. Then review it any time architecture, DNS, or deployment workflows change. SSL failures are usually preventable, but only if HTTPS is treated as part of deployment design rather than a task tacked on at the end.