{"id":2191,"date":"2025-11-20T15:40:01","date_gmt":"2025-11-20T12:40:01","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/fixing-common-ssl-certificate-errors-mixed-content-not-secure-and-browser-warnings\/"},"modified":"2026-11-04T05:18:14","modified_gmt":"2026-11-04T02:18:14","slug":"ssl-certificate-errors-fixes","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/ssl-certificate-errors-fixes\/","title":{"rendered":"SSL Certificate Errors: Diagnosis and Fixes"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>An SSL certificate can be installed while browsers still show \u2018Not Secure\u2019 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.<\/p>\n<p>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 <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> servers running Apache or Nginx, and in front of CDNs and reverse proxies. We will focus on three big categories: mixed content, generic \u2018Not Secure\u2019 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.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Browsers_Show_Not_Secure_and_Other_SSL_Warnings\"><span class=\"toc_number toc_depth_1\">1.<\/span> Why Browsers Show \u2018Not Secure\u2019 and Other SSL Warnings<\/a><\/li><li><a href=\"#The_Hosting_Checklist_Before_Debugging_SSL\"><span class=\"toc_number toc_depth_1\">2.<\/span> The Hosting Checklist Before Debugging SSL<\/a><ul><li><a href=\"#1_Confirm_DNS_is_pointing_to_the_correct_server\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> 1. Confirm DNS is pointing to the correct server<\/a><\/li><li><a href=\"#2_Make_sure_the_correct_hostname_is_covered\"><span class=\"toc_number toc_depth_2\">2.2.<\/span> 2. Make sure the correct hostname is covered<\/a><\/li><li><a href=\"#3_Confirm_the_full_certificate_chain_is_installed\"><span class=\"toc_number toc_depth_2\">2.3.<\/span> 3. Confirm the full certificate chain is installed<\/a><\/li><li><a href=\"#4_Check_client_time_and_server_SNI_configuration\"><span class=\"toc_number toc_depth_2\">2.4.<\/span> 4. Check client time and server SNI configuration<\/a><\/li><\/ul><\/li><li><a href=\"#Fixing_Not_Secure_When_You_Already_Have_an_SSL_Certificate\"><span class=\"toc_number toc_depth_1\">3.<\/span> Fixing \u2018Not Secure\u2019 When You Already Have an SSL Certificate<\/a><ul><li><a href=\"#Case_1_Site_loads_over_HTTP_by_default\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> Case 1: Site loads over HTTP by default<\/a><\/li><li><a href=\"#Case_2_Self-signed_or_untrusted_CA\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> Case 2: Self-signed or untrusted CA<\/a><\/li><li><a href=\"#Case_3_Expired_certificate\"><span class=\"toc_number toc_depth_2\">3.3.<\/span> Case 3: Expired certificate<\/a><\/li><li><a href=\"#Case_4_Certificate_name_mismatch_www_vs_non-www_vs_subdomains\"><span class=\"toc_number toc_depth_2\">3.4.<\/span> Case 4: Certificate name mismatch (www vs non-www vs subdomains)<\/a><\/li><\/ul><\/li><li><a href=\"#Mixed_Content_Finding_and_Fixing_HTTP_Resources\"><span class=\"toc_number toc_depth_1\">4.<\/span> Mixed Content: Finding and Fixing HTTP Resources<\/a><ul><li><a href=\"#How_browsers_detect_mixed_content\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> How browsers detect mixed content<\/a><\/li><li><a href=\"#Fixing_mixed_content_at_the_application_level\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Fixing mixed content at the application level<\/a><\/li><li><a href=\"#Mixed_content_and_WordPress_on_shared_hosting_or_VPS\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> Mixed content and WordPress on shared hosting or VPS<\/a><\/li><li><a href=\"#CDNs_proxies_and_mixed_content\"><span class=\"toc_number toc_depth_2\">4.4.<\/span> CDNs, proxies and mixed content<\/a><\/li><\/ul><\/li><li><a href=\"#Browser_Warnings_About_TLS_Versions_Cipher_Suites_and_HSTS\"><span class=\"toc_number toc_depth_1\">5.<\/span> Browser Warnings About TLS Versions, Cipher Suites and HSTS<\/a><ul><li><a href=\"#Old_TLS_versions_disabled_by_browsers\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> Old TLS versions disabled by browsers<\/a><\/li><li><a href=\"#Weak_cipher_suites_and_key_exchange\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> Weak cipher suites and key exchange<\/a><\/li><li><a href=\"#HSTS_and_certificate_errors\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> HSTS and certificate errors<\/a><\/li><\/ul><\/li><li><a href=\"#Architecture_Gotchas_Reverse_Proxies_Multi-Domain_and_SaaS_Setups\"><span class=\"toc_number toc_depth_1\">6.<\/span> Architecture Gotchas: Reverse Proxies, Multi-Domain and SaaS Setups<\/a><ul><li><a href=\"#Terminating_SSL_at_a_reverse_proxy\"><span class=\"toc_number toc_depth_2\">6.1.<\/span> Terminating SSL at a reverse proxy<\/a><\/li><li><a href=\"#Multi-tenant_SaaS_with_custom_domains\"><span class=\"toc_number toc_depth_2\">6.2.<\/span> Multi-tenant SaaS with custom domains<\/a><\/li><li><a href=\"#CAA_DNSSEC_and_policy-related_failures\"><span class=\"toc_number toc_depth_2\">6.3.<\/span> CAA, DNSSEC and policy-related failures<\/a><\/li><\/ul><\/li><li><a href=\"#Maintaining_SSL_Reliability_in_a_Hosting_Environment\"><span class=\"toc_number toc_depth_1\">7.<\/span> Maintaining SSL Reliability in a Hosting Environment<\/a><\/li><li><a href=\"#A_Practical_SSL_Troubleshooting_Order\"><span class=\"toc_number toc_depth_1\">8.<\/span> A Practical SSL Troubleshooting Order<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Browsers_Show_Not_Secure_and_Other_SSL_Warnings\">Why Browsers Show \u2018Not Secure\u2019 and Other SSL Warnings<\/span><\/h2>\n<p>A modern browser does not just check whether you have any <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>; it checks several things at once:<\/p>\n<ul>\n<li>Is the connection encrypted with HTTPS, or is the page still loading over plain HTTP?<\/li>\n<li>Is the certificate valid for the exact hostname the user typed (including www vs non-www and subdomains)?<\/li>\n<li>Is the certificate issued by a trusted Certificate Authority (CA), and is the full chain (intermediates) correctly served?<\/li>\n<li>Is the certificate within its validity period (neither expired nor not yet valid), and does it pass the browser\u2019s applicable revocation checks?<\/li>\n<li>Is the TLS configuration modern enough (no obsolete protocols like TLS 1.0, no very weak ciphers)?<\/li>\n<li>Is the page fully secure, or does it mix HTTPS with insecure HTTP images, scripts or iframes?<\/li>\n<\/ul>\n<p>Different combinations of these problems create different messages: \u2018Not Secure\u2019, \u2018Your connection is not private\u2019, \u2018NET::ERR_CERT_AUTHORITY_INVALID\u2019, \u2018SSL_ERROR_BAD_CERT_DOMAIN\u2019, 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 <a href='https:\/\/www.dchost.com\/blog\/en\/what-is-an-ssl-certificate-ways-to-secure-your-website\/'>explain what an SSL certificate is and how it protects your website<\/a>. Here we will focus specifically on fixing errors, step by step, from the hosting side.<\/p>\n<h2><span id=\"The_Hosting_Checklist_Before_Debugging_SSL\">The Hosting Checklist Before Debugging SSL<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"1_Confirm_DNS_is_pointing_to_the_correct_server\">1. Confirm DNS is pointing to the correct server<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>What A \/ AAAA records your domain is using<\/li>\n<li>Whether these IPs belong to the intended hosting server, CDN or reverse proxy<\/li>\n<li>Whether DNS changes have fully propagated (TTL delays)<\/li>\n<\/ul>\n<p>You can quickly verify with tools like <code>dig<\/code> or <code>nslookup<\/code>, 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 <a href='https:\/\/www.dchost.com\/blog\/en\/common-dns-record-mistakes\/'>DNS records explained like a friend<\/a> is a good companion read.<\/p>\n<h3><span id=\"2_Make_sure_the_correct_hostname_is_covered\">2. Make sure the correct hostname is covered<\/span><\/h3>\n<p>Three possible hostname mismatches:<\/p>\n<ul>\n<li>Certificate issued for example.com, but visitors use www.example.com<\/li>\n<li>Certificate only covers the main domain, but you are accessing a subdomain like shop.example.com<\/li>\n<li>Trying to access the site directly via IP address instead of the domain<\/li>\n<\/ul>\n<p>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 \u2018SSL_ERROR_BAD_CERT_DOMAIN\u2019 or \u2018NET::ERR_CERT_COMMON_NAME_INVALID\u2019, this is usually the reason.<\/p>\n<h3><span id=\"3_Confirm_the_full_certificate_chain_is_installed\">3. Confirm the full certificate chain is installed<\/span><\/h3>\n<p>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.<\/p>\n<p>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 <code>fullchain.pem<\/code>. 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.<\/p>\n<h3><span id=\"4_Check_client_time_and_server_SNI_configuration\">4. Check client time and server SNI configuration<\/span><\/h3>\n<p>Two more subtle but important points:<\/p>\n<ul>\n<li><strong>System time:<\/strong> Browsers check certificate dates using the client device\u2019s 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.<\/li>\n<li><strong>SNI (Server Name Indication):<\/strong> 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.<\/li>\n<\/ul>\n<p>Once this checklist is clean, you can tackle specific error types with much less guesswork.<\/p>\n<h2><span id=\"Fixing_Not_Secure_When_You_Already_Have_an_SSL_Certificate\">Fixing \u2018Not Secure\u2019 When You Already Have an SSL Certificate<\/span><\/h2>\n<p>One of the most frustrating situations is installing an SSL certificate, verifying it looks valid, and still seeing \u2018Not Secure\u2019 in the address bar. There are a few common patterns here.<\/p>\n<h3><span id=\"Case_1_Site_loads_over_HTTP_by_default\">Case 1: Site loads over HTTP by default<\/span><\/h3>\n<p>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.<\/p>\n<p>The fix is to redirect all traffic from HTTP to HTTPS at the server or application level:<\/p>\n<ul>\n<li><strong>On Apache:<\/strong> Use the appropriate virtual-host redirect or a permitted .htaccess rule. A rule based on Apache\u2019s HTTPS variable assumes TLS reaches Apache directly; a reverse proxy needs a trusted scheme-detection configuration.<\/li>\n<li><strong>On Nginx:<\/strong> Configure the HTTP listener to return a 301 to the intended HTTPS hostname.<\/li>\n<li><strong>In applications such as WordPress:<\/strong> Set the relevant site and home URLs to HTTPS so generated links use the correct scheme. This complements the server redirect.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Case_2_Self-signed_or_untrusted_CA\">Case 2: Self-signed or untrusted CA<\/span><\/h3>\n<p>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 \u2018Your connection is not private\u2019. 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.<\/p>\n<p>ACME-based certificate management (for example, with Let\u2019s 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 <a href='https:\/\/www.dchost.com\/blog\/en\/acme-challenges-http-01-dns-01-tls-alpn-01\/'>ACME challenges deep dive<\/a> that covers them in detail.<\/p>\n<h3><span id=\"Case_3_Expired_certificate\">Case 3: Expired certificate<\/span><\/h3>\n<p>An expired certificate fails the browser\u2019s 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.<\/p>\n<p>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 <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, 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 <a href='https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-wildcard-ssl-certificates\/'>Let\u2019s Encrypt wildcard SSL automation on cPanel, Plesk and Nginx<\/a>.<\/p>\n<h3><span id=\"Case_4_Certificate_name_mismatch_www_vs_non-www_vs_subdomains\">Case 4: Certificate name mismatch (www vs non-www vs subdomains)<\/span><\/h3>\n<p>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.<\/p>\n<p>Possible fixes:<\/p>\n<ul>\n<li>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.<\/li>\n<li>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.<\/li>\n<li>Check that your virtual host or server block is using the right certificate for the right server_name.<\/li>\n<\/ul>\n<h2><span id=\"Mixed_Content_Finding_and_Fixing_HTTP_Resources\">Mixed Content: Finding and Fixing HTTP Resources<\/span><\/h2>\n<p>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 \u2018Not Secure\u2019 indicators despite having a valid certificate.<\/p>\n<h3><span id=\"How_browsers_detect_mixed_content\">How browsers detect mixed content<\/span><\/h3>\n<p>When you load an HTTPS page, the browser scans all resource URLs. If it sees something like:<\/p>\n<ul>\n<li><code>http:\/\/example.com\/style.css<\/code><\/li>\n<li><code>http:\/\/cdn.example.com\/script.js<\/code><\/li>\n<li><code>http:\/\/images.example.com\/logo.png<\/code><\/li>\n<\/ul>\n<p>it flags this as mixed content. You can see details in the browser\u2019s developer tools (Console or Security tab). There are two main types:<\/p>\n<ul>\n<li><strong>Upgradable content:<\/strong> 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.<\/li>\n<li><strong>Blockable content:<\/strong> scripts, stylesheets, iframes and other non-upgradable HTTP resources are blocked. The older \u2018active\u2019 and \u2018passive\u2019 labels do not fully describe current behavior.<\/li>\n<\/ul>\n<h3><span id=\"Fixing_mixed_content_at_the_application_level\">Fixing mixed content at the application level<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>Hard-coded http:\/\/ links in templates or themes<\/li>\n<li>Old content in the database (for example, WordPress posts that reference http:\/\/example.com\/uploads\/&#8230;)<\/li>\n<li>Configuration files with base URLs or CDN URLs set to http:\/\/<\/li>\n<\/ul>\n<p>Practical steps:<\/p>\n<ul>\n<li>Search your codebase for <code>http:\/\/<\/code> and inspect which matches are resources loaded by HTTPS pages. Where the target supports HTTPS, use <code>https:\/\/<\/code> or a suitable same-origin relative URL such as <code>\/images\/logo.png<\/code>. Do not blindly rewrite unrelated external links.<\/li>\n<li>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.<\/li>\n<li>For CDN or subdomain assets, confirm that the resource is available over HTTPS with a valid certificate before updating its URL.<\/li>\n<\/ul>\n<h3><span id=\"Mixed_content_and_WordPress_on_shared_hosting_or_VPS\">Mixed content and WordPress on shared hosting or VPS<\/span><\/h3>\n<p>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:<\/p>\n<ol>\n<li>Take a restorable backup of files and database before making changes.<\/li>\n<li>Check WordPress Address (URL) and Site Address (URL) in Settings \u2192 General, or their existing configuration overrides, and update the applicable values to HTTPS.<\/li>\n<li>Use a serialization-aware tool such as WP-CLI search-replace, first in dry-run mode. Scope replacements from <code>http:\/\/example.com<\/code> to <code>https:\/\/example.com<\/code> to the affected site\u2019s relevant tables and columns; exclude GUIDs and unrelated sites or external domains.<\/li>\n<li>Apply the reviewed replacement, clear application, server and CDN caches, then test key pages, media and browser-console messages.<\/li>\n<\/ol>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/http-security-headers-hsts-csp\/'>HTTP security headers such as HSTS and CSP<\/a> if you want to enforce HTTPS more aggressively.<\/p>\n<h3><span id=\"CDNs_proxies_and_mixed_content\">CDNs, proxies and mixed content<\/span><\/h3>\n<p>When a CDN or reverse proxy sits in front of your origin, there are more opportunities for mixed content:<\/p>\n<ul>\n<li>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.<\/li>\n<li>If you use a \u2018Flexible SSL\u2019 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.<\/li>\n<li>Old static URLs hard-coded with http:\/\/ may be cached and reused until you purge the CDN.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Browser_Warnings_About_TLS_Versions_Cipher_Suites_and_HSTS\">Browser Warnings About TLS Versions, Cipher Suites and HSTS<\/span><\/h2>\n<p>Once mixed content and basic \u2018Not Secure\u2019 issues are resolved, you may still see more advanced warnings in the browser\u2019s security tab or in online SSL scanners. These are about the quality of your TLS configuration rather than the mere presence of a certificate.<\/p>\n<h3><span id=\"Old_TLS_versions_disabled_by_browsers\">Old TLS versions disabled by browsers<\/span><\/h3>\n<p>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\u2019s wording varies, so confirm the negotiated protocol and server configuration rather than relying on one error-code name.<\/p>\n<p>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.<\/p>\n<p>If you manage your own VPS or dedicated server, consult the configuration guidance in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/nginx-apache-tls-hsts-ocsp-setup\/'>TLS 1.3, OCSP stapling and HSTS on Nginx and Apache<\/a>, which we wrote exactly for this purpose.<\/p>\n<h3><span id=\"Weak_cipher_suites_and_key_exchange\">Weak cipher suites and key exchange<\/span><\/h3>\n<p>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.<\/p>\n<p>In Nginx, <code>ssl_ciphers<\/code> configures the OpenSSL cipher list for TLS 1.2 and earlier, <code>ssl_prefer_server_ciphers<\/code> controls server preference, and <code>ssl_protocols<\/code> 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.<\/p>\n<h3><span id=\"HSTS_and_certificate_errors\">HSTS and certificate errors<\/span><\/h3>\n<p>HSTS tells supporting browsers to use HTTPS for a hostname for the policy\u2019s specified lifetime. It can help prevent HTTP use, but it also makes correct certificate deployment and renewal essential:<\/p>\n<ul>\n<li>While a browser\u2019s HSTS policy is active, certificate validation errors stop the connection; HSTS does not provide a way around an expired or incorrect certificate.<\/li>\n<li>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.<\/li>\n<\/ul>\n<p>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\u2019s stored policy. Treat preload enrollment as a separate commitment, not an initial troubleshooting step.<\/p>\n<p>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.<\/p>\n<h2><span id=\"Architecture_Gotchas_Reverse_Proxies_Multi-Domain_and_SaaS_Setups\">Architecture Gotchas: Reverse Proxies, Multi-Domain and SaaS Setups<\/span><\/h2>\n<p>Moving beyond a single site on a single shared hosting account introduces additional places where SSL can be misconfigured. Patterns to check include:<\/p>\n<h3><span id=\"Terminating_SSL_at_a_reverse_proxy\">Terminating SSL at a reverse proxy<\/span><\/h3>\n<p>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 <code>X-Forwarded-Proto<\/code> or the standardized <code>Forwarded<\/code> header.<\/p>\n<p>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:<\/p>\n<ul>\n<li>Configure your app or framework (for example, WordPress, Laravel) to accept forwarded protocol information only from explicitly trusted proxies.<\/li>\n<li>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.<\/li>\n<\/ul>\n<h3><span id=\"Multi-tenant_SaaS_with_custom_domains\">Multi-tenant SaaS with custom domains<\/span><\/h3>\n<p>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.<\/p>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/saas-custom-domains-dns-01-ssl\/'>bring-your-own-domain SaaS with automatic SSL via DNS-01<\/a>.<\/p>\n<h3><span id=\"CAA_DNSSEC_and_policy-related_failures\">CAA, DNSSEC and policy-related failures<\/span><\/h3>\n<p>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.<\/p>\n<p>For a CAA-related issuance failure, inspect the CA\u2019s exact error, the applicable <code>CAA<\/code> 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 <a href='https:\/\/www.dchost.com\/blog\/en\/caa-records-lets-encrypt-zerossl\/'>CAA records and multi-CA strategies<\/a> and <a href='https:\/\/www.dchost.com\/blog\/en\/dnssec-website-security-benefits-and-limits\/'>what DNSSEC is and how it secures your domain<\/a> explain the separate roles of these DNS mechanisms. Retest issuance after fixing the reported cause and monitor the next renewal.<\/p>\n<h2><span id=\"Maintaining_SSL_Reliability_in_a_Hosting_Environment\">Maintaining SSL Reliability in a Hosting Environment<\/span><\/h2>\n<p>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:<\/p>\n<ul>\n<li><strong>Automate supported steps:<\/strong> Schedule renewal, deploy the result to every relevant endpoint and retain failure logs and alerts.<\/li>\n<li><strong>Maintain TLS configuration:<\/strong> Use current documentation for the server and TLS library, then test protocol and cipher support against the clients you serve.<\/li>\n<li><strong>Verify the served chain:<\/strong> Check the certificate and intermediates clients actually receive, including the edge and origin separately.<\/li>\n<li><strong>Protect proxy connections:<\/strong> Use HTTPS with certificate validation between the proxy and origin where that connection needs transport protection.<\/li>\n<li><strong>Stage policy changes:<\/strong> Test HSTS scope, redirects and client compatibility before increasing policy duration or deploying broadly.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"A_Practical_SSL_Troubleshooting_Order\">A Practical SSL Troubleshooting Order<\/span><\/h2>\n<p>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.<\/p>\n<p>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\u2019s management scope and which belong to the application administrator. For further maintenance guidance, see <a href='https:\/\/www.dchost.com\/blog\/en\/ssl-tls-certificate-maintenance-renewal\/'>keeping up with SSL security updates<\/a> and <a href='https:\/\/www.dchost.com\/blog\/en\/nginx-apache-tls-hsts-ocsp-setup\/'>deploying modern TLS 1.3 configurations<\/a>.<\/p>\n<p>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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Find the cause of SSL certificate errors with checks for DNS, hostnames, certificate chains and renewal. Fix mixed content, review proxy connections and configure TLS and HSTS with clear deployment checks.<\/p>\n","protected":false},"author":1,"featured_media":8686,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[184],"tags":[],"class_list":["post-2191","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2191","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2191"}],"version-history":[{"count":8,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2191\/revisions"}],"predecessor-version":[{"id":8999,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2191\/revisions\/8999"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/8686"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2191"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2191"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2191"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}