Why Is SSL Not Working on My Site? A Diagnostic Guide

SSL problems come in several distinct categories that require different fixes. Knowing which category applies to your situation before attempting fixes saves significant time. This guide starts with a diagnostic table that maps your specific symptom to the category of problem and the fix to pursue.

The most important first step is the SSL Labs test: go to ssllabs.com/ssltest, enter your domain, and run the test. SSL Labs checks your certificate, certificate chain, TLS configuration, and several other factors from an external perspective: exactly what your visitors experience. Most SSL problems are visible in the SSL Labs report. If you are comfortable running that test, the report will tell you what is wrong. If you prefer a symptom-based approach, use the diagnostic table below.

Symptom-to-Cause Diagnostic Table

Matching Browser Error Codes to Causes

When visitors see a full-page SSL error, the error code in the browser identifies the specific certificate problem. Different browsers show different error codes for the same underlying issue.

Certificate Expired: The Most Common Cause

An expired certificate is the single most common SSL problem. The certificate has a Not After date. When the current time passes that date, the certificate becomes invalid and browsers display full-page security errors.

The fix is straightforward: renew the certificate and deploy the new certificate to the server. The specific steps depend on how the certificate was obtained.

• Hosting provider AutoSSL (cPanel, Plesk): Log in to your hosting control panel and check the SSL/TLS section. AutoSSL should have attempted renewal but may have failed. Check the AutoSSL log for errors. Trigger a manual renewal if automatic renewal has not occurred. Common causes of AutoSSL failure: domain not resolving to the server anymore, port 80 blocked by firewall, domain validation method changed by Let’s Encrypt.
• Self-hosted Let’s Encrypt via Certbot: Check the Certbot renewal log. Run the renewal manually to test whether it succeeds now. Check port 80 accessibility (HTTP-01 challenge requires it). Check whether a redirect from HTTP to HTTPS is interfering with the validation challenge.
• Paid certificate from a CA: Log in to your CA account, renew the certificate, download the new certificate files, and replace the old certificate on your server. Restart the web server after updating.
• Cloud-hosted platform (Cloudflare, AWS ALB, Azure App Service): Check the platform’s certificate management section. Managed certificates on these platforms should renew automatically. If renewal failed, check for DNS or domain configuration changes that prevented renewal.

Let’s Encrypt discontinued sending certificate expiry notification emails in June 2025. If your automated renewal was failing silently and you relied on those emails as a safety net, the certificate may have expired without any warning. Set up external certificate monitoring (UptimeRobot, Freshping, or similar services with SSL expiry checks) to alert you before expiry regardless of whether automated renewal emails work.

Untrusted Issuer: The Missing Intermediate Certificate

The NET::ERR_CERT_AUTHORITY_INVALID error with a valid, non-expired certificate from a reputable CA usually means the certificate chain is incomplete: the intermediate CA certificate is missing from the server’s configuration.

A certificate chain has three levels: the root CA (pre-installed in browsers), the intermediate CA (must be sent by the server), and the leaf certificate (your site’s certificate). Browsers do not trust the leaf certificate directly; they trust the root. To validate your leaf certificate, the browser needs the intermediate to connect the chain from leaf to root.

When the intermediate is missing, browsers that implement AIA (Authority Information Access) fetching can sometimes retrieve it automatically. Chrome often succeeds at this fallback, which is why the site may work in Chrome while failing in Firefox, Safari, curl, and programmatic HTTP clients that do not implement AIA fetching.

The fix is to update the certificate bundle on your server to include both the leaf certificate and the intermediate certificate(s) concatenated together. The CA that issued your certificate provides the intermediate certificate file. For Nginx, this is the ssl_certificate directive pointing to a fullchain.pem file. For Apache, the SSLCertificateChainFile directive or a combined certificate file. After updating, restart the web server and verify with SSL Labs that Chain Issues shows None.

Hostname Mismatch: Certificate Does Not Cover Your Domain

The NET::ERR_CERT_COMMON_NAME_INVALID error means the hostname in the visitor’s browser does not match any entry in the certificate’s Subject Alternative Name list. This happens in several common situations.

The www vs non-www problem is the most frequent: a certificate for www.example.com does not cover example.com, and vice versa. If visitors access your site without www and the certificate only covers www.example.com, they see a hostname mismatch error. The solution is to ensure the certificate covers both variants. Let’s Encrypt and most hosting AutoSSL systems include both www and non-www by default if you include both in the domain list when setting up SSL.

The subdomain situation: a certificate for example.com does not cover shop.example.com. If you have added a subdomain after issuing the original certificate, you need either a wildcard certificate or a certificate that includes the subdomain as a SAN entry.

The HTTP-to-HTTPS redirect: if example.com redirects to www.example.com and the certificate only covers www.example.com, accessing http://example.com redirects to https://example.com before the www redirect fires, showing a mismatch for example.com. The redirect order matters: redirect HTTP to HTTPS before redirecting www to non-www (or vice versa), and ensure the certificate covers all intermediate destinations.

Mixed Content: Padlock Warning Without a Full Error

