Fixing Common SSL Certificate Errors: Mixed Content, ‘Not Secure’ and Browser Warnings

If you have ever finished an SSL installation, proudly typed your domain in the browser, and still seen a grey padlock or a big red ‘Not Secure’ label, you are not alone. From a hosting perspective, we see the same handful of SSL issues over and over again: mixed content, incorrect redirects, incomplete certificate chains, or browsers rejecting old TLS versions. The good news is that almost all of these problems follow predictable patterns. Once you understand where the browser is getting upset, you can fix the root cause instead of randomly changing settings and hoping the warning disappears.

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. Our goal at dchost.com is simple: a clean, solid padlock for every site you host with us, without drama and without guesswork.

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 still within its validity period (not expired, not yet valid, not revoked)?
• 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: a crossed-out padlock, ‘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 old IP or a different server than the one where you installed the certificate, browsers will still hit the old environment and complain. Check:

• What A / AAAA records your domain is using
• Whether these IPs match the hosting or VPS where you installed the certificate
• 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 common mistakes we see:

• 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 exist in the certificate’s Common Name (CN) or Subject Alternative Names (SANs). 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.

On cPanel and most control panels, there is a field for the certificate, one for the private key and one for the CA bundle (intermediate chain). On Nginx/Apache, make sure you use the ‘full chain’ file (sometimes called fullchain.pem) instead of just the leaf certificate.

4. Check server time and SNI

Two more subtle but important points:

• System time: If the server’s clock is far off, TLS handshakes may fail because the certificate appears not yet valid or already expired.
• 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 show ‘Not Secure’ for any plain HTTP page. 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 cPanel/Apache (.htaccess): Add a RewriteRule that forces HTTPS for your domain.
• On Nginx: Listen on port 80 and redirect to the https version (HTTP 301).
• In applications (like WordPress): Set the site URL and home URL to https, so generated links are already secure.

Once the redirect is in place and visitors are always on HTTPS, the basic ‘Not Secure’ label usually disappears, assuming the certificate itself is valid.

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’. The only real solution is to replace it with a certificate issued by a publicly trusted CA (or use a reverse proxy or VPN that terminates TLS for end users).

On our infrastructure, we typically automate this with ACME-based certificates (for example, Let’s Encrypt), so you get publicly trusted SSL by default, without manual renewal. 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

Browsers are ruthless about expiry dates. Even if it expired an hour ago, users will see a large error page. From a hosting perspective, the best answer is to never rely on manual renewals.

On shared hosting with AutoSSL, this is normally handled for you. On VPS or dedicated servers, use an ACME client (such as certbot or acme.sh) with a cron job or systemd timer to renew certificates well before expiry and reload your web server automatically. If you are managing many subdomains, wildcard SSL via DNS-01 can simplify this, as we explain in our guide on 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 is for example.com only and the visitor uses www.example.com, most modern certificates include both names, but not always. Similarly, if you have a certificate for app.example.com and you browse to api.example.com, browsers will complain.

Possible fixes:

• Issue a certificate that includes all the hostnames you actually use (SAN or wildcard).
• Redirect all traffic to a single canonical hostname (for example, always redirect www to non-www or vice versa).
• Check that your virtual host or server block is using the right certificate for the right server_name.

Mixed Content: The Silent SSL Killer

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:

• Passive mixed content: images, audio, video. Often allowed but still weakens security.
• Active mixed content: scripts, iframes, stylesheets. Usually blocked because they can compromise the page.

Fixing mixed content at the application level

The core fix is simple: all URLs on an HTTPS page should themselves start with HTTPS. 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 update internal links to https:// or to relative URLs (like /images/logo.png).
• If you use a CMS like WordPress, update the site URL and home URL to https, then use a search-and-replace tool to convert old content URLs from http to https in the database.
• If you serve static assets from a CDN or subdomain, make sure that hostname also has a valid SSL certificate and use HTTPS URLs.

Mixed content and WordPress on shared hosting or VPS

On WordPress sites hosted with us, we see a repeating pattern: SSL is correctly installed at the hosting level, but the database still contains thousands of http:// links. A typical cleanup procedure is:

1. In wp-admin, set Settings → General → WordPress Address (URL) and Site Address (URL) to https.
2. Take a full backup (files and database). Never skip this step.
3. Use a safe search-replace tool (for example, a WP-CLI command or a trusted plugin) to replace all instances of http://example.com with https://example.com in the database.
4. Clear any caches (plugin cache, server cache, CDN cache) and test again.

From the hosting side, we also ensure that HTTP is redirected to HTTPS, so new content is generated with the correct scheme. 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:

• The CDN might serve assets over HTTP if you configured an http:// origin URL.
• 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.

