SSL and HTTPS Setup for Websites: Certificates, Redirects, and Renewal Checklist

Overview

HTTPS encrypts the connection between a visitor’s browser and your website. It also gives browsers a way to verify that the site is presenting a certificate for the requested domain. In practice, HTTPS depends on several pieces working together: a valid certificate, correct DNS and hosting configuration, a secure TLS endpoint, consistent redirects, and application content that loads without insecure dependencies.

Certificate authorities issue certificates for specific hostnames. A certificate for example.com may not automatically cover www.example.com, a subdomain, or an alternate domain unless those names are included in the certificate’s coverage. Confirm the exact hostnames your visitors use before installation.

Certificate types at a glance

For many websites, a certificate managed by the hosting platform is the simplest option. Managed cloud hosting and site builder platforms may handle issuance, installation, and renewal automatically, but you should still verify the result and know how renewal failures are reported. If you manage the web server yourself, you are responsible for certificate files, permissions, server configuration, reloads, and renewal automation.

Before changing a live site, review related DNS records for a new website and, where possible, test the change on a staging environment using the workflow described in production versus staging websites.

Checklist by scenario

Scenario 1: A new website

1. Confirm the canonical hostname. Decide whether the public address will use the root domain, the www hostname, or another subdomain. Use that choice consistently in links, canonical tags, sitemap URLs, and marketing materials.
2. Point DNS to the correct host. Confirm that the A, AAAA, or CNAME records lead to the intended hosting service. DNS changes can take time to appear consistently, so avoid troubleshooting certificate issuance against an old endpoint.
3. Enable the certificate. Use the hosting panel, website builder, or server tooling to request and install a certificate covering every required hostname. Follow the platform’s current instructions rather than copying an old configuration.
4. Test HTTPS before redirecting. Open each hostname with https://. Check the certificate details, page rendering, forms, images, scripts, and API requests.
5. Redirect HTTP to HTTPS. Once HTTPS works, configure a permanent redirect from HTTP. Preserve the path and query string so a request such as http://example.com/about?ref=mail reaches the matching HTTPS URL.
6. Choose one final hostname. If both the root and www versions are reachable, redirect one to the other. Avoid chains such as HTTP to www HTTP to HTTPS to the final page.
7. Update internal references. Change hard-coded HTTP URLs in templates, content, JavaScript, CSS, feeds, webhooks, and configuration files.

Scenario 2: An existing website moving to HTTPS

1. Back up the site, database, configuration, and deployment files. A backup is useful if a redirect or application change causes an unexpected problem; see this cloud hosting backup and disaster recovery plan.
2. Search the codebase and database for http:// references. Separate your own URLs from third-party resources, because each requires a different fix.
3. Install and test the certificate on the live or staging endpoint before enforcing redirects.
4. Update the application’s base URL and any CMS settings. Review cookies, login callbacks, payment callbacks, API allowlists, and webhook destinations.
5. Apply one permanent redirect at the edge or web-server layer where practical. Test representative old URLs, including pages with parameters and files.
6. Update analytics, search tools, advertising destinations, XML sitemaps, canonical tags, structured data, and social profile links to use the final HTTPS URLs.
7. Monitor logs, uptime, forms, and key conversion paths after launch. Pair this with an existing website uptime monitoring and incident response process.

Scenario 3: A certificate is nearing renewal

1. Record the expiration date, covered hostnames, certificate provider, installation method, and renewal owner.
2. Confirm that automated renewal can complete validation. Check DNS, HTTP validation paths, firewall rules, and any proxy or CDN settings that could intercept the request.
3. Renew in a test or controlled environment when the platform supports it, then verify the newly served certificate from outside your network.
4. Confirm that the web server, load balancer, container, or hosting platform has reloaded the renewed certificate.
5. Keep an alert for renewal failure, not only for expiration. A failed renewal can remain unnoticed until the current certificate stops being accepted.

For automated application deployments, include HTTPS verification in the release checklist. A one-click deployment is convenient, but it should not bypass checks for environment variables, callback URLs, redirects, or certificate coverage. The related one-click website deployment checklist can complement this process.

What to double-check

Browser verification

Open the final HTTPS URL in more than one browser or a private window. Inspect the connection information and certificate details. Check the subject names or alternative names, validity dates, and whether the browser reports a trusted connection. Also test a hostname that should redirect, such as the HTTP version or the non-canonical www version.

Command-line verification

Use tools available in your environment to inspect redirects and response headers:

curl -I http://example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com

The first command should normally show a redirect to HTTPS. The second helps confirm the final response and headers. The OpenSSL command can expose the certificate chain and the certificate presented for the requested hostname. Exact output varies by server and operating system, so treat these commands as inspection tools rather than pass-or-fail tests.

Mixed-content review

Mixed content occurs when an HTTPS page requests a resource over HTTP. Browsers may block active content such as scripts, frames, or form targets, and may warn about or upgrade some passive resources. Use browser developer tools to identify the exact URL. Replace it with an HTTPS endpoint, serve the asset from your own site, update the dependency, or remove it. Do not assume that changing a visible link fixes a script, stylesheet, font, image, iframe, or API request embedded elsewhere.

TLS and server settings

Use the hosting provider’s current secure TLS profile where one is available. If you manage the server, review supported protocol versions, cipher configuration, certificate-chain delivery, and security headers against current platform documentation. Avoid copying settings from an old tutorial without testing compatibility with browsers, clients, APIs, and monitoring tools. Security settings should be changed deliberately, with a rollback plan.

Common mistakes

• Redirecting before HTTPS works. This can create a site-wide failure that is harder to diagnose because every HTTP request is immediately sent to the broken HTTPS endpoint.
• Covering only one hostname. Root and www domains, subdomains, and alternate domains must be considered individually.
• Creating redirect chains. Consolidate redirects so each old URL reaches the final URL in as few steps as practical.
• Ignoring non-page traffic. Review APIs, webhooks, feeds, images, downloads, health checks, and third-party integrations, not just the homepage.
• Forgetting certificate renewal ownership. Record who receives alerts and who can fix DNS, hosting, or validation problems.
• Testing only from the office network. External checks can reveal stale DNS, an incomplete chain, firewall rules, or a different certificate at a proxy or load balancer.
• Changing several infrastructure layers at once. Make DNS, certificate, redirect, and application changes traceable so failures can be isolated.

When to revisit

Use this checklist before launching a new website, migrating hosting, changing domains, adding a subdomain, replacing a CDN or load balancer, or modifying deployment workflows. Revisit it before certificate renewal windows and after receiving a renewal warning. It is also useful during recurring security audits and before seasonal planning cycles when traffic, campaigns, or integrations may change.

Review the process whenever your hosting panel, certificate automation, browser behavior, DNS provider, reverse proxy, or application framework changes. Platform instructions and recommended TLS settings can evolve, so refresh implementation details at least every six months or after a major infrastructure change. Keep the following compact audit with your operations notes:

• Confirm every public hostname and its intended canonical destination.
• Check certificate coverage, trust, chain delivery, and expiration dates.
• Test HTTP-to-HTTPS and non-canonical-host redirects without chains.
• Scan representative pages for mixed content and broken integrations.
• Verify forms, authentication, APIs, webhooks, feeds, and monitoring checks.
• Confirm renewal automation, alerts, ownership, and a documented recovery path.
• Record the test date, environment, observed certificate, and any follow-up work.

Finish by checking the site from an external network and reviewing uptime or error monitoring for the next deployment period. HTTPS is reliable when it is treated as an ongoing hosting and release responsibility, not a one-time installation task.