SSL Certificate Errors: Diagnosis and Fixes

An SSL certificate can be installed while browsers still show ‘Not Secure’ or connection errors. Possible causes include HTTP pages, mixed content, a hostname mismatch, incomplete certificate chains or an outdated TLS configuration. Start with the exact failing URL and browser message, then check the certificate, application and network path in that order.

In this guide, we will walk through the most common SSL-related errors you see in Chrome, Firefox and Safari, and how to fix them at the hosting level: on cPanel/WHM, on VPS servers running Apache or Nginx, and in front of CDNs and reverse proxies. We will focus on three big categories: mixed content, generic ‘Not Secure’ labels, and more advanced browser warnings related to TLS, cipher suites and HSTS. The goal is HTTPS connections without certificate or mixed-content warnings; the address-bar icon varies by browser.

Why Browsers Show ‘Not Secure’ and Other SSL Warnings

A modern browser does not just check whether you have any SSL certificate; it checks several things at once:

• Is the connection encrypted with HTTPS, or is the page still loading over plain HTTP?
• Is the certificate valid for the exact hostname the user typed (including www vs non-www and subdomains)?
• Is the certificate issued by a trusted Certificate Authority (CA), and is the full chain (intermediates) correctly served?
• Is the certificate within its validity period (neither expired nor not yet valid), and does it pass the browser’s applicable revocation checks?
• Is the TLS configuration modern enough (no obsolete protocols like TLS 1.0, no very weak ciphers)?
• Is the page fully secure, or does it mix HTTPS with insecure HTTP images, scripts or iframes?

Different combinations of these problems create different messages: ‘Not Secure’, ‘Your connection is not private’, ‘NET::ERR_CERT_AUTHORITY_INVALID’, ‘SSL_ERROR_BAD_CERT_DOMAIN’, or mixed content warnings in the console. If you want a quick refresher on what certificates are and how they work, we have a separate article where we explain what an SSL certificate is and how it protects your website. Here we will focus specifically on fixing errors, step by step, from the hosting side.

The Hosting Checklist Before Debugging SSL

Before diving into specific error messages, it helps to run through a short checklist. Many SSL problems are not about the certificate itself but about DNS and hosting configuration around it.

1. Confirm DNS is pointing to the correct server

If your domain points to an unintended server, browsers may receive the wrong certificate. If a CDN or reverse proxy fronts the site, its browser-facing certificate matters too. Check:

• What A / AAAA records your domain is using
• Whether these IPs belong to the intended hosting server, CDN or reverse proxy
• Whether DNS changes have fully propagated (TTL delays)

You can quickly verify with tools like dig or nslookup, or any online DNS checker. If you are curious about how DNS records work together (A, AAAA, CNAME, MX, TXT and more), our article on DNS records explained like a friend is a good companion read.

2. Make sure the correct hostname is covered

Three possible hostname mismatches:

• Certificate issued for example.com, but visitors use www.example.com
• Certificate only covers the main domain, but you are accessing a subdomain like shop.example.com
• Trying to access the site directly via IP address instead of the domain

Browsers are strict: the hostname in the URL must match a Subject Alternative Name (SAN) in the certificate, either exactly or through a valid wildcard match. Do not rely on the Common Name (CN) alone. If you see errors like ‘SSL_ERROR_BAD_CERT_DOMAIN’ or ‘NET::ERR_CERT_COMMON_NAME_INVALID’, this is usually the reason.

3. Confirm the full certificate chain is installed

A valid server certificate often comes with one or more intermediate certificates that link your certificate to a root CA trusted by browsers. If those intermediates are missing, some devices will consider the certificate untrusted even if the main file looks fine.

Control-panel labels vary, but installation normally involves the server certificate, its matching private key and the intermediate chain. In Nginx, the certificate file contains the leaf certificate first, followed by intermediates; an ACME client may call it fullchain.pem. Apache 2.4.8 and later can also load intermediates from SSLCertificateFile, so the older SSLCertificateChainFile directive is obsolete. Use the instructions for your installed server or panel version and inspect the chain actually served.

4. Check client time and server SNI configuration

Two more subtle but important points:

• System time: Browsers check certificate dates using the client device’s clock. If that clock is far off, a valid certificate may appear not yet valid or already expired. A server acting as a TLS client to an upstream service likewise needs an accurate clock.
• SNI (Server Name Indication): On shared IPs, servers use SNI to decide which certificate to present. If virtual host configuration is wrong, the server may present the wrong certificate for a domain.

Once this checklist is clean, you can tackle specific error types with much less guesswork.

Fixing ‘Not Secure’ When You Already Have an SSL Certificate