The rule of thumb from a hosting point of view: keep the entire path HTTPS, from browser to CDN to origin. Configure your CDN to connect to your origin with HTTPS, install a valid certificate on the origin (which we can provide on your hosting service), and purge caches after a big search-and-replace.

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

Modern browsers have deprecated TLS 1.0 and 1.1. If your server only supports these older protocols (for example, very old Apache/Nginx defaults), connections will fail with messages like ‘ERR_SSL_OBSOLETE_VERSION’ or similar.

The fix is to update your web server configuration to support TLS 1.2 and 1.3, and ideally disable 1.0 and 1.1 unless you have a specific legacy requirement.

We maintain hardened default configs on our servers and follow modern best practices. If you manage your own VPS or dedicated server, you can copy battle-tested configuration snippets from 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

Even with TLS 1.2+, a server can still offer old, weak cipher suites (for example, those using RC4 or 3DES). Some scanners will flag these as vulnerabilities, and certain corporate environments may block them.

On Apache and Nginx, you control this with directives like ssl_ciphers, ssl_prefer_server_ciphers and ssl_protocols. The modern recommendation is to stick to strong AES-GCM and ChaCha20-based suites and to enforce forward secrecy (ECDHE key exchange). Again, using a modern preset rather than inventing your own list is usually safest.

HSTS and certificate pinning issues

HSTS (HTTP Strict Transport Security) tells browsers to always use HTTPS for your domain and optionally to remember this rule for a long period. It is a great security feature, especially for login and payment pages, but misconfigurations can bite:

• If you enable HSTS with a very long max-age, and then let your certificate expire or misconfigure it, users will be locked out until you fix it.
• If you include subdomains in HSTS but forget to install SSL on all of them, those subdomains may become unreachable in modern browsers.

This is why we usually suggest starting with a short max-age and gradually increasing it once you are confident in your certificate automation and renewals. Our TLS 1.3 guide mentioned above includes a safe HSTS rollout pattern that we use in production at dchost.com.

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

As soon as you move beyond a single site on a single shared hosting account, SSL errors tend to come from architecture rather than simple misconfiguration. A few patterns we see often:

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. This is fine, but you must make the application and origin server aware of the real 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 trust the proxy and use the forwarded protocol.
• Ensure the proxy only sets these headers for traffic it terminates, to avoid spoofing.

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.

We strongly recommend centralizing this logic rather than managing individual certificates by hand. DNS-01 ACME challenges and wildcard or SAN certificates are powerful tools here. We documented how to do this at scale in our article on 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.

If you see errors about CAA, check your zone for CAA records and confirm they allow your chosen CA. We have a detailed article on CAA records and multi-CA strategies, and another one explaining what DNSSEC is and how it secures your domain. From a hosting point of view, aligning these DNS policies with your SSL automation process is crucial to avoid last-minute certificate failures.

How We Approach SSL Reliability at dchost.com

Because we operate hosting, VPS, dedicated and colocation environments, we see SSL problems long before they reach production. Over time, we have settled on a few principles that you can also adopt:

• Automate everything: Issuance, renewal and deployment of certificates should be automated with clear logs and monitoring, not spreadsheets and calendar reminders.
• Use battle-tested TLS configs: Start from modern, audited configuration templates instead of copying random snippets from old forum posts.
• Keep the chain complete: Always deploy full-chain certificates and verify with command-line tools or online scanners.
• Enforce HTTPS end-to-end: Do not stop at the CDN or reverse proxy; protect the full path between the user and your origin servers.
• Stage changes: Introduce HSTS, TLS 1.3, or new ciphers gradually, watching logs and error reports instead of toggling everything at once.

We treat SSL as a living part of your hosting stack, not a one-time setup task. That mindset is what keeps the padlock green month after month.

Wrapping Up: A Simple Action Plan for a Clean Padlock

SSL issues can feel intimidating when the browser throws big red warnings at you, but most problems follow straightforward patterns. From a hosting perspective, your first step is always to double-check DNS, hostname coverage and the full certificate chain. Once that base is solid, enforce HTTPS with redirects, clean up mixed content in your application, and modernize your TLS configuration so browsers are not forced into legacy, insecure protocols.

If you host your sites with dchost.com, we can help you review this entire path: from domain and DNS configuration, to SSL issuance and renewal automation, to web server tuning on shared hosting, VPS or dedicated servers. Combined with our existing guides on keeping up with SSL security updates and deploying modern TLS 1.3 configs, you have everything you need to keep your users’ browsers happy and your brand trusted.

If you are tired of chasing SSL errors across panels, plugins and servers, consider consolidating your domain, hosting, VPS or dedicated infrastructure with us and letting our team design a clean, automated SSL flow from day one. The padlock should be boring, predictable and invisible. We are here to make it exactly that for your projects.