SSL Certificate Renewal and Troubleshooting Checklist for Small Business Websites

Overview

An SSL certificate enables encrypted HTTPS connections between a visitor’s browser and your website. In practice, keeping HTTPS working involves more than replacing an expired certificate. The certificate must match the domain, be installed on the server that receives traffic, chain to a trusted certificate authority, and work with the site’s DNS, redirects, applications, and external resources.

This matters whether your site runs on managed cloud hosting, a website builder, WordPress cloud hosting, or a self-managed server. Hosting platforms often automate renewal, but automation can fail after a domain move, DNS change, firewall update, staging deployment, or hosting migration. A repeatable review helps you distinguish an expired certificate from a validation, configuration, or mixed-content problem.

Before changing anything, record the affected hostname, the exact browser or monitoring error, the time the problem began, and any recent infrastructure changes. Check both the main domain and important subdomains such as www, app, shop, or admin. A certificate can be valid for one hostname while another still has an error.

For related operational planning, see the cloud deployment checklist for small SaaS projects and developer websites and the website uptime monitoring guide.

Checklist by scenario

Before an SSL certificate renewal

• Identify every hostname that must use HTTPS, including the preferred version of the domain and any active subdomains.
• Find the certificate’s expiration date and the platform responsible for renewal. This may be a managed hosting panel, a website builder, a reverse proxy, a CDN, or a server you administer.
• Confirm that the domain registration is active and that the authoritative DNS zone is under your control.
• Check whether the certificate uses automatic renewal and whether the renewal account, API token, or deployment integration is still valid.
• Review recent changes to DNS records, hosting, load balancers, firewalls, redirects, and web-server configuration.
• Confirm that you have a recent website backup and a way to restore the site if a configuration change causes an outage. The small business website backup strategy provides a separate retention and recovery checklist.

Do not wait until the expiration date to investigate. Renewal systems need to complete domain validation and then install the new certificate on the service that handles HTTPS traffic. The exact lead time depends on the certificate authority and hosting platform, so follow the current instructions for your provider.

If the certificate has expired

1. Open the affected URL in a private browser window and note the exact warning. Test the root domain, the www hostname, and any important subdomains separately.
2. Check the certificate currently served to visitors. Confirm its expiration date, subject names, issuer, and whether the hostname appears in the certificate’s valid names.
3. Renew or reissue the certificate through the platform that terminates HTTPS. Installing a certificate in a different hosting account will not fix the service receiving live traffic.
4. Complete the requested domain validation. Depending on the workflow, validation may require a DNS record or a web-accessible validation file. Avoid removing validation records until the process is complete.
5. Install the renewed certificate and its required intermediate chain, then reload or redeploy the web service if the platform requires it.
6. Test from more than one network or monitoring location and confirm that HTTP redirects to HTTPS without a loop.

If the certificate does not match the domain

A name mismatch usually means the server is presenting the wrong certificate, the hostname is not included, or DNS points to an unexpected service. Compare the requested hostname with the certificate’s valid names. Check the DNS record, hosting account, CDN or proxy configuration, and the virtual-host or site mapping on the server. If both the root domain and www are intended to work, make sure the certificate covers both or that one reliably redirects to the other.

If renewal fails during domain validation

• For DNS validation, confirm that the required record exists at the authoritative DNS provider, not only in a different hosting panel. Watch for duplicate, stale, or incorrectly formatted records.
• For HTTP validation, confirm that the validation path is publicly reachable and is not blocked by authentication, a maintenance page, a redirect loop, a firewall, or an application rule.
• Check whether a CDN, load balancer, or proxy routes validation requests to the correct origin.
• Allow for DNS and configuration changes to become visible, then retry according to the provider’s instructions.

ACME-based automation can simplify renewal, but it still depends on working DNS, reachable validation endpoints, valid credentials, and a deployment step that places the new certificate where live traffic is served. Treat automation as something to monitor, not something to assume is working.

If HTTPS loads but the page shows warnings

Mixed content occurs when an HTTPS page requests images, scripts, stylesheets, fonts, frames, or other resources over HTTP. Use the browser’s developer tools and console to identify the insecure URLs. Update hard-coded links in the CMS, theme, templates, database, or application configuration. Check third-party widgets and asset URLs as well. Avoid changing links blindly if an external service does not support HTTPS; replace or remove that dependency instead.

Also test forms, checkout pages, embedded content, login areas, and API calls. A homepage may appear secure while a specific template or user journey still loads insecure resources.

If HTTPS redirects fail

Confirm there is one clear redirect path from HTTP to the canonical HTTPS URL. Multiple redirect rules at the application, web server, CDN, and hosting layers can create loops or excessive hops. Check whether the site is behind a proxy that terminates TLS; the application must correctly understand the original protocol or it may redirect an already secure request back to itself.

What to double-check

• DNS: Verify A, AAAA, CNAME, and relevant validation records. An outdated IPv6 record can send some visitors to a server with an old certificate even when the IPv4 address is correct.
• Certificate coverage: Confirm every required hostname is covered and that the certificate is installed on every active edge, origin, load balancer, or staging endpoint that receives traffic.
• Certificate chain: Ensure the server sends the required intermediate certificates. A certificate may look correct on the server but fail for some clients when the chain is incomplete.
• Server time: Incorrect system time can make a valid certificate appear not yet valid or expired. Check the host and any relevant gateway.
• Redirects: Test HTTP and HTTPS versions with and without www, and confirm the final URL is the intended canonical address.
• Application settings: Update the CMS site URL, cookie security settings, canonical tags, sitemap URLs, API endpoints, and webhook URLs when moving from HTTP to HTTPS.
• Monitoring: Add certificate-expiration checks and an HTTPS health check to your uptime process. Monitoring should test the real public hostname, not only an internal origin.

For a deeper reliability process, compare this review with the website uptime and performance monitoring guide. SSL failures are availability incidents when visitors cannot reach the site or complete a transaction.

Common mistakes

• Renewing the wrong certificate: Several certificates may exist across hosting, CDN, staging, and development environments. First identify which service answers the public DNS record.
• Checking only one hostname: The root domain, www, and subdomains can resolve to different services and present different certificates.
• Changing DNS without documenting it: Unrecorded DNS changes make later troubleshooting slower and can break validation or email services.
• Forgetting the intermediate chain: Uploading only the leaf certificate can produce trust errors on some clients.
• Testing only from a cached browser: Use a private window, another network, and an external monitoring check. Caches can hide both old errors and new failures.
• Ignoring application-generated URLs: Database content, plugins, scripts, and integrations can continue requesting HTTP resources after the server is configured for HTTPS.
• Making emergency changes without a rollback: Export the current configuration, keep a recent backup, and change one layer at a time so the cause remains visible.

When to revisit

Use this checklist before every planned certificate renewal and whenever the domain, DNS provider, hosting platform, CDN, reverse proxy, or web server changes. Revisit it after a WordPress migration, a website builder transfer, a cloud deployment, a new subdomain, or a major theme and plugin update.

Make the review part of seasonal maintenance and deployment planning. At minimum, keep an inventory of hostnames, certificate owners, renewal methods, DNS access, and escalation contacts. Set an expiration alert with enough time to investigate validation or installation failures, rather than relying only on a browser warning after the certificate has expired.

For the next review, follow this order: identify the public endpoint, inspect the served certificate, verify DNS and validation, renew or install through the correct platform, test redirects and page resources, then confirm monitoring and backups. Record the result and any changed settings. That small operational habit turns SSL certificate renewal from an emergency task into a predictable part of maintaining secure, reliable web hosting.