SSL certificate renewal is usually routine, but a missed renewal or incorrect HTTPS configuration can make a working website appear unavailable. This guide provides a reusable checklist for renewing certificates, diagnosing common HTTPS errors, validating changes safely, and restoring service if a production deployment goes wrong.
Overview
An SSL certificate enables encrypted HTTPS connections between a visitor’s browser and your website. In practice, HTTPS depends on more than the certificate itself: the certificate must be valid for the requested hostname, the web server must present the correct certificate and intermediate certificates, DNS must point visitors to the intended server, and the application must load its resources securely.
Before starting an SSL certificate renewal, identify four details:
- Which hostnames are covered: for example, the root domain, a
wwwhostname, or additional subdomains. - Where the certificate is managed: a hosting control panel, a certificate management service, a cloud load balancer, a reverse proxy, or the server itself.
- How renewal is validated: commonly through DNS or HTTP validation, depending on the certificate workflow.
- Where HTTPS terminates: the origin server may not be the same system that visitors connect to if a proxy, CDN, or load balancer is in use.
Keep a recent backup of the web server configuration, certificate files, private key references, and application settings. Never publish or paste a private key into a ticket, chat, repository, or diagnostic tool. If your domain or hosting arrangement is changing at the same time, review the DNS configuration first; the DNS records guide can help map the relevant records.
Checklist by scenario
Scenario 1: Routine certificate renewal
- Record the current certificate’s expiration date, covered hostnames, issuer, and installation location.
- Confirm that the account or automation responsible for renewal can still access the domain, DNS zone, server, or hosting panel.
- Run the renewal in a staging or test environment when your platform supports it. A dry run can reveal permission, validation, or port problems without replacing the live certificate.
- Install the renewed certificate and the matching private key through the same system that terminates HTTPS.
- Reload or restart the web server only after checking its configuration. A graceful reload is generally preferable when supported, because it can reduce connection disruption.
- Test every important hostname over HTTPS, including redirects from HTTP and the
wwwor non-wwwversion used by your site. - Confirm that automated renewal is scheduled and that its logs or notifications are visible to the responsible team.
For command-line systems, a certificate tool may provide commands similar to a renewal dry run and a renewal operation. The exact command depends on the certificate client, operating system, web server, and hosting provider, so use the documentation for your environment rather than copying an unrelated command into production.
Scenario 2: The browser says the certificate is expired
Check the server visitors actually reach, not only the machine where you expected the certificate to be installed. DNS may direct different hostnames, networks, or services to different endpoints. Inspect the certificate presented by the affected hostname and compare its expiration date with the certificate installed in your hosting panel or server.
If the new certificate exists but browsers still receive the old one, look for a load balancer, reverse proxy, CDN, secondary web server, or container that also needs the certificate. Confirm that the renewal job completed successfully rather than assuming that a scheduled task ran correctly.
Scenario 3: Certificate-name mismatch
A name mismatch occurs when the requested hostname is not included in the certificate’s names. Check the exact address in the browser, including subdomains. A certificate for example.com does not automatically prove that every subdomain is covered. Request or install a certificate that explicitly covers the required names, then verify that the server selects it for the correct virtual host.
Scenario 4: Incomplete certificate chain
Some browsers or devices may reject a server that sends only its leaf certificate and omits the required intermediate certificates. Install the certificate bundle or full chain supplied by the certificate workflow, not just the individual site certificate. Then test from more than one browser or validation tool. Avoid guessing at chain files: use the files and instructions associated with the certificate being installed.
Scenario 5: Redirect loops or mixed content
For a redirect loop, trace every hop from HTTP to HTTPS and between hostname variants. Check web-server redirects, application settings, proxy settings, and forwarded-protocol headers. A common pattern is an application behind a proxy believing the original request was HTTP and redirecting repeatedly, even though the visitor connected over HTTPS.
Mixed-content warnings mean an HTTPS page is requesting an image, script, stylesheet, font, or other resource over HTTP. Search the page source, templates, database content, and third-party integrations for hard-coded HTTP URLs. Update them to HTTPS or use a relative or configuration-based URL where appropriate. Do not solve the warning by blindly disabling browser security controls.
Scenario 6: Renewal or migration caused an outage
Stop making additional live changes and preserve the error logs, timestamps, configuration diff, and certificate details. If the previous certificate and configuration are still valid, roll back to the last known-good version, reload the service, and test externally. If the issue is limited to one hostname, restore that virtual host rather than changing unrelated sites. After service is restored, investigate the failed validation or deployment in a non-production environment before retrying.
What to double-check
| Check | What to verify |
|---|---|
| Hostname coverage | The certificate includes every public hostname that must use HTTPS. |
| DNS | A and AAAA records, aliases, and validation records point to the intended service. |
| Private key | The private key matches the renewed certificate and remains protected. |
| Certificate chain | The server sends the required intermediate certificates. |
| Server selection | The correct virtual host and certificate are served for each hostname. |
| Application URLs | Canonical URLs, assets, APIs, webhooks, and embedded content use HTTPS consistently. |
| Automation | Renewal, installation, reload, and alerting steps are all working rather than only the first step. |
Test from outside the hosting network when possible. Internal DNS, cached responses, or a local proxy can hide a public configuration problem. Also check both IPv4 and IPv6 paths if the domain publishes both types of address.
Common mistakes
- Renewing the wrong certificate: several certificates may exist for different environments or hostnames. Start with the endpoint presenting the error.
- Updating only the origin: a proxy or load balancer may terminate HTTPS before traffic reaches the origin server.
- Forgetting alternate hostnames: test the root domain,
www, application subdomains, and any customer-facing endpoints. - Replacing files without reloading the service: many servers do not use new certificate files until they are reloaded or restarted.
- Changing DNS and certificates together without a plan: separate changes where possible so an outage has a clear cause.
- Ignoring renewal alerts: a successful certificate issue does not always mean the certificate was installed on every endpoint.
- Testing only one page: checkout, login, forms, APIs, webhooks, and administrative paths may use different hostnames or resources.
For broader operational checks, pair this guide with the website security and uptime monitoring checklist. If the certificate problem appeared during a hosting move, use the website migration guide and keep the old endpoint available until the new one has been verified.
When to revisit
Review this checklist before each planned renewal, before seasonal traffic or campaign periods, and whenever your hosting, DNS, proxy, CDN, or domain configuration changes. Revisit it after adding a subdomain, moving a website, changing certificate automation, rotating server credentials, or introducing a new load balancer.
Set a calendar reminder well before the certificate’s expiration date and assign an owner for the renewal process. Review the reminder whenever your team, hosting provider, certificate client, or deployment workflow changes. Tools and browser behavior can change, so confirm current commands and validation requirements in the documentation for the systems you use.
For the next renewal, use this short action list:
- Identify every HTTPS endpoint and its certificate manager.
- Back up the current configuration and confirm rollback access.
- Run a renewal test or staging deployment.
- Renew, install, reload, and verify the certificate externally.
- Test redirects, assets, forms, APIs, and alternate hostnames.
- Confirm monitoring and renewal alerts, then document the result.
A reliable SSL process is not just a once-a-year certificate replacement. It is a small operational routine that connects domain management, DNS, web hosting, deployment controls, monitoring, and support. Keeping those pieces documented makes HTTPS errors faster to diagnose and safer to resolve.
