Certificate Valid, But Website Shown as Not Secure on Some Browsers: What to Do

A valid SSL certificate appearing as "Not Secure" usually stems from mixed content, incorrect domain binding, or outdated browser caches rather than a faulty certificate itself. This discrepancy occurs when the browser detects insecure resources on an otherwise secure page, or when the certificate’s Common Name does not match the requested hostname. Resolving this requires verifying the URL structure, checking for HTTP resources embedded in HTTPS pages, and ensuring the certificate chain is complete.

Understanding Mixed Content Errors

The most common reason a browser flags a site with a valid certificate as insecure is the presence of mixed content. Modern browsers enforce strict security policies where if any resource on an HTTPS page—such as images, scripts, stylesheets, or iframes—is loaded over an unencrypted HTTP connection, the entire page may be marked as partially secure or insecure. This is a protective measure to prevent man-in-the-middle attacks that could exploit the weak link in the chain. To diagnose this, open your browser's developer tools by pressing F12 or right-clicking and selecting Inspect. Navigate to the Console tab. If you see warnings like "Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure script 'http://...'", this confirms the issue. The browser blocks these resources or marks the padlock icon as broken because it cannot guarantee the integrity of the data being transferred. The solution involves updating all internal links and resource references within your website's codebase to use HTTPS. If you are using a Content Management System (CMS) like WordPress, plugins such as "Really Simple SSL" can automatically rewrite URLs. For custom applications, ensure that relative paths are used where possible, or explicitly define the protocol as https. Additionally, check third-party widgets or analytics scripts that might still be pointing to legacy HTTP endpoints.

Verifying Domain and Hostname Mismatch

Even if the certificate is technically valid, it will trigger security warnings if the domain name in the URL does not exactly match the Subject Alternative Names (SANs) or Common Name (CN) listed in the certificate. A certificate issued for www.example.com will not be trusted if a user visits example.com without the www prefix, unless both are included in the SAN list. Similarly, wildcard certificates like *.example.com do not cover sub-subdomains like mail.sub.example.com. Browsers display detailed error codes such as NET::ERR_CERT_COMMON_NAME_INVALID or SSL_ERROR_BAD_CERT_DOMAIN to indicate this mismatch. To resolve this, log into your Certificate Authority (CA) dashboard and verify the domains covered by your current certificate. You must either purchase a new certificate that includes all necessary variants of your domain or configure your web server to redirect all traffic to the primary domain specified in the certificate. For example, if your certificate only covers www.yoursite.com, you should configure your Nginx or Apache server to permanently redirect http://yoursite.com and https://yoursite.com to https://www.yoursite.com. This ensures users always access the version of the site protected by the valid certificate. See our guide on Client Fails TLS Handshake: Troubleshooting Guide for deeper insights into connectivity issues that may compound this problem.

Checking Certificate Chain Completeness

A certificate is only as strong as its chain of trust. If the intermediate certificates are missing from your server configuration, some browsers may fail to validate the root certificate against their local store, resulting in a "Not Secure" warning despite the leaf certificate being valid. This is particularly common on Linux servers running Nginx or Apache if the fullchain.pem file is not correctly linked. You can test your certificate chain using online tools like SSL Labs' Server Test or the command line tool openssl s_client. When using openssl, run: openssl s_client -connect yourdomain.com:443 -showcerts. Look for errors indicating "unable to get local issuer certificate." If this appears, your server is not sending the necessary intermediate certificates to the client. To fix this, concatenate your server certificate with the intermediate CA certificate into a single file, often referred to as the full chain. In Nginx, this is done by setting ssl_certificate to point to the combined file. In Apache, you use SSLEngine on and SSLCertificateFile for the cert, and SSLCertificateChainFile for the intermediates. Restart your web service after making these changes to apply the new configuration.

Clearing Browser Cache and DNS

Sometimes, the issue lies not with the server but with the client-side storage. Browsers aggressively cache SSL states and HSTS (HTTP Strict Transport Security) policies. If you recently renewed your certificate or changed your domain configuration, the browser might still be holding onto old security data, causing it to reject the new or corrected certificate. Clearing your browser cache and cookies can resolve stale security state issues. However, for HSTS-related problems, you need to visit chrome://net-internals/#hsts (in Chrome) or about:preferences#privacy (in Firefox) and delete the domain from the HSTS/PKCS11 module list. This forces the browser to re-evaluate the certificate from scratch on the next visit. Additionally, DNS propagation delays can cause different users to see different results. If you recently updated your DNS records, some users might still be resolving to an old IP address that hosts an expired or misconfigured certificate. Use tools like dig or nslookup to verify that your domain resolves to the correct IP address globally. If you are using a CDN like CloudFront, ensure that the distribution settings are correctly pulling from your origin and not caching invalid responses. Refer to CloudFront Keeps GET'ting Pages from My Website if you suspect CDN caching issues are contributing to inconsistent security statuses.

Frequently Asked Questions

Why does my site show as secure on desktop but not on mobile?

This often happens because mobile browsers have stricter mixed content blocking policies or different certificate stores. Check if your mobile site loads resources via HTTP, or if the mobile version uses a different domain not covered by your certificate. Ensure your responsive design serves all assets over HTTPS regardless of the device.

Can I ignore the "Not Secure" warning if the certificate is valid?

No, ignoring the warning compromises user trust and SEO rankings. Browsers penalize sites that are not fully secure by lowering their search visibility and displaying prominent interstitial warnings to users. Always resolve mixed content or chain issues to maintain a professional and safe online presence.

What causes ERR_CERT_DATE_INVALID if my certificate is active?

This error usually indicates a system clock mismatch on the client device. If the user's computer time is significantly out of sync with the actual time, they may perceive the certificate as expired or not yet valid. Advise users to synchronize their device clocks with an internet time server.

How do I check if my intermediate certificates are installed correctly?

Use the OpenSSL command line tool to connect to your server and inspect the certificate chain. Look for any gaps in the chain where the issuer certificate is missing. Online tools like Qualys SSL Labs provide a detailed breakdown of your chain completeness and identify any missing intermediates.

Does renewing a certificate clear HSTS settings in browsers?

No, HSTS settings persist independently of certificate validity. If a site previously set a high max-age for HSTS, browsers will refuse to connect via HTTP even after renewal until the HSTS policy expires or is manually cleared. You must wait for the HSTS duration to lapse or instruct users to clear their HSTS state for the domain.