{"id":4130,"date":"2026-01-04T14:52:54","date_gmt":"2026-01-04T11:52:54","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/what-real-https-behind-a-cdn-actually-means\/"},"modified":"2026-01-04T14:52:54","modified_gmt":"2026-01-04T11:52:54","slug":"what-real-https-behind-a-cdn-actually-means","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/what-real-https-behind-a-cdn-actually-means\/","title":{"rendered":"What \u201cReal HTTPS Behind a CDN\u201d Actually Means"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>{<br \/>\n  &#8220;title&#8221;: &#8220;Real HTTPS Behind a CDN: Full (Strict) SSL and Origin Encryption Done Right&#8221;,<br \/>\n  &#8220;content&#8221;: &#8220;<\/p>\n<p>Putting a CDN in front of your website is one of the easiest ways to speed up global visitors and add an extra security layer. But the moment you enable \u201cHTTPS via CDN\u201d, a subtle trap appears: the connection between the visitor and the CDN can be encrypted, while the CDN-to-origin hop stays on plain HTTP or on a poorly validated certificate. From the browser\u2019s point of view everything looks secure, but in reality your traffic might be exposed on the most sensitive link \u2013 between the CDN edge and your hosting server. In performance reviews and security audits we run for dchost.com customers, we regularly see this exact pattern. The good news: it\u2019s completely fixable. In this article we will walk through what \u201creal HTTPS behind a CDN\u201d actually means, how SSL termination and Full (Strict) SSL work, why \u201cFlexible SSL\u201d is dangerous, and how to configure origin encryption correctly on Nginx, Apache and common hosting stacks.<\/p>\n<p>nnnn<\/p>\n<p>When you put a CDN in front of your site, you suddenly have two separate HTTPS hops:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>Browser \u2192 CDN edge<\/strong> (visitor sees the CDN\u2019s certificate)<\/li>\n<p>n  <\/p>\n<li><strong>CDN edge \u2192 origin server<\/strong> (CDN talks to your <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or hosting account)<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p><strong>Real end-to-end HTTPS<\/strong> means both of these links are fully encrypted and properly validated:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>The browser gets a valid certificate for your domain from the CDN.<\/li>\n<p>n  <\/p>\n<li>The CDN verifies a valid certificate on your origin server before sending traffic there.<\/li>\n<p>n  <\/p>\n<li>HTTP traffic is redirected to HTTPS at both CDN and origin level.<\/li>\n<p>n  <\/p>\n<li>No \u201cmixed content\u201d (HTTP images, scripts, CSS) is left behind.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>If you only secure the first hop, an attacker who can sniff or tamper with traffic between the CDN and your server (for example, inside a data center, ISP or compromised router) can still read or modify requests. For e\u2011commerce or any login\u2011based system, this breaks compliance and your security model.<\/p>\n<p>nn<\/p>\n<p>If you are planning a full HTTP\u2192HTTPS migration, it is worth reading our detailed guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/\">301 redirects, HSTS and SEO\u2011safe HTTPS migrations<\/a> alongside this article, as the concepts complement each other.<\/p>\n<p>nn<\/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=\"#SSL_Termination_Passthrough_and_CDN_SSL_Modes\"><span class=\"toc_number toc_depth_1\">1<\/span> SSL Termination, Passthrough and CDN SSL Modes<\/a><ul><li><a href=\"#Key_terms\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Key terms<\/a><\/li><li><a href=\"#Pattern_1_SSL_termination_at_the_CDN_only\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Pattern 1: SSL termination at the CDN only<\/a><\/li><li><a href=\"#Pattern_2_End-to-end_TLS_with_origin_validation_Full_Strict\"><span class=\"toc_number toc_depth_2\">1.3<\/span> Pattern 2: End-to-end TLS with origin validation (Full Strict)<\/a><\/li><li><a href=\"#Pattern_3_End-to-end_TLS_without_validation_Full_selfsigned\"><span class=\"toc_number toc_depth_2\">1.4<\/span> Pattern 3: End-to-end TLS without validation (Full \/ self\u2011signed)<\/a><\/li><li><a href=\"#Pattern_4_TLS_passthrough_less_common_in_CDNs\"><span class=\"toc_number toc_depth_2\">1.5<\/span> Pattern 4: TLS passthrough (less common in CDNs)<\/a><\/li><\/ul><\/li><li><a href=\"#Broken_HTTPS_Setups_We_Commonly_See_and_Why_They_Hurt\"><span class=\"toc_number toc_depth_1\">2<\/span> Broken HTTPS Setups We Commonly See (and Why They Hurt)<\/a><ul><li><a href=\"#1_Flexible_SSL_with_HTTP_origin\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1. \u201cFlexible SSL\u201d with HTTP origin<\/a><\/li><li><a href=\"#2_Self-signed_origin_certificate_without_Strict\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2. Self-signed origin certificate without \u201cStrict\u201d<\/a><\/li><li><a href=\"#3_HTTPS_on_origin_but_HTTP_allowed_in_parallel\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 3. HTTPS on origin, but HTTP allowed in parallel<\/a><\/li><li><a href=\"#4_HSTS_enabled_too_early_with_misconfigured_CDN\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 4. HSTS enabled too early with misconfigured CDN<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_a_Correct_HTTPS_CDN_Architecture\"><span class=\"toc_number toc_depth_1\">3<\/span> Designing a Correct HTTPS + CDN Architecture<\/a><ul><li><a href=\"#1_Canonical_HTTPS_domain_and_redirects\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. Canonical HTTPS domain and redirects<\/a><\/li><li><a href=\"#2_TLS_on_the_origin_server\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. TLS on the origin server<\/a><\/li><li><a href=\"#3_CDN_configured_in_Full_Strict_mode\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. CDN configured in Full (Strict) mode<\/a><\/li><li><a href=\"#4_Locking_down_direct_origin_access\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 4. Locking down direct origin access<\/a><\/li><\/ul><\/li><li><a href=\"#StepbyStep_Enabling_Full_Strict_SSL_Behind_a_CDN\"><span class=\"toc_number toc_depth_1\">4<\/span> Step\u2011by\u2011Step: Enabling Full (Strict) SSL Behind a CDN<\/a><ul><li><a href=\"#Step_1_Issue_and_install_an_origin_certificate\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Step 1: Issue and install an origin certificate<\/a><\/li><li><a href=\"#Step_2_Force_HTTPS_at_the_origin\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step 2: Force HTTPS at the origin<\/a><ul><li><a href=\"#Nginx_example\"><span class=\"toc_number toc_depth_3\">4.2.1<\/span> Nginx example<\/a><\/li><li><a href=\"#Apache_example_htaccess\"><span class=\"toc_number toc_depth_3\">4.2.2<\/span> Apache example (.htaccess)<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Configure_the_CDN_to_use_HTTPS_for_origin_pulls\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Step 3: Configure the CDN to use HTTPS for origin pulls<\/a><\/li><li><a href=\"#Step_4_Change_SSL_mode_to_Full_Strict\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Step 4: Change SSL mode to Full (Strict)<\/a><\/li><li><a href=\"#Step_5_Clean_up_mixed_content_and_old_HTTP_links\"><span class=\"toc_number toc_depth_2\">4.5<\/span> Step 5: Clean up mixed content and old HTTP links<\/a><\/li><li><a href=\"#Step_6_Enable_HSTS_once_you_are_confident\"><span class=\"toc_number toc_depth_2\">4.6<\/span> Step 6: Enable HSTS once you are confident<\/a><\/li><\/ul><\/li><li><a href=\"#Origin_Encryption_Details_TLS_Versions_Ciphers_and_OCSP\"><span class=\"toc_number toc_depth_1\">5<\/span> Origin Encryption Details: TLS Versions, Ciphers and OCSP<\/a><ul><li><a href=\"#Modern_TLS_versions_only\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Modern TLS versions only<\/a><\/li><li><a href=\"#Cipher_suites_and_PFS\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Cipher suites and PFS<\/a><\/li><li><a href=\"#OCSP_stapling_and_certificate_chain_health\"><span class=\"toc_number toc_depth_2\">5.3<\/span> OCSP stapling and certificate chain health<\/a><\/li><\/ul><\/li><li><a href=\"#Locking_Down_the_Origin_IP_Whitelisting_mTLS_and_Private_Networks\"><span class=\"toc_number toc_depth_1\">6<\/span> Locking Down the Origin: IP Whitelisting, mTLS and Private Networks<\/a><ul><li><a href=\"#Strategy_1_Firewall_restricts_access_to_CDN_IPs_only\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Strategy 1: Firewall restricts access to CDN IPs only<\/a><\/li><li><a href=\"#Strategy_2_Authenticated_origin_pulls_or_mTLS\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Strategy 2: Authenticated origin pulls or mTLS<\/a><\/li><li><a href=\"#Strategy_3_Private_networking_and_tunnels\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Strategy 3: Private networking and tunnels<\/a><\/li><\/ul><\/li><li><a href=\"#Testing_Monitoring_and_Automation\"><span class=\"toc_number toc_depth_1\">7<\/span> Testing, Monitoring and Automation<\/a><ul><li><a href=\"#Functional_tests\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Functional tests<\/a><\/li><li><a href=\"#Failure_tests\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Failure tests<\/a><\/li><li><a href=\"#Monitoring_and_renewals\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Monitoring and renewals<\/a><\/li><\/ul><\/li><li><a href=\"#Checklist_Real_HTTPS_Behind_Your_CDN\"><span class=\"toc_number toc_depth_1\">8<\/span> Checklist: Real HTTPS Behind Your CDN<\/a><\/li><li><a href=\"#Bringing_It_All_Together_Secure_Fast_and_Maintainable_HTTPS\"><span class=\"toc_number toc_depth_1\">9<\/span> Bringing It All Together: Secure, Fast and Maintainable HTTPS<\/a><\/li><\/ul><\/div>\n<h2><span id=\"SSL_Termination_Passthrough_and_CDN_SSL_Modes\">SSL Termination, Passthrough and CDN SSL Modes<\/span><\/h2>\n<p>nn<\/p>\n<p>To configure HTTPS correctly, you first need to understand how TLS termination works in a CDN setup.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Key_terms\">Key terms<\/span><\/h3>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>Origin server<\/strong>: Your actual web server at dchost.com (shared hosting, VPS, dedicated or colocated).<\/li>\n<p>n  <\/p>\n<li><strong>CDN edge<\/strong>: The reverse proxy nodes distributed globally that cache and serve your content.<\/li>\n<p>n  <\/p>\n<li><strong>TLS\/SSL termination<\/strong>: The point where encrypted traffic is decrypted and becomes plain HTTP internally.<\/li>\n<p>n  <\/p>\n<li><strong>Passthrough<\/strong>: TLS is not terminated; it is passed as-is to the origin (common in TCP load balancers, less common in HTTP-only CDNs).<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Pattern_1_SSL_termination_at_the_CDN_only\">Pattern 1: SSL termination at the CDN only<\/span><\/h3>\n<p>n<\/p>\n<p>In this pattern, the browser connects over HTTPS to the CDN, but the CDN connects over plain HTTP to your origin:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Browser \u2192 <strong>HTTPS<\/strong> \u2192 CDN \u2192 <strong>HTTP<\/strong> \u2192 Origin<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Some providers call this <strong>\u201cFlexible SSL\u201d<\/strong>. It is convenient because you do not need any certificate or HTTPS configuration on your origin. However, it is fundamentally insecure:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>The \u201clast mile\u201d (CDN \u2192 origin) is unencrypted.<\/li>\n<p>n  <\/p>\n<li>Attackers on the network path between CDN and origin can sniff or alter traffic.<\/li>\n<p>n  <\/p>\n<li>Your application may believe a request is HTTPS but actually receive it as HTTP, which can break security logic (cookies, redirects, HSTS assumptions).<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>For anything beyond a trivial marketing site, we strongly advise never using this mode.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Pattern_2_End-to-end_TLS_with_origin_validation_Full_Strict\">Pattern 2: End-to-end TLS with origin validation (Full Strict)<\/span><\/h3>\n<p>n<\/p>\n<p>Here, both hops are encrypted and the CDN <strong>validates<\/strong> your origin certificate:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Browser \u2192 <strong>HTTPS<\/strong> \u2192 CDN \u2192 <strong>HTTPS (validated)<\/strong> \u2192 Origin<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>This is usually called <strong>\u201cFull (Strict) SSL\u201d<\/strong> or similar. Requirements:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Your origin server must present a valid TLS certificate (public CA or a trusted origin certificate).<\/li>\n<p>n  <\/p>\n<li>The certificate must match the hostname the CDN uses to reach your origin.<\/li>\n<p>n  <\/p>\n<li>The certificate must not be expired or revoked.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>With this mode, tampering on the CDN\u2192origin path becomes extremely difficult. This is the mode you should target.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Pattern_3_End-to-end_TLS_without_validation_Full_selfsigned\">Pattern 3: End-to-end TLS without validation (Full \/ self\u2011signed)<\/span><\/h3>\n<p>n<\/p>\n<p>Some CDNs have a middle mode often labeled simply as \u201cFull\u201d (without <em>strict<\/em>). In this case:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Browser \u2192 <strong>HTTPS<\/strong> \u2192 CDN \u2192 <strong>HTTPS (not strictly validated)<\/strong> \u2192 Origin<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>The origin certificate may be self\u2011signed or invalid. The connection is encrypted, but the CDN does not verify identity strongly. This is better than cleartext HTTP, but it does not fully block man\u2011in\u2011the\u2011middle attacks on the server side. If your CDN supports a strict mode, prefer that, even if it means installing a proper certificate or origin cert on your server.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Pattern_4_TLS_passthrough_less_common_in_CDNs\">Pattern 4: TLS passthrough (less common in CDNs)<\/span><\/h3>\n<p>n<\/p>\n<p>Some reverse proxies or TCP load balancers can pass TLS straight through to the origin without terminating it:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Browser \u2192 <strong>HTTPS (no decryption)<\/strong> \u2192 Proxy \u2192 <strong>HTTPS<\/strong> \u2192 Origin<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Here, the origin serves the certificate the browser sees, and the proxy never inspects HTTP headers. This pattern is used more in L4 load balancing and for protocols like SMTP, not so much in classic web CDNs that need to cache and rewrite content.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Broken_HTTPS_Setups_We_Commonly_See_and_Why_They_Hurt\">Broken HTTPS Setups We Commonly See (and Why They Hurt)<\/span><\/h2>\n<p>nn<\/p>\n<p>When we onboard new customers at dchost.com or run a security review, we repeatedly encounter a few broken-but-looks-OK configurations.<\/p>\n<p>nn<\/p>\n<h3><span id=\"1_Flexible_SSL_with_HTTP_origin\">1. \u201cFlexible SSL\u201d with HTTP origin<\/span><\/h3>\n<p>n<\/p>\n<p>This is the most common problem:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>No certificate installed on the origin.<\/li>\n<p>n  <\/p>\n<li>CDN talks to origin over HTTP.<\/li>\n<p>n  <\/p>\n<li>Application thinks it is on HTTPS because of headers like <code>X-Forwarded-Proto: https<\/code>.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Issues:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Data between CDN and origin is exposed.<\/li>\n<p>n  <\/p>\n<li>Any database queries, admin actions or API calls are visible on that link.<\/li>\n<p>n  <\/p>\n<li>If someone ever reaches the origin directly (bypassing CDN), they will see an HTTP endpoint that often lacks rate limits and WAF protection.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"2_Self-signed_origin_certificate_without_Strict\">2. Self-signed origin certificate without \u201cStrict\u201d<\/span><\/h3>\n<p>n<\/p>\n<p>Here, an HTTPS origin is configured but the CDN accepts any certificate, even if it is self\u2011signed or mismatched. During a targeted attack inside the data path, an attacker could present their own certificate to the CDN and still terminate traffic.<\/p>\n<p>nn<\/p>\n<h3><span id=\"3_HTTPS_on_origin_but_HTTP_allowed_in_parallel\">3. HTTPS on origin, but HTTP allowed in parallel<\/span><\/h3>\n<p>n<\/p>\n<p>Another frequent pattern: the origin listens on both HTTP and HTTPS, but there is no redirect from HTTP to HTTPS. The CDN is configured to use HTTPS, yet:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Some internal services or scripts still call the origin via HTTP.<\/li>\n<p>n  <\/p>\n<li>Developers access the server directly over HTTP for convenience.<\/li>\n<p>n  <\/p>\n<li>Search engines might discover and index HTTP URLs if any external link leaks.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>This causes <strong>mixed content<\/strong> problems and inconsistent security. If you have already enabled SSL and see \u201cNot fully secure\u201d warnings in browsers, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sonrasi-mixed-content-ve-guvensiz-icerik-hatalarini-duzeltmek\/\">fixing mixed content and insecure HTTP requests after enabling SSL<\/a> walks through typical fixes.<\/p>\n<p>nn<\/p>\n<h3><span id=\"4_HSTS_enabled_too_early_with_misconfigured_CDN\">4. HSTS enabled too early with misconfigured CDN<\/span><\/h3>\n<p>n<\/p>\n<p>HSTS forces browsers to always use HTTPS for your domain. It is great once everything is clean, but if you enable HSTS and still have:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Flexible SSL or non\u2011strict HTTPS between CDN and origin, or<\/li>\n<p>n  <\/p>\n<li>HTTP endpoints that must remain reachable (e.g., legacy APIs),<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>you can lock yourself into a broken state. That is why we always treat HSTS as a <strong>final hardening step<\/strong>, after confirming real end\u2011to\u2011end HTTPS is working.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Designing_a_Correct_HTTPS_CDN_Architecture\">Designing a Correct HTTPS + CDN Architecture<\/span><\/h2>\n<p>nn<\/p>\n<p>Let\u2019s build a mental model of a clean, production\u2011ready setup, assuming your site is hosted on a dchost.com VPS or dedicated server but the same logic applies to shared hosting as well.<\/p>\n<p>nn<\/p>\n<h3><span id=\"1_Canonical_HTTPS_domain_and_redirects\">1. Canonical HTTPS domain and redirects<\/span><\/h3>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Pick one canonical hostname (for example, <code>https:\/\/www.example.com<\/code>).<\/li>\n<p>n  <\/p>\n<li>Redirect all variants to it:\n<ul>n      <\/p>\n<li><code>http:\/\/example.com<\/code> \u2192 <code>https:\/\/www.example.com<\/code><\/li>\n<p>n      <\/p>\n<li><code>https:\/\/example.com<\/code> \u2192 <code>https:\/\/www.example.com<\/code><\/li>\n<p>n      <\/p>\n<li><code>http:\/\/www.example.com<\/code> \u2192 <code>https:\/\/www.example.com<\/code><\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li>Do this <strong>first at the origin<\/strong>, then mirror it at the CDN level.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/www-mi-ciplak-alan-adi-mi-canonical-domain-301-ve-hsts-icin-dogru-ayarlar\/\">www vs non\u2011www canonical domains, 301 redirects and HSTS<\/a> goes deeper into the SEO and technical details of this choice.<\/p>\n<p>nn<\/p>\n<h3><span id=\"2_TLS_on_the_origin_server\">2. TLS on the origin server<\/span><\/h3>\n<p>n<\/p>\n<p>Your origin must present a valid certificate for the hostname the CDN uses:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>If the CDN connects using <code>origin.example.com<\/code>, that is what your certificate should cover.<\/li>\n<p>n  <\/p>\n<li>If the CDN uses the same hostname as visitors (<code>www.example.com<\/code>), then your origin certificate must match that.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>You can use Let\u2019s Encrypt or a commercial SSL depending on your needs; our comparison of <a href=\"https:\/\/www.dchost.com\/blog\/en\/ucretsiz-lets-encrypt-mi-kurumsal-ssl-sertifikasi-mi-e%e2%80%91ticaret-ve-kurumsal-siteler-icin-yol-haritasi\/\">Let\u2019s Encrypt vs commercial SSL certificates for e\u2011commerce and corporate sites<\/a> explains trade\u2011offs.<\/p>\n<p>nn<\/p>\n<h3><span id=\"3_CDN_configured_in_Full_Strict_mode\">3. CDN configured in Full (Strict) mode<\/span><\/h3>\n<p>n<\/p>\n<p>Once your origin has a valid certificate, switch the CDN\u2019s SSL mode to the strict variant:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>\u201cFull (Strict)\u201d, \u201cStrict SSL\u201d, \u201cVerify certificate\u201d or similar name.<\/li>\n<p>n  <\/p>\n<li>Avoid \u201cFlexible\u201d or \u201cFull\u201d without strict verification if at all possible.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>In this mode, if the origin certificate breaks or expires, the CDN will <strong>fail hard<\/strong> instead of silently falling back to HTTP \u2013 which is exactly what you want in a secure design.<\/p>\n<p>nn<\/p>\n<h3><span id=\"4_Locking_down_direct_origin_access\">4. Locking down direct origin access<\/span><\/h3>\n<p>n<\/p>\n<p>Ideally, the public should not be able to hit your origin server directly over HTTP(S). Strategies:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Bind your web server to a private IP used only by the CDN.<\/li>\n<p>n  <\/p>\n<li>Use firewall rules to allow only CDN IP ranges to reach port 80\/443.<\/li>\n<p>n  <\/p>\n<li>Use mutual TLS (mTLS) or authenticated origin pulls when the CDN supports it.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>We discuss authenticated origin pulls and mTLS in detail in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/origini-korumak-cloudflare-authenticated-origin-pulls-ve-mtls-ile-gercek-kaynak-dogrulamasi\/\">Protect your origin like you mean it<\/a>, which is a natural companion to the concepts in this guide.<\/p>\n<p>nn<\/p>\n<h2><span id=\"StepbyStep_Enabling_Full_Strict_SSL_Behind_a_CDN\">Step\u2011by\u2011Step: Enabling Full (Strict) SSL Behind a CDN<\/span><\/h2>\n<p>nn<\/p>\n<p>Let\u2019s go through a concrete setup. Assume:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Your public site is <code>https:\/\/www.example.com<\/code> behind a CDN.<\/li>\n<p>n  <\/p>\n<li>The origin is a dchost.com VPS running Nginx or Apache on <code>www.example.com<\/code> as well.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Step_1_Issue_and_install_an_origin_certificate\">Step 1: Issue and install an origin certificate<\/span><\/h3>\n<p>n<\/p>\n<ol>n  <\/p>\n<li>On your server or control panel, request a certificate for <code>www.example.com<\/code> (or <code>origin.example.com<\/code> if you use a separate origin hostname).<\/li>\n<p>n  <\/p>\n<li>Use HTTP\u201101 or DNS\u201101 validation as appropriate.<\/li>\n<p>n  <\/p>\n<li>Install the certificate and private key in your web server configuration or via your panel (cPanel, DirectAdmin, Plesk, etc.).<\/li>\n<p>n<\/ol>\n<p>n<\/p>\n<p>If you manage many domains, consider automating issuance and renewal with ACME clients such as certbot or acme.sh. For larger portfolios, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/onlarca-alan-adi-icin-ssl-sertifika-sure-sonu-izleme-ve-otomatik-yenileme-stratejisi\/\">monitoring SSL certificate expiry across many domains<\/a> shows how to avoid unpleasant surprises.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Step_2_Force_HTTPS_at_the_origin\">Step 2: Force HTTPS at the origin<\/span><\/h3>\n<p>n<\/p>\n<p>You should enforce HTTPS even if the CDN usually connects via HTTPS, to ensure a consistent security posture and protect direct origin access.<\/p>\n<p>nn<\/p>\n<h4><span id=\"Nginx_example\">Nginx example<\/span><\/h4>\n<p>n<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">server {n    listen 80;n    listen [::]:80;n    server_name www.example.com example.com;nn    return 301 https:\/\/www.example.com$request_uri;n}nnserver {n    listen 443 ssl http2;n    listen [::]:443 ssl http2;n    server_name www.example.com;nn    ssl_certificate     \/etc\/letsencrypt\/live\/www.example.com\/fullchain.pem;n    ssl_certificate_key \/etc\/letsencrypt\/live\/www.example.com\/privkey.pem;nn    # your usual root, PHP, proxy_pass, etc.n}n<\/code><\/pre>\n<p>nn<\/p>\n<h4><span id=\"Apache_example_htaccess\">Apache example (.htaccess)<\/span><\/h4>\n<p>n<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">&lt;IfModule mod_rewrite.c&gt;nRewriteEngine OnnRewriteCond %{HTTPS} !=onnRewriteRule ^ https:\/\/www.example.com%{REQUEST_URI} [L,R=301]n&lt;\/IfModule&gt;n<\/code><\/pre>\n<p>nn<\/p>\n<p>Make sure your application (WordPress, Laravel, custom PHP, etc.) is configured to use HTTPS URLs as its base URL. For example:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>WordPress: set <strong>WordPress Address<\/strong> and <strong>Site Address<\/strong> to <code>https:\/\/<\/code>.<\/li>\n<p>n  <\/p>\n<li>Laravel: set <code>APP_URL=https:\/\/www.example.com<\/code> in <code>.env<\/code>.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Step_3_Configure_the_CDN_to_use_HTTPS_for_origin_pulls\">Step 3: Configure the CDN to use HTTPS for origin pulls<\/span><\/h3>\n<p>n<\/p>\n<p>In your CDN dashboard:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Set origin protocol to \u201cHTTPS only\u201d or \u201cUse HTTPS\u201d.<\/li>\n<p>n  <\/p>\n<li>Ensure the origin host the CDN uses matches the CN\/SAN of your certificate.<\/li>\n<p>n  <\/p>\n<li>If your CDN supports it, pin the exact hostname and disallow certificate mismatches.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>This ensures every request the CDN sends to your server is encrypted and validated.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Step_4_Change_SSL_mode_to_Full_Strict\">Step 4: Change SSL mode to Full (Strict)<\/span><\/h3>\n<p>n<\/p>\n<p>Now switch the SSL mode to strict verification:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Select \u201cFull (Strict)\u201d or \u201cStrict SSL\u201d.<\/li>\n<p>n  <\/p>\n<li>Disable \u201cFlexible SSL\u201d or any mode that allows HTTP origin fallbacks.<\/li>\n<p>n  <\/p>\n<li>Save and wait a minute for the change to propagate.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Test your site:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Visit <code>https:\/\/www.example.com<\/code> in an incognito window.<\/li>\n<p>n  <\/p>\n<li>Check the certificate in your browser\u2019s security panel \u2013 you should see the CDN\u2019s edge certificate.<\/li>\n<p>n  <\/p>\n<li>Use <code>curl -v https:\/\/www.example.com<\/code> from a remote machine to verify you do not get SSL errors.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Step_5_Clean_up_mixed_content_and_old_HTTP_links\">Step 5: Clean up mixed content and old HTTP links<\/span><\/h3>\n<p>n<\/p>\n<p>Even with perfect TLS, mixed content can cause security warnings and block some resources. You need to:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Search your HTML, templates and database for <code>http:\/\/<\/code> references to your domain.<\/li>\n<p>n  <\/p>\n<li>Update them to <code>https:\/\/<\/code> or protocol\u2011relative URLs when safely possible.<\/li>\n<p>n  <\/p>\n<li>Stop emitting absolute HTTP URLs in your application templates.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Our dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sonrasi-mixed-content-ve-guvensiz-icerik-hatalarini-duzeltmek\/\">fixing mixed content errors after enabling SSL<\/a> includes WordPress and common CMS scenarios.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Step_6_Enable_HSTS_once_you_are_confident\">Step 6: Enable HSTS once you are confident<\/span><\/h3>\n<p>n<\/p>\n<p>After a few days of stable operation, you can enable HSTS to enforce HTTPS in user agents:<\/p>\n<p>n<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">add_header Strict-Transport-Security &quot;max-age=31536000; includeSubDomains&quot; always;n<\/code><\/pre>\n<p>n<\/p>\n<p>Be cautious with <code>includeSubDomains<\/code> and especially with HSTS preload lists. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-referrer-policy-dogru-nasil-kurulur\/\">HTTP security headers guide<\/a> walks through safe rollout strategies and common pitfalls.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Origin_Encryption_Details_TLS_Versions_Ciphers_and_OCSP\">Origin Encryption Details: TLS Versions, Ciphers and OCSP<\/span><\/h2>\n<p>nn<\/p>\n<p>Once you have Full (Strict) SSL in place, you can go further and tune the TLS stack on the origin for stronger security and better performance.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Modern_TLS_versions_only\">Modern TLS versions only<\/span><\/h3>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Disable <strong>TLS 1.0<\/strong> and <strong>TLS 1.1<\/strong>.<\/li>\n<p>n  <\/p>\n<li>Support at least <strong>TLS 1.2<\/strong>, and preferably <strong>TLS 1.3<\/strong> as well.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Most CDNs will negotiate TLS 1.2 or 1.3 to your origin if it is available. For details on practical TLS 1.3 configuration, OCSP stapling and performance wins, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginxte-tls-1-3-ocsp-stapling-ve-brotli-nasil-kurulur-hizli-ve-guvenli-httpsnin-sicacik-rehberi\/\">TLS 1.3, OCSP stapling and Brotli on Nginx<\/a>.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Cipher_suites_and_PFS\">Cipher suites and PFS<\/span><\/h3>\n<p>n<\/p>\n<p>Use strong cipher suites with forward secrecy (PFS). A typical Nginx example:<\/p>\n<p>n<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssl_protocols TLSv1.2 TLSv1.3;nssl_prefer_server_ciphers on;nssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:n             ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';n<\/code><\/pre>\n<p>n<\/p>\n<p>Adjust based on your stack and client base, and test with a TLS scanner to avoid compatibility issues.<\/p>\n<p>nn<\/p>\n<h3><span id=\"OCSP_stapling_and_certificate_chain_health\">OCSP stapling and certificate chain health<\/span><\/h3>\n<p>n<\/p>\n<p>OCSP stapling lets your server provide revocation status to the CDN efficiently. While the browser sees the CDN\u2019s certificate, it is still best practice to keep your origin\u2019s chain and OCSP responses healthy:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Install intermediate certificates correctly.<\/li>\n<p>n  <\/p>\n<li>Enable OCSP stapling if your web server supports it.<\/li>\n<p>n  <\/p>\n<li>Monitor certificate expiration and renewal errors.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h2><span id=\"Locking_Down_the_Origin_IP_Whitelisting_mTLS_and_Private_Networks\">Locking Down the Origin: IP Whitelisting, mTLS and Private Networks<\/span><\/h2>\n<p>nn<\/p>\n<p>With HTTPS fully working, the next step is to protect the origin from direct internet access. Otherwise, attackers can often bypass CDN WAF, rate limits and caching by hitting the server\u2019s IP directly.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Strategy_1_Firewall_restricts_access_to_CDN_IPs_only\">Strategy 1: Firewall restricts access to CDN IPs only<\/span><\/h3>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Find your CDN\u2019s official IP ranges (usually documented).<\/li>\n<p>n  <\/p>\n<li>On your VPS or dedicated server, use <code>ufw<\/code>, <code>firewalld<\/code> or <code>iptables\/nftables<\/code> to allow ports 80\/443 only from those ranges.<\/li>\n<p>n  <\/p>\n<li>Deny 80\/443 from all other public IPs.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Our checklist on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucularda-guvenlik-duvari-yapilandirma-ufw-firewalld-ve-iptables\/\">firewall configuration on VPS servers<\/a> is a good reference while implementing this.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Strategy_2_Authenticated_origin_pulls_or_mTLS\">Strategy 2: Authenticated origin pulls or mTLS<\/span><\/h3>\n<p>n<\/p>\n<p>Some CDNs support:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>Authenticated origin pulls<\/strong>: CDN presents a client certificate, and your origin is configured to trust only that certificate.<\/li>\n<p>n  <\/p>\n<li><strong>Mutual TLS (mTLS)<\/strong>: Both sides verify each other\u2019s certificates.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>In such setups, even if someone discovers your origin IP and can reach it, the TLS handshake will fail without the CDN\u2019s client certificate. For a hands\u2011on walkthrough of this approach, see our dedicated origin protection guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/origini-korumak-cloudflare-authenticated-origin-pulls-ve-mtls-ile-gercek-kaynak-dogrulamasi\/\">using authenticated origin pulls and mTLS<\/a>.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Strategy_3_Private_networking_and_tunnels\">Strategy 3: Private networking and tunnels<\/span><\/h3>\n<p>n<\/p>\n<p>In more advanced architectures:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Your origin lives on a private network or RFC1918 address.<\/li>\n<p>n  <\/p>\n<li>The CDN connects through a private link, VPN or tunnel.<\/li>\n<p>n  <\/p>\n<li>No public routing exists for the origin\u2019s IP.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>This is ideal in multi\u2011region or high\u2011security deployments and combines well with strict TLS and mTLS at the same time.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Testing_Monitoring_and_Automation\">Testing, Monitoring and Automation<\/span><\/h2>\n<p>nn<\/p>\n<h3><span id=\"Functional_tests\">Functional tests<\/span><\/h3>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Use <code>curl -I https:\/\/www.example.com<\/code> from several locations (or via VPN) to make sure you always get HTTPS responses and 301 redirects behave as expected.<\/li>\n<p>n  <\/p>\n<li>Hit your origin directly (if allowed) with <code>curl -I https:\/\/origin.example.com<\/code> to confirm it enforces HTTPS and presents the right certificate.<\/li>\n<p>n  <\/p>\n<li>Use browser devtools \u201cSecurity\u201d tab to confirm no mixed content and a clean TLS chain.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Failure_tests\">Failure tests<\/span><\/h3>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Temporarily revoke HTTPS on the origin in a staging environment and check that the CDN fails loud (error page) instead of silently downgrading to HTTP.<\/li>\n<p>n  <\/p>\n<li>Try to access <code>http:\/\/origin-ip<\/code> directly; you should see either a redirect to HTTPS or a blocked connection.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Monitoring_and_renewals\">Monitoring and renewals<\/span><\/h3>\n<p>n<\/p>\n<p>Do not rely on calendar reminders for certificate renewals. Instead:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Automate issuance and renewal with ACME clients.<\/li>\n<p>n  <\/p>\n<li>Set up external checks that alert you well before expiry.<\/li>\n<p>n  <\/p>\n<li>Monitor both CDN edge certificates and origin certificates if they are separate.<\/li>\n<p>n<\/ul>\n<p>n<\/p>\n<p>Again, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/onlarca-alan-adi-icin-ssl-sertifika-sure-sonu-izleme-ve-otomatik-yenileme-stratejisi\/\">SSL certificate expiry monitoring and automation<\/a> gives practical scripts and service options to keep things sane at scale.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Checklist_Real_HTTPS_Behind_Your_CDN\">Checklist: Real HTTPS Behind Your CDN<\/span><\/h2>\n<p>nn<\/p>\n<p>To wrap the configuration into something actionable, here is a condensed checklist you can run through for each project:<\/p>\n<p>nn<\/p>\n<ul>n  <\/p>\n<li><strong>Domain &amp; redirects<\/strong>n\n<ul>n      <\/p>\n<li>Decide on a canonical hostname (www vs non\u2011www).<\/li>\n<p>n      <\/p>\n<li>Implement 301 redirects to the canonical hostname at the origin.<\/li>\n<p>n      <\/p>\n<li>Mirror those redirects at the CDN edge where possible.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Origin TLS<\/strong>n\n<ul>n      <\/p>\n<li>Issue a valid certificate for the origin hostname.<\/li>\n<p>n      <\/p>\n<li>Install certificate and key on the web server.<\/li>\n<p>n      <\/p>\n<li>Force HTTP\u2192HTTPS on the origin.<\/li>\n<p>n      <\/p>\n<li>Disable TLS 1.0\/1.1 and use modern cipher suites.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>CDN configuration<\/strong>n\n<ul>n      <\/p>\n<li>Set origin protocol to HTTPS only.<\/li>\n<p>n      <\/p>\n<li>Enable Full (Strict) SSL or equivalent.<\/li>\n<p>n      <\/p>\n<li>Disable Flexible SSL and HTTP fallbacks.<\/li>\n<p>n      <\/p>\n<li>Configure caching and WAF rules as needed.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Origin hardening<\/strong>n\n<ul>n      <\/p>\n<li>Restrict ports 80\/443 to CDN IP ranges via firewall.<\/li>\n<p>n      <\/p>\n<li>Enable authenticated origin pulls or mTLS if available.<\/li>\n<p>n      <\/p>\n<li>Avoid exposing origin IPs in DNS records or public places.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Application clean\u2011up<\/strong>n\n<ul>n      <\/p>\n<li>Update application configuration to use HTTPS base URLs.<\/li>\n<p>n      <\/p>\n<li>Fix mixed content and insecure asset URLs.<\/li>\n<p>n      <\/p>\n<li>Review cookies for <code>Secure<\/code> and <code>SameSite<\/code> flags.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Security headers &amp; HSTS<\/strong>n\n<ul>n      <\/p>\n<li>Add HSTS header after confirming all HTTPS paths are clean.<\/li>\n<p>n      <\/p>\n<li>Configure other security headers (CSP, X-Frame-Options, etc.).<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Monitoring<\/strong>n\n<ul>n      <\/p>\n<li>Automate SSL renewal on origin and at CDN.<\/li>\n<p>n      <\/p>\n<li>Set up expiry alerts for all domains.<\/li>\n<p>n      <\/p>\n<li>Periodically scan your site with TLS\/HTTPS testing tools.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h2><span id=\"Bringing_It_All_Together_Secure_Fast_and_Maintainable_HTTPS\">Bringing It All Together: Secure, Fast and Maintainable HTTPS<\/span><\/h2>\n<p>nn<\/p>\n<p>CDNs and HTTPS are often sold as simple toggles, but in real\u2011world hosting this is where small misconfigurations can quietly undermine your security model. As we have seen, \u201cgreen padlock in the browser\u201d does not automatically mean the entire path from your visitor\u2019s device to your dchost.com server is encrypted and authenticated correctly. The critical difference lies in how SSL termination is handled, whether your CDN validates the origin certificate with Full (Strict) SSL, and how well you lock down direct origin access.<\/p>\n<p>nn<\/p>\n<p>If you follow the architecture and checklist in this guide, you end up with a stack that is fast, resilient and compliant: the CDN handles global performance and WAF duties, while your origin stays behind a properly encrypted and restricted channel. When you host your projects on dchost.com shared hosting, VPS, dedicated servers or colocation, our team can help you design and review this setup\u2014whether you are migrating an existing site to HTTPS, adding a CDN on top of a mature application, or planning a new platform from scratch. If you would like a second pair of eyes on your current configuration, feel free to reach out to us; building clean, real HTTPS architectures behind CDNs is something we do every day.<\/p>\n<p>n&#8221;,<br \/>\n  &#8220;focus_keyword&#8221;: &#8220;real https behind a cdn&#8221;,<br \/>\n  &#8220;meta_description&#8221;: &#8220;Learn how to configure real HTTPS behind a CDN with Full (Strict) SSL, secure origin encryption, correct redirects and firewall rules on Nginx\/Apache.&#8221;,<br \/>\n  &#8220;faqs&#8221;: [<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;What is the difference between Flexible SSL and Full (Strict) SSL behind a CDN?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;Flexible SSL encrypts only the connection between the browser and the CDN; the CDN then connects to your origin server over plain HTTP. From the user\u2019s perspective the site looks secure, but the CDN-to-origin hop is unencrypted and vulnerable to sniffing or tampering. Full (Strict) SSL encrypts both hops and also validates the origin certificate: the CDN will only connect to your server if it presents a valid, non-expired certificate matching the expected hostname. This ensures true end-to-end HTTPS and should be the target mode for serious projects.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;Do I really need an <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a> on the origin if my CDN already provides HTTPS?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;Yes. If the CDN is the only place that has a certificate and your origin only speaks HTTP, you get encryption on the browser-to-CDN hop but not between CDN and origin. That internal link often carries the most sensitive data: admin logins, API requests, database queries, and more. Installing a proper certificate on the origin and configuring the CDN in Full (Strict) mode ensures that every request remains encrypted and that the CDN verifies it is talking to the correct server, not a man-in-the-middle on the network path.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;How should I secure my origin server so attackers cannot bypass the CDN?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;First, enforce HTTPS on the origin and use a valid TLS certificate so you can enable Full (Strict) SSL at the CDN. Then restrict direct access: use firewall rules on your VPS or dedicated server to only allow ports 80 and 443 from official CDN IP ranges, denying all other sources. Where supported, enable authenticated origin pulls or mutual TLS so the origin only accepts traffic from the CDN presenting a trusted client certificate. Avoid publishing the origin IP in public DNS records and regularly test that direct IP access is blocked or redirected safely.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;When is it safe to enable HSTS after moving a site behind a CDN?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;Enable HSTS only after you have verified that HTTPS works cleanly end-to-end. That means: your origin has a valid certificate, the CDN is in Full (Strict) mode, HTTP is redirected to HTTPS both at the CDN and the origin, and there are no mixed content issues in your pages. Start with a shorter HSTS max-age (for example, a few days or weeks) and monitor for problems. Once you are confident, you can increase the max-age and optionally add includeSubDomains or preload. Enabling HSTS too early while still using Flexible SSL or leaving HTTP endpoints active can lock you into a broken state.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;How can I monitor SSL certificate expiry for both CDN and origin certificates?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;The best approach is to combine automated renewal with proactive monitoring. Use ACME clients such as certbot or acme.sh on your origin server to renew Let\u2019s Encrypt certificates automatically and log any failures. In parallel, set up external monitoring that checks each HTTPS hostname regularly, parses the certificate\u2019s expiry date and alerts you well before it expires. This should cover both the origin certificates and any certificates managed by your CDN. For environments with many domains or clients, a centralised expiry monitoring system, as described in dchost.com\u2019s SSL expiry monitoring guide, can prevent last-minute surprises.&#8221;<br \/>\n    }<br \/>\n  ]<br \/>\n}<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>{ &#8220;title&#8221;: &#8220;Real HTTPS Behind a CDN: Full (Strict) SSL and Origin Encryption Done Right&#8221;, &#8220;content&#8221;: &#8220; Putting a CDN in front of your website is one of the easiest ways to speed up global visitors and add an extra security layer. But the moment you enable \u201cHTTPS via CDN\u201d, a subtle trap appears: the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4131,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4130","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\/4130","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=4130"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4130\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4131"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}