SSL certificate errors usually come from an expired certificate, a hostname mismatch, an incomplete certificate chain, or incorrect server settings. Test the certificate from both the browser and server, identify which layer fails, then renew, reissue, or reconfigure it. SSL, or Secure Sockets Layer, is the familiar name for the technology that encrypts HTTPS connections; modern systems use TLS. Fixing the certificate alone may not solve redirects, mixed content, proxy settings, or cached errors.
Table of Contents
- What common SSL errors mean
- Test the certificate before changing the site
- Fix the certificate or chain
- Fix redirects, mixed content, and CMS settings
- Verify recovery and prevent another failure
What common SSL errors mean
An expired or not-yet-valid certificate usually points to a missed renewal, a failed automated renewal, or an incorrect system clock. Check the certificate's validity dates and the server's current time before replacing anything. A hostname mismatch means the requested domain is absent from the certificate's covered names. For example, a certificate for `example.com` may not cover `www.example.com`, `shop.example.com`, or a staging subdomain.
An untrusted-certificate warning often means the server is not sending the required intermediate certificates. It can also indicate a self-signed certificate, an unknown certificate authority, or HTTPS interception by security software. Protocol and cipher errors occur earlier in the TLS connection. They commonly involve incompatible TLS versions, proxy or load-balancer settings, an incorrect virtual host, or a certificate installed without its matching private key.
Test the certificate before changing the site
Start with the exact failing address, including its hostname. Test both `www` and non-`www` versions, important subdomains, and any hostname used by a content delivery network, checkout, form, or API. Use several checks because each reveals a different part of the problem: The `-servername` option matters because many servers host several HTTPS sites on one IP address.
Without it, a test may retrieve the default site's certificate and suggest a mismatch that ordinary visitors never receive. Compare results from the origin server and any CDN, reverse proxy, hosting gateway, or load balancer. A valid origin certificate does not prove that the public-facing service presents the correct certificate.
- Open the address in a private browser window and record the exact error.
- Inspect the certificate's names, issuer, validity dates, and chain in the browser.
- Run `curl -Iv https://example.com/` to view connection and redirect details.
- Run `openssl s_client -connect example.com:443 -servername example.com -showcerts` to inspect the certificate presented for that hostname.
- Test from another network or device to rule out local caching, filtering, or clock problems.
Fix the certificate or chain
Renew an expired certificate, or reissue it when the required hostname is missing. Include every public hostname that must work, but do not assume a wildcard certificate covers the base domain; `*.example.com` and `example.com` may need separate entries. Install the certificate on the system that terminates HTTPS. That may be the web server, but it could instead be a CDN, reverse proxy, managed hosting layer, or load balancer.
If clients report an incomplete chain, configure the server with the leaf certificate and the appropriate intermediate certificate bundle. Do not substitute the root certificate, and do not expose or copy the private key unless the receiving system requires it and can protect it. Confirm that the installed certificate matches the private key before restarting or reloading the service. Keep the previous working configuration available so you can restore service if the new chain or key is incorrect.
Fix redirects, mixed content, and CMS settings
A working certificate can still leave a site partly broken. Mixed content occurs when an HTTPS page requests scripts, stylesheets, fonts, images, frames, or API data over plain HTTP; browsers may block the active resources. Update the site's canonical URL and replace internal HTTP references carefully. In WordPress, review the WordPress Address and Site Address, hard-coded theme URLs, plugin settings, and serialized database values.
Use a tool that preserves serialized data when changing stored URLs. In Drupal, inspect trusted-host, reverse-proxy, base URL, module, theme, and cache settings appropriate to the installed version. For either CMS, clear application, browser, server, and CDN caches after correcting the configuration. Use one deliberate redirect path, such as HTTP to HTTPS and non-`www` to `www`. Redirect rules split across the application, web server, and CDN can create loops, especially when a proxy does not pass the original request scheme correctly.
Verify recovery and prevent another failure
Retest every important hostname after the change, not only the home page. Check login screens, forms, payment flows, asset domains, APIs, redirects, and integrations that call the site from another server. Certificate problems can interrupt crawling, analytics collection, advertising landing pages, conversion tracking, webhooks, and third-party integrations. After restoring HTTPS, verify the canonical URL, sitemap URLs, ad destinations, tracking requests, and external callbacks.
Automated renewal needs more than a scheduled command. The certificate authority must be able to complete its validation method, the renewed certificate must deploy to the correct endpoint, and the HTTPS service may need a reload. Add expiry monitoring from outside the hosting environment and alert more than one responsible person. Also monitor the public hostname, because checking only a certificate file on disk will not detect a failed deployment or a proxy serving an older certificate.
