Website SSL Certificate Management Checklist: Renewal, TLS Testing, and Fixes

Overview

An SSL certificate allows a website to use HTTPS and helps establish an encrypted connection between a visitor’s browser and the web server. In everyday site management, “SSL” is still common terminology, although modern encrypted connections use TLS. The practical management tasks are the same: confirm that the certificate is valid for the requested hostname, has not expired, is presented with its required chain, and is served by the correct website.

A certificate problem can appear as a browser warning, a failed API request, an unavailable subdomain, or a redirect that sends visitors between HTTP and HTTPS. These symptoms may be caused by the certificate itself, DNS, a reverse proxy, a load balancer, application configuration, or cached redirects. A repeatable review process makes it easier to identify the correct layer.

Keep this checklist with your broader website uptime monitoring process. Availability checks and certificate checks complement one another: a site can be online while presenting an invalid certificate, or its certificate can be valid while the application remains unavailable.

What to track

1. Maintain a certificate inventory

List every public hostname that uses HTTPS, not just the main domain. Include the bare domain, the www version, staging or preview environments when they are publicly reachable, and service endpoints such as an API, customer portal, or webmail hostname. Record whether each hostname is served directly by your hosting account, a CDN, a reverse proxy, or another platform.

Do not rely on the domain registrar alone for this inventory. Domain registration, DNS hosting, web hosting, and certificate management may be separate services.

2. Check certificate validity and coverage

For each hostname, verify the expiration date, the hostname coverage, and the certificate chain. A certificate can be within its validity period but still produce a warning if it does not include the requested subdomain or if the server sends an incomplete chain. Check both the bare domain and the www hostname when both are intended to work.

Also confirm that the server is presenting the certificate you expect. During a migration, an old certificate may remain active on one IP address, load-balancer listener, or edge location while the new certificate is installed elsewhere.

3. Test TLS and HTTPS behavior

Use a current browser to inspect the connection details and certificate information. For a more repeatable technical check, run a command such as:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The -servername option matters on servers hosting multiple domains because it requests the certificate for the specified hostname. Review the subject alternative names, validity dates, issuer, and certificates returned in the chain. Treat command-line output as a diagnostic aid, not as a substitute for testing the actual visitor paths.

Test the TLS configuration with a maintained security scanner or your hosting provider’s diagnostic tools. Record whether the endpoint accepts the protocol versions and cipher configurations approved by your organization. TLS guidance and browser behavior can change, so avoid copying a static configuration without checking the current documentation for your server, proxy, or hosting platform.

4. Verify redirects and page resources

Check that an HTTP request reaches the intended HTTPS URL and that it does not create a redirect loop. A useful command is:

curl -I http://example.com
curl -I https://example.com

Confirm the response status, Location header, hostname, and path. Then load representative pages over HTTPS and inspect the browser console for mixed-content warnings. Images, stylesheets, scripts, fonts, forms, canonical URLs, and API calls should use HTTPS or an appropriate relative URL. A valid certificate does not automatically fix insecure references embedded in page content.

Cadence and checkpoints

Monthly review

• Check the inventory for new, removed, or renamed hostnames.
• Review certificate expiration dates and confirm alerts are reaching the responsible owner.
• Open the main domain and important subdomains in a current browser.
• Test HTTP-to-HTTPS redirects and check for mixed-content warnings.
• Review monitoring results for certificate, DNS, and availability errors.

A monthly review is especially useful for small businesses with several vendors. It catches ownership gaps before a renewal becomes urgent.

Before renewal or certificate replacement

1. Confirm the exact hostnames that must be covered.
2. Verify that DNS points to the system performing validation and serving the certificate.
3. Confirm access to the hosting panel, certificate account, or automation credentials.
4. Check whether a CDN, proxy, or load balancer requires a separate installation.
5. Schedule a test immediately after deployment.

Do not wait until the expiry date to discover that an old DNS record, inaccessible validation path, or second server still needs attention. The exact lead time depends on your renewal method, but the operational principle is simple: renew early enough to test and correct the deployment.

After renewal, migration, or DNS change

Test every documented hostname from outside the server network. Check the certificate, redirect chain, page assets, forms, login paths, webhooks, and API requests. If your site uses multiple origins or regions, test each public entry point rather than assuming one successful check represents all of them.

How to interpret changes

Use the symptom to narrow the investigation:

• Expired certificate: Renew or replace it, then confirm that every TLS termination point serves the new certificate.
• Hostname mismatch: Check the requested URL against the certificate’s covered names. The certificate may be valid for the main domain but not a subdomain.
• Untrusted or incomplete chain: Install the required intermediate certificates according to the server or hosting platform’s instructions.
• Wrong certificate after migration: Compare DNS results, IP addresses, virtual-host settings, proxy configuration, and load-balancer listeners.
• Redirect loop: Inspect application redirects and proxy settings. A proxy may receive HTTPS from the browser but pass HTTP information to the origin, causing conflicting rules.
• Mixed content: Update hard-coded HTTP resources, third-party embeds, scripts, stylesheets, and API endpoints.
• Connection or protocol failure: Review the server’s TLS configuration, supported protocol versions, firewall rules, and compatibility requirements.

Record each incident with the hostname, time observed, browser or command output, DNS result, certificate fingerprint if available, recent changes, owner, and resolution. This creates a useful incident worksheet instead of relying on memory.

For sites hosted on cloud infrastructure, include certificate ownership in your hosting documentation. A website launch checklist can help capture DNS, security, and redirect dependencies before a new site goes live.

When to revisit

Review this SSL certificate management checklist monthly and perform a deeper quarterly audit. Revisit it immediately when you add a subdomain, change DNS providers, move hosting, introduce a CDN or reverse proxy, replace a load balancer, change the website builder, or modify redirect and security settings.

Update the procedure when your certificate provider, hosting panel, server software, or TLS policy changes. Browser warnings, certificate-authority requirements, and recommended TLS configurations may evolve, so verify current technical guidance rather than treating an old configuration as permanent.

At your next review, take these five actions:

1. Export or update the hostname and certificate inventory.
2. Check expiry, hostname coverage, chain delivery, and renewal ownership.
3. Run browser and command-line HTTPS tests from an external connection.
4. Confirm redirects, canonical URLs, forms, APIs, and page resources use HTTPS correctly.
5. Save the results, assign any fixes, and set the next review date.

Pair these checks with a broader website maintenance calendar so certificate management remains a routine operational task rather than an emergency response.