One of the most frustrating situations is installing an SSL certificate, verifying it looks valid, and still seeing ‘Not Secure’ in the address bar. There are a few common patterns here.

Case 1: Site loads over HTTP by default

Browsers generally mark plain HTTP pages as insecure, though the indicator varies. If your site is available at both http://example.com and https://example.com, and you do not enforce HTTPS, many visitors will still land on HTTP and see the warning.

The fix is to redirect all traffic from HTTP to HTTPS at the server or application level:

• On Apache: Use the appropriate virtual-host redirect or a permitted .htaccess rule. A rule based on Apache’s HTTPS variable assumes TLS reaches Apache directly; a reverse proxy needs a trusted scheme-detection configuration.
• On Nginx: Configure the HTTP listener to return a 301 to the intended HTTPS hostname.
• In applications such as WordPress: Set the relevant site and home URLs to HTTPS so generated links use the correct scheme. This complements the server redirect.

Test the destination certificate before enabling the redirect, then check the resulting URL and redirect chain. An HTTP-to-HTTPS redirect fixes the HTTP entry point; certificate errors and mixed content need their own checks.

Case 2: Self-signed or untrusted CA

If you created a self-signed certificate for testing, or use a CA that browsers do not trust, visitors will get a full-page warning like ‘Your connection is not private’. For a public website, serve a certificate issued by a publicly trusted CA, either at the web server or at a TLS-terminating reverse proxy. A VPN alone does not make an untrusted website certificate trusted. Private services can instead use a private CA explicitly trusted by managed client devices.

ACME-based certificate management (for example, with Let’s Encrypt) can automate issuance and renewal of publicly trusted certificates. If you want to dive deeper into ACME methods (HTTP-01, DNS-01, TLS-ALPN-01) and automation strategies, we have an ACME challenges deep dive that covers them in detail.

Case 3: Expired certificate

An expired certificate fails the browser’s validity check. Check the actual expiry date and issuer policy rather than assuming a fixed certificate lifetime. Automated renewal reduces dependence on manual work, but it needs monitoring and a working deployment step.

On shared hosting, check whether AutoSSL or another renewal service is enabled for the domain and inspect its status and failure notices. On VPS or dedicated servers, an ACME client such as Certbot or acme.sh can use a scheduled task to renew before expiry. Confirm that successful renewals update the certificate used by the web server and trigger any required reload. Finally, inspect the certificate served to clients, including the CDN edge when applicable. For wildcard issuance through DNS-01, see our guide to Let’s Encrypt wildcard SSL automation on cPanel, Plesk and Nginx.

Case 4: Certificate name mismatch (www vs non-www vs subdomains)

If your certificate covers example.com only and the visitor uses www.example.com, the names do not match. A certificate can include both names, but you must check its SANs rather than assume this. Similarly, a certificate covering only app.example.com does not cover api.example.com.

Possible fixes:

• Issue a certificate that includes all the hostnames you actually use in its SANs. A wildcard such as *.example.com covers one subdomain level, not example.com itself or deeper names.
• Redirect traffic to a single canonical hostname (for example, www to non-www or vice versa), but ensure every HTTPS source hostname has a valid certificate: TLS validation happens before the browser receives the redirect.
• Check that your virtual host or server block is using the right certificate for the right server_name.

Mixed Content: Finding and Fixing HTTP Resources

Mixed content happens when the main page is loaded over HTTPS, but some resources on that page (images, CSS, JavaScript, fonts, iframes) are loaded via HTTP. Modern browsers often upgrade or block some of these requests, but the result for users can be broken layouts, missing images or ‘Not Secure’ indicators despite having a valid certificate.

How browsers detect mixed content

When you load an HTTPS page, the browser scans all resource URLs. If it sees something like:

• http://example.com/style.css
• http://cdn.example.com/script.js
• http://images.example.com/logo.png

it flags this as mixed content. You can see details in the browser’s developer tools (Console or Security tab). There are two main types:

• Upgradable content: eligible image, audio and video requests are upgraded from HTTP to HTTPS. There are exceptions, including IP-address hosts and some image request forms; verify the actual browser result.
• Blockable content: scripts, stylesheets, iframes and other non-upgradable HTTP resources are blocked. The older ‘active’ and ‘passive’ labels do not fully describe current behavior.

Fixing mixed content at the application level

The core fix is simple: resources loaded by an HTTPS page should use HTTPS, either explicitly or through relative URLs. In practice, the work is usually in these places:

