{"id":2191,"date":"2025-11-20T15:41:26","date_gmt":"2025-11-20T12:41:26","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/fixing-common-ssl-certificate-errors-mixed-content-not-secure-and-browser-warnings\/"},"modified":"2025-11-20T15:41:26","modified_gmt":"2025-11-20T12:41:26","slug":"fixing-common-ssl-certificate-errors-mixed-content-not-secure-and-browser-warnings","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/fixing-common-ssl-certificate-errors-mixed-content-not-secure-and-browser-warnings\/","title":{"rendered":"Fixing Common SSL Certificate Errors: Mixed Content, \u2018Not Secure\u2019 and Browser Warnings"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>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 \u2018Not Secure\u2019 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.<\/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. Our goal at dchost.com is simple: a clean, solid padlock for every site you host with us, without drama and without guesswork.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/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_server_time_and_SNI\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 4. Check server time and SNI<\/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_The_Silent_SSL_Killer\"><span class=\"toc_number toc_depth_1\">4<\/span> Mixed Content: The Silent SSL Killer<\/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_pinning_issues\"><span class=\"toc_number toc_depth_2\">5.3<\/span> HSTS and certificate pinning issues<\/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=\"#How_We_Approach_SSL_Reliability_at_dchostcom\"><span class=\"toc_number toc_depth_1\">7<\/span> How We Approach SSL Reliability at dchost.com<\/a><\/li><li><a href=\"#Wrapping_Up_A_Simple_Action_Plan_for_a_Clean_Padlock\"><span class=\"toc_number toc_depth_1\">8<\/span> Wrapping Up: A Simple Action Plan for a Clean Padlock<\/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 still within its validity period (not expired, not yet valid, not revoked)?<\/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: a crossed-out padlock, \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\/ssl-sertifikasi-nedir-web-sitenizi-guvence-altina-almanin-yollari\/'>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 old IP or a different server than the one where you installed the certificate, browsers will still hit the old environment and complain. Check:<\/p>\n<ul>\n<li>What A \/ AAAA records your domain is using<\/li>\n<li>Whether these IPs match the hosting or VPS where you installed the certificate<\/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\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/'>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 common mistakes we see:<\/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 exist in the certificate\u2019s Common Name (CN) or Subject Alternative Names (SANs). 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>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 \u2018full chain\u2019 file (sometimes called <code>fullchain.pem<\/code>) instead of just the leaf certificate.<\/p>\n<h3><span id=\"4_Check_server_time_and_SNI\">4. Check server time and SNI<\/span><\/h3>\n<p>Two more subtle but important points:<\/p>\n<ul>\n<li><strong>System time:<\/strong> If the server\u2019s clock is far off, TLS handshakes may fail because the certificate appears not yet valid or already expired.<\/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 show \u2018Not Secure\u2019 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.<\/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 cPanel\/Apache (.htaccess):<\/strong> Add a RewriteRule that forces HTTPS for your domain.<\/li>\n<li><strong>On Nginx:<\/strong> Listen on port 80 and redirect to the https version (HTTP 301).<\/li>\n<li><strong>In applications (like WordPress):<\/strong> Set the site URL and home URL to https, so generated links are already secure.<\/li>\n<\/ul>\n<p>Once the redirect is in place and visitors are always on HTTPS, the basic \u2018Not Secure\u2019 label usually disappears, assuming the certificate itself is valid.<\/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. 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).<\/p>\n<p>On our infrastructure, we typically automate this with ACME-based certificates (for example, Let\u2019s 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 <a href='https:\/\/www.dchost.com\/blog\/en\/acme-challenge-turleri-derinlemesine-http%e2%80%9101-dns%e2%80%9101-ve-tls%e2%80%91alpn%e2%80%9101-ne-zaman-hangisi\/'>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>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.<\/p>\n<p>On shared hosting with AutoSSL, this is normally handled for you. On VPS or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, 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 <a href='https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-wildcard-ssl-otomasyonu-dns-01-ile-cpanel-plesk-ve-nginxte-zahmetsiz-kurulum-ve-yenileme-nasil-yapilir\/'>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 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.<\/p>\n<p>Possible fixes:<\/p>\n<ul>\n<li>Issue a certificate that includes all the hostnames you actually use (SAN or wildcard).<\/li>\n<li>Redirect all traffic to a single canonical hostname (for example, always redirect www to non-www or vice versa).<\/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_The_Silent_SSL_Killer\">Mixed Content: The Silent SSL Killer<\/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>Passive mixed content:<\/strong> images, audio, video. Often allowed but still weakens security.<\/li>\n<li><strong>Active mixed content:<\/strong> scripts, iframes, stylesheets. Usually blocked because they can compromise the page.<\/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: all URLs on an HTTPS page should themselves start with HTTPS. 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 update internal links to <code>https:\/\/<\/code> or to relative URLs (like <code>\/images\/logo.png<\/code>).<\/li>\n<li>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.<\/li>\n<li>If you serve static assets from a CDN or subdomain, make sure that hostname also has a valid SSL certificate and use HTTPS URLs.<\/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>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:<\/p>\n<ol>\n<li>In wp-admin, set Settings \u2192 General \u2192 WordPress Address (URL) and Site Address (URL) to https.<\/li>\n<li>Take a full backup (files and database). Never skip this step.<\/li>\n<li>Use a safe search-replace tool (for example, a WP-CLI command or a trusted plugin) to replace all instances of <code>http:\/\/example.com<\/code> with <code>https:\/\/example.com<\/code> in the database.<\/li>\n<li>Clear any caches (plugin cache, server cache, CDN cache) and test again.<\/li>\n<\/ol>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-ve-digerlerini-ne-zaman-nasil-uygulamalisin\/'>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>The CDN might serve assets over HTTP if you configured an http:\/\/ origin URL.<\/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>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.<\/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>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 \u2018ERR_SSL_OBSOLETE_VERSION\u2019 or similar.<\/p>\n<p>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.<\/p>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/tls-1-3-ve-modern-sifrelerin-sicacik-mutfagi-nginx-apachede-ocsp-stapling-hsts-preload-ve-pfs-nasil-kurulur\/'>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>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.<\/p>\n<p>On Apache and Nginx, you control this with directives like <code>ssl_ciphers<\/code>, <code>ssl_prefer_server_ciphers<\/code> and <code>ssl_protocols<\/code>. 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.<\/p>\n<h3><span id=\"HSTS_and_certificate_pinning_issues\">HSTS and certificate pinning issues<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>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.<\/li>\n<li>If you include subdomains in HSTS but forget to install SSL on all of them, those subdomains may become unreachable in modern browsers.<\/li>\n<\/ul>\n<p>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.<\/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>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:<\/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. This is fine, but you must make the application and origin server aware of the real 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 trust the proxy and use the forwarded protocol.<\/li>\n<li>Ensure the proxy only sets these headers for traffic it terminates, to avoid spoofing.<\/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>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 <a href='https:\/\/www.dchost.com\/blog\/en\/saaste-ozel-alan-adlari-ve-otomatik-ssl-dns%e2%80%9101-ile-cok-kiracili-mimarini-nasil-tatli-tatli-olceklersin\/'>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>If you see errors about CAA, check your zone for <code>CAA<\/code> records and confirm they allow your chosen CA. We have a detailed article on <a href='https:\/\/www.dchost.com\/blog\/en\/caa-kayitlari-derinlemesine-neden-nasil-ve-ne-zaman-coklu%e2%80%91caya-gecmelisin\/'>CAA records and multi-CA strategies<\/a>, and another one explaining <a href='https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-web-sitenizi-nasil-daha-guvenli-hale-getirir\/'>what DNSSEC is and how it secures your domain<\/a>. From a hosting point of view, aligning these DNS policies with your SSL automation process is crucial to avoid last-minute certificate failures.<\/p>\n<h2><span id=\"How_We_Approach_SSL_Reliability_at_dchostcom\">How We Approach SSL Reliability at dchost.com<\/span><\/h2>\n<p>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:<\/p>\n<ul>\n<li><strong>Automate everything:<\/strong> Issuance, renewal and deployment of certificates should be automated with clear logs and monitoring, not spreadsheets and calendar reminders.<\/li>\n<li><strong>Use battle-tested TLS configs:<\/strong> Start from modern, audited configuration templates instead of copying random snippets from old forum posts.<\/li>\n<li><strong>Keep the chain complete:<\/strong> Always deploy full-chain certificates and verify with command-line tools or online scanners.<\/li>\n<li><strong>Enforce HTTPS end-to-end:<\/strong> Do not stop at the CDN or reverse proxy; protect the full path between the user and your origin servers.<\/li>\n<li><strong>Stage changes:<\/strong> Introduce HSTS, TLS 1.3, or new ciphers gradually, watching logs and error reports instead of toggling everything at once.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Wrapping_Up_A_Simple_Action_Plan_for_a_Clean_Padlock\">Wrapping Up: A Simple Action Plan for a Clean Padlock<\/span><\/h2>\n<p>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.<\/p>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/ssl-sertifika-guvenlik-guncellemeleri-neden-hep-son-dakikaya-kaliyor-ne-zaman-nasil-guncellenmeli\/'>keeping up with SSL security updates<\/a> and <a href='https:\/\/www.dchost.com\/blog\/en\/tls-1-3-ve-modern-sifrelerin-sicacik-mutfagi-nginx-apachede-ocsp-stapling-hsts-preload-ve-pfs-nasil-kurulur\/'>deploying modern TLS 1.3 configs<\/a>, you have everything you need to keep your users\u2019 browsers happy and your brand trusted.<\/p>\n<p>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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>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 \u2018Not Secure\u2019 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, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2192,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2191","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_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":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2191\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2192"}],"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}]}}