Mixed content is one of the most confusing SSL problems because the site appears to be on HTTPS but the padlock shows a warning rather than a clean secure indicator. The site has not failed; specific resources on the page are loading over HTTP instead of HTTPS.

Modern browsers handle mixed content in two ways. Passive mixed content (images, videos, audio) is loaded with a warning: the padlock shows a triangle or information indicator. Active mixed content (scripts, CSS, iframes) is blocked entirely: the resource does not load, which may break page functionality.

To identify the specific HTTP resources causing mixed content warnings, open the browser developer tools (F12 on Windows, Command+Option+I on Mac), go to the Console tab, and look for warnings starting with ‘Mixed Content.’ Each warning identifies the specific URL being loaded over HTTP.

• WordPress sites: The Really Simple SSL plugin detects and fixes most mixed content by rewriting HTTP URLs to HTTPS in the page output. It handles WordPress-generated URLs automatically but may not fix hardcoded URLs in themes or plugins.
• Custom sites: Update hardcoded http:// URLs in templates, content, and database records to https://. Check database-stored content for http:// links using a search-and-replace tool with care. Update embedded third-party content to use HTTPS URLs where the third-party service supports it.
• External resources with no HTTPS: If an external resource is only available over HTTP and cannot be served over HTTPS, remove it or find an HTTPS alternative. A resource that is HTTP-only will continue causing mixed content warnings regardless of other fixes.

Redirect Loops: The Site Keeps Redirecting

ERR_TOO_MANY_REDIRECTS means the browser followed a chain of redirects that led back to a page it had already visited, creating an infinite loop. SSL-related redirect loops most commonly occur in three scenarios.

Cloudflare Flexible SSL with WordPress

This is the most common cause of SSL redirect loops. When Cloudflare’s SSL/TLS mode is set to Flexible, Cloudflare connects to the origin server over HTTP while presenting HTTPS to visitors. WordPress, configured to redirect HTTP to HTTPS, sees an HTTP connection from Cloudflare and issues a redirect to HTTPS. Cloudflare sends another HTTP connection. WordPress redirects again. The loop runs until the browser gives up.

Fix: Change Cloudflare’s SSL/TLS mode from Flexible to Full or Full (Strict). This requires your origin server to have a valid SSL certificate. On shared hosting, this means your hosting AutoSSL must be active. With Full (Strict), Cloudflare verifies the origin certificate; with Full, it accepts any certificate including self-signed. Once Cloudflare connects to the origin over HTTPS, WordPress no longer sees HTTP and the redirect loop stops.

Duplicate redirect rules

If both the web server configuration (Nginx or Apache) and WordPress (via .htaccess or a plugin) have HTTP-to-HTTPS redirect rules, they can interfere with each other. Similarly, if multiple plugins each add redirect rules, conflicts arise. Check whether the redirect exists in more than one place and remove duplicates, leaving only one authoritative redirect rule.

Force SSL plugin combined with server-level redirect

Using a WordPress plugin that forces HTTPS alongside a server-level HTTP-to-HTTPS redirect can create loops if the two systems do not coordinate correctly. The simplest fix is to handle the redirect at the server level (Nginx or Apache, or Cloudflare) and disable any plugin-level redirect enforcement, keeping one redirect source.

To diagnose a redirect loop, use curl with the –max-redirs flag set to a small number and the –location flag to follow redirects, watching where each redirect goes. The pattern of the redirects usually reveals where the loop originates. Alternatively, use a browser developer tools Network tab and observe the chain of 301/302 responses to see which URL keeps appearing.

Coverage Gaps: Works on One Domain Variant But Not Another

A certificate that covers www.example.com but not example.com (or vice versa) causes SSL errors for visitors who access the uncovered variant. This is especially common when:

• A certificate was renewed but the renewal only covered one variant
• A custom domain was added to a hosting account after the original certificate was issued
• A subdomain was added after the wildcard’s scope was already defined

The diagnostic step is straightforward: run SSL Labs for both the www and non-www versions of your domain. The report for each shows which SAN entries are on the certificate and whether the hostname matches. If one variant is not covered, renew or reissue the certificate to include both.

On most shared hosting panels, the SSL/TLS section allows you to reissue the certificate with additional domain names. On Let’s Encrypt via Certbot, re-run the certbot command with both domain variants included using the -d flag for each. The new certificate replaces the old one covering both variants.

Works in Chrome but Not in Safari or iOS: Apple-Specific Requirements

If SSL works in Chrome and Firefox but fails specifically in Safari, iPhone, or iPad browsers, or in iOS apps connecting to your server, the issue is usually an Apple-specific certificate requirement that Chrome does not enforce.

Apple’s platforms have three requirements beyond standard browser validation:

