An SSL certificate installation often looks finished the moment the padlock appears in your own browser. Then a customer on an older phone sees a warning, a payment provider rejects a webhook, or the certificate quietly expires three months later. Most of these problems come from a handful of repeatable mistakes. This guide explains how to diagnose and fix each one, whether your site runs on a VPS, a control panel or behind a CDN.

Incomplete intermediate chain

A certificate authority signs your certificate with an intermediate certificate, which is itself signed by a trusted root. The server must send your certificate together with the intermediate. If it sends only your certificate, desktop browsers often work because they cache or fetch the missing piece, while mobile apps, API clients and older devices fail.

How to diagnose it

Use an online SSL checker or run openssl s_client -connect example.com:443 -showcerts and count the certificates returned. An incomplete certificate chain usually shows only one certificate, or reports that the issuer could not be verified.

How to fix it

  • On Nginx, point the certificate directive to the full chain file, not the single certificate.
  • On Apache, use the full chain file or set the chain file directive for older versions.
  • In a control panel, paste the CA bundle into the separate intermediate field.

Name mismatch

A name mismatch error means the hostname in the address bar is not listed on the certificate. Common causes are a certificate issued for example.com but not www.example.com, a new subdomain added after the certificate was issued, or a server that sends the default certificate because the virtual host for your domain is missing an SSL configuration.

Check the Subject Alternative Names on the certificate and compare them with every hostname you use. Reissue the certificate with all names included, and make sure each HTTPS virtual host has its own server name set, so the server can pick the right certificate using SNI.

Mixed content after moving to HTTPS

Mixed content happens when an HTTPS page loads images, scripts or stylesheets over plain HTTP. Browsers block insecure scripts outright and may show a broken padlock for images. The symptoms range from a missing padlock to broken menus and checkout pages.

  • Open the browser developer console; it lists every blocked or insecure resource.
  • Update the site URL settings in your CMS so new links are generated with HTTPS.
  • Search the database for hard-coded http:// links in content, theme settings and widgets, and replace them carefully after taking a backup.
  • Check third-party embeds, fonts and tracking scripts, which sometimes still reference HTTP addresses.

A Content-Security-Policy header with upgrade-insecure-requests can cover stragglers, but fix the sources rather than relying on it alone.

ACME auto-renewal failures

Free certificates from Let's Encrypt last 90 days and depend on ACME auto-renewal. When renewal fails, nobody notices until the site shows an expiry warning. Typical causes include:

  • Blocked HTTP challenge: a redirect rule, firewall or CDN prevents the validation server from reaching the challenge file under /.well-known/acme-challenge/.
  • DNS changes: the domain now points to a different server or CDN, so the challenge lands somewhere else.
  • Broken renewal job: the cron job or systemd timer was removed during a server upgrade, or the client runs but the web server is never reloaded.
  • Rate limits: repeated failed attempts during testing can temporarily block new issuance.

Run a dry-run renewal to see the exact error, confirm the challenge path is reachable over plain HTTP, and add a reload hook so the web server picks up the new certificate. For domains behind a CDN, a DNS challenge is often more reliable. Set up an expiry monitor so you get a warning weeks before a certificate lapses.

Redirect loops behind proxies and CDNs

A redirect loop often appears right after enabling HTTPS on a site behind a reverse proxy, load balancer or CDN. The CDN connects to your server over HTTP, the server redirects to HTTPS, the CDN forwards the request again over HTTP, and the cycle repeats.

Fixing the loop

  • Set the CDN to connect to the origin over HTTPS with a valid certificate on the server, instead of flexible mode.
  • If the proxy terminates TLS, have the application trust the X-Forwarded-Proto header so it knows the original request was already secure.
  • Keep redirects in one place. Having a redirect in the CDN, another in the web server and a third in the CMS invites loops.

A short post-installation checklist

  • Test with an external SSL checker, not just your browser.
  • Verify every hostname, including www and mail-related names you use.
  • Scan key pages for mixed content, especially checkout and contact forms.
  • Run a renewal dry-run and confirm monitoring is in place.
  • Check that HTTP redirects to HTTPS in a single hop.

If you would rather have this handled for you, our SSL certificate installation and configuration service covers certificates, chains, redirects and renewal setup for business websites in Long Beach and LA County.

SSL Errors FAQ

Why does my site work on desktop but show an SSL error on phones?

This is the classic sign of a missing intermediate certificate. Desktop browsers may fill in the gap, while mobile devices and apps do not. Install the full chain.

Do I need to reinstall the certificate after renewal?

Not if renewal is automated correctly. The client replaces the files and a reload hook tells the web server to use them. If the old certificate is still served after renewal, the reload step is missing.

Is flexible SSL on a CDN good enough?

It encrypts only the connection between the visitor and the CDN. Traffic to your server stays unencrypted and redirect loops are common, so use full encryption with a valid origin certificate.