• Hard-coded http:// links in templates or themes
• Old content in the database (for example, WordPress posts that reference http://example.com/uploads/…)
• Configuration files with base URLs or CDN URLs set to http://

Practical steps:

• Search your codebase for http:// and inspect which matches are resources loaded by HTTPS pages. Where the target supports HTTPS, use https:// or a suitable same-origin relative URL such as /images/logo.png. Do not blindly rewrite unrelated external links.
• For WordPress, back up the database and files, check the site and home URL settings, and preview a serialization-aware replacement limited to the relevant old site or resource URLs.
• For CDN or subdomain assets, confirm that the resource is available over HTTPS with a valid certificate before updating its URL.

Mixed content and WordPress on shared hosting or VPS

A WordPress site can have SSL correctly installed at the hosting level while its database still contains HTTP resource URLs. A typical cleanup procedure is:

1. Take a restorable backup of files and database before making changes.
2. Check WordPress Address (URL) and Site Address (URL) in Settings → General, or their existing configuration overrides, and update the applicable values to HTTPS.
3. Use a serialization-aware tool such as WP-CLI search-replace, first in dry-run mode. Scope replacements from http://example.com to https://example.com to the affected site’s relevant tables and columns; exclude GUIDs and unrelated sites or external domains.
4. Apply the reviewed replacement, clear application, server and CDN caches, then test key pages, media and browser-console messages.

From the hosting side, redirect HTTP to HTTPS as well. Redirects do not rewrite stored resource URLs; the application must generate HTTPS URLs. For stricter setups, you can combine this with HTTP security headers like HSTS and CSP. We have a dedicated article on HTTP security headers such as HSTS and CSP if you want to enforce HTTPS more aggressively.

CDNs, proxies and mixed content

When a CDN or reverse proxy sits in front of your origin, there are more opportunities for mixed content:

• An HTTP origin connection is separate from the browser-facing connection: it does not by itself mean the CDN serves assets to the browser over HTTP.
• If you use a ‘Flexible SSL’ style mode (encrypted between user and CDN but plain HTTP from CDN to origin), the browser might show HTTPS, but requests between CDN and origin are not encrypted.
• Old static URLs hard-coded with http:// may be cached and reused until you purge the CDN.

Where a CDN or reverse proxy connects across a network, configure HTTPS to the origin and enable certificate validation for the intended origin name. Check this connection separately from the browser-to-CDN certificate. After correcting stored resource URLs, purge affected caches and confirm that the browser receives HTTPS asset URLs.

Browser Warnings About TLS Versions, Cipher Suites and HSTS

Once mixed content and basic ‘Not Secure’ issues are resolved, you may still see more advanced warnings in the browser’s security tab or in online SSL scanners. These are about the quality of your TLS configuration rather than the mere presence of a certificate.

Old TLS versions disabled by browsers

TLS 1.0 and 1.1 are deprecated. A server that only supports these versions cannot connect to clients that require TLS 1.2 or later. The browser’s wording varies, so confirm the negotiated protocol and server configuration rather than relying on one error-code name.

Use maintained server and TLS-library versions, enable TLS 1.2 and TLS 1.3 where supported, and disable TLS 1.0 and 1.1. Check the actual client compatibility requirements and test the configuration before applying it; a separate legacy requirement needs its own migration plan.

If you manage your own VPS or dedicated server, consult the configuration guidance in our article on TLS 1.3, OCSP stapling and HSTS on Nginx and Apache, which we wrote exactly for this purpose.

Weak cipher suites and key exchange

TLS 1.2 configuration can still permit outdated cipher suites. RFC 9325 prohibits negotiating RC4 and recommends avoiding algorithms with less than 128 bits of effective security; 3DES has an effective strength of 112 bits. TLS 1.3 uses a separate set of AEAD cipher suites and does not offer RC4 or 3DES. Assess each enabled protocol separately.

In Nginx, ssl_ciphers configures the OpenSSL cipher list for TLS 1.2 and earlier, ssl_prefer_server_ciphers controls server preference, and ssl_protocols selects protocol versions. These are Nginx directive names, not Apache directives. For TLS 1.2, RFC 9325 recommends ECDHE suites with AES-GCM. TLS 1.3 cipher suites separate record protection from key exchange: RFC 8446 requires AES-128-GCM support and recommends AES-256-GCM and ChaCha20-Poly1305 support unless an application profile specifies otherwise. Nginx exposes OpenSSL configuration through ssl_conf_command, available since 1.19.4, including its Ciphersuites command; TLS 1.3 also requires OpenSSL 1.1.1 or later. Follow the documentation for the installed Nginx/OpenSSL or Apache version, validate the syntax and test negotiated protocols and suites before reloading.

HSTS and certificate errors

HSTS tells supporting browsers to use HTTPS for a hostname for the policy’s specified lifetime. It can help prevent HTTP use, but it also makes correct certificate deployment and renewal essential:

• While a browser’s HSTS policy is active, certificate validation errors stop the connection; HSTS does not provide a way around an expired or incorrect certificate.
• The optional includeSubDomains directive extends the policy to subdomains. Any covered name used for a website needs working HTTPS, including names managed by another team.

Start with a short max-age after HTTPS works, then increase it once redirects and renewal deployment have been checked. Add subdomain coverage only after auditing those names. A received policy lasts for its max-age and is refreshed by later valid headers; simply removing the header does not immediately erase a browser’s stored policy. Treat preload enrollment as a separate commitment, not an initial troubleshooting step.

If the reported error specifically mentions certificate pinning, retain the exact message and check the documentation for the affected client or application. Do not assume it is an HSTS error or disable certificate validation as a workaround.

Architecture Gotchas: Reverse Proxies, Multi-Domain and SaaS Setups

Moving beyond a single site on a single shared hosting account introduces additional places where SSL can be misconfigured. Patterns to check include:

Terminating SSL at a reverse proxy

In many setups, a reverse proxy (Nginx, HAProxy or a CDN) terminates HTTPS, and the origin server sees only HTTP traffic. That backend connection is unencrypted; use HTTPS when it needs transport protection. You must also make the application and origin server aware of the browser-facing protocol, usually via headers like X-Forwarded-Proto or the standardized Forwarded header.

If your app does not trust these headers or is not configured to use them, it may think the site is on HTTP and generate http:// URLs, leading to mixed content or dangerous redirects. The fix is typically:

• Configure your app or framework (for example, WordPress, Laravel) to accept forwarded protocol information only from explicitly trusted proxies.
• Ensure the trusted proxy strips or overwrites client-supplied protocol headers with the actual browser-facing scheme. Do not trust such headers on direct client connections.

Multi-tenant SaaS with custom domains

When you build a SaaS where customers connect their own domains, SSL becomes more complex. You may need to issue certificates dynamically for each mapped domain and renew them automatically.

Centralize domain validation, issuance, deployment and renewal monitoring. DNS-01 and SAN certificates can help, but authorization is required for every customer domain. A wildcard such as *.example.com covers one label under example.com; it does not cover arbitrary mapped customer domains, the apex example.com or deeper names. See the architecture considerations in our guide to bring-your-own-domain SaaS with automatic SSL via DNS-01.

CAA, DNSSEC and policy-related failures

Sometimes a CA refuses to issue a certificate with errors referencing CAA or DNS problems. CAA DNS records let you restrict which certificate authorities may issue certificates for your domain. Misconfigured CAA can block issuance entirely. DNSSEC misconfigurations can also indirectly break ACME challenges.

For a CAA-related issuance failure, inspect the CA’s exact error, the applicable CAA records and whether they authorize the intended issuer. For DNSSEC-related lookup failures, verify the DNSSEC configuration before retrying; do not remove DNS protections as a generic workaround. Our guides to CAA records and multi-CA strategies and what DNSSEC is and how it secures your domain explain the separate roles of these DNS mechanisms. Retest issuance after fixing the reported cause and monitor the next renewal.

Maintaining SSL Reliability in a Hosting Environment

The same maintenance tasks apply whether a website uses shared hosting, a VPS, a dedicated server or colocated infrastructure. Assign ownership for certificate renewal and deployment, then use a repeatable checklist:

• Automate supported steps: Schedule renewal, deploy the result to every relevant endpoint and retain failure logs and alerts.
• Maintain TLS configuration: Use current documentation for the server and TLS library, then test protocol and cipher support against the clients you serve.
• Verify the served chain: Check the certificate and intermediates clients actually receive, including the edge and origin separately.
• Protect proxy connections: Use HTTPS with certificate validation between the proxy and origin where that connection needs transport protection.
• Stage policy changes: Test HSTS scope, redirects and client compatibility before increasing policy duration or deploying broadly.

Repeat these checks after migrations, DNS changes, proxy changes and renewals. A successful issuance log alone does not prove that every public endpoint is serving the new certificate.

A Practical SSL Troubleshooting Order

Begin with the failing hostname, DNS destination, certificate validity and served chain. Once HTTPS works, test redirects, correct mixed content in the application and review TLS protocol support. Keep the browser-to-proxy and proxy-to-origin connections separate in your diagnosis, and retest the original failing page after each targeted change.

For a DCHost-hosted service, include the affected hostname, exact error and recent changes when opening a support request. Check which tasks fall within the service’s management scope and which belong to the application administrator. For further maintenance guidance, see keeping up with SSL security updates and deploying modern TLS 1.3 configurations.

Record who manages DNS, the certificate, the proxy and the application. Clear responsibilities and a tested renewal path make later faults easier to locate, whether those components are hosted together or managed separately.