• No SHA-1 in the certificate chain: Apple rejects any certificate chain that includes SHA-1 signed certificates, including intermediate CA certificates. This has been Apple’s policy since iOS 11 and macOS 10.13. Chrome is more tolerant. If your certificate chain includes a SHA-1 intermediate (visible in SSL Labs under the Certification Paths section), contact your CA for an updated chain that uses only SHA-256.
• Certificate Transparency compliance: Apple requires that certificates issued after October 15, 2018 include at least two Signed Certificate Timestamps (SCTs) from approved CT logs. This is automatically satisfied by all major public CAs. If using a certificate from an unusual or private CA, CT compliance may not be present.
• App Transport Security: iOS and macOS apps enforce minimum TLS version (1.2), forward secrecy cipher suites, and RSA key size (2048 bits minimum). A server configured with old TLS versions or weak ciphers fails Apple’s ATS requirements even if browsers accept it.

Run SSL Labs and check the Apple Platform section of the report. Any specific Apple requirement failures are listed there.

Just Installed SSL and Now the Site is Broken

Installing an SSL certificate is the first step, not the last. Several things need to be updated after a certificate is installed for the site to work correctly on HTTPS.

WordPress URL settings not updated

WordPress stores the site URL in its settings. If the site was previously on http and the WordPress Address (URL) and Site Address (URL) in Settings, General still show http, WordPress generates HTTP links throughout the site, causing mixed content warnings and potentially redirect conflicts. Update both fields to https and save.

HTTP to HTTPS redirect not configured

Visitors who navigate to http://yourdomain.com should be redirected to https://yourdomain.com automatically. This redirect does not happen just because a certificate is installed. It requires a redirect rule in the web server configuration, .htaccess file, or via a plugin. Without it, the HTTP version of your site continues to be accessible and visitors who type the URL without https may not get the secure version.

Hardcoded HTTP URLs in content

If your site content, themes, or plugins contain hardcoded http:// URLs pointing to your own domain, they will cause mixed content warnings after switching to HTTPS. Use a search-and-replace tool to find and update these in the database (with care and a backup first). For WordPress, the Search Replace DB tool or the WP-CLI search-replace command handles this. For other platforms, a database query replacing http://yourdomain.com with https://yourdomain.com in content fields addresses it.

Using SSL Labs as Your Primary Diagnostic Tool

The SSL Labs SSL Server Test at ssllabs.com/ssltest is the most comprehensive free SSL diagnostic tool available. It checks your certificate, the full certificate chain, TLS protocol versions, cipher suites, HSTS configuration, and platform-specific requirements including Apple’s. The report takes about a minute to generate and shows exactly what external clients (including your visitors) experience when connecting.

Key sections to review in the SSL Labs report:

• Certificate section: Shows the certificate’s expiry date, the hostnames it covers, the issuer, and whether it is trusted in major trust stores. Any coverage gaps are visible here.
• Certification Paths section: Shows the full certificate chain from your leaf certificate to the root. Chain Issues: None is the target. Chain Issues: Incomplete means the intermediate is missing.
• Protocol Details section: Shows whether HSTS is set, forward secrecy, and cipher suites.
• Apple Platform section: Shows any Apple-specific requirement failures that would cause Safari or iOS failures.

Running SSL Labs before and after making any certificate change confirms whether the change actually resolved the issue from an external perspective.

Frequently Asked Questions

How do I know if my SSL certificate is working?

The most reliable check is the SSL Labs test at ssllabs.com/ssltest. Enter your domain and run the test. An A or A+ grade means the certificate and TLS configuration are correct. In a browser, click the padlock icon in the address bar to see the certificate details including the expiry date and which hostnames it covers. For a quick external check without SSL Labs, you can also check your certificate using the browser developer tools (Security tab in Chrome).

Why does my site show ‘Not Secure’ even though I installed SSL?

‘Not Secure’ in Chrome (shown in the address bar for HTTP pages) means the page is loading over HTTP, not HTTPS. Installing an SSL certificate does not automatically redirect HTTP to HTTPS. You need to also configure a 301 redirect from HTTP to HTTPS in your web server configuration, .htaccess file, or hosting panel. After the redirect is in place, visitors going to http://yourdomain.com will be automatically sent to https://yourdomain.com. If the site uses a padlock with a warning triangle rather than a clean padlock, the site is on HTTPS but has mixed content (some resources loading over HTTP); that is a different issue described in the mixed content section above.

Why does SSL work on www but not without www?

The certificate does not cover both variants. A certificate for www.example.com does not automatically cover example.com, and vice versa. Check which names are listed in the certificate’s Subject Alternative Name entries using SSL Labs or the browser’s certificate details panel. If only one variant is covered, reissue the certificate to include both. When using Let’s Encrypt, include both variants when requesting the certificate. Most hosting AutoSSL systems include both by default, but this depends on the hosting configuration.

My SSL was working and suddenly stopped. What happened?

The most common cause is certificate expiry. Check the certificate’s Not After date in SSL Labs or by clicking the padlock in your browser. If it has expired, renew and redeploy. If the certificate has not expired, the second most common cause is a change in your server or CDN configuration: a hosting migration, a web server restart that lost an in-memory HTTPS redirect, a Cloudflare SSL mode change, or a load balancer certificate that was not updated when the origin certificate was renewed. The SSL Labs test identifies which of these is the case.