What “Real HTTPS Behind a CDN” Actually Means

{
“title”: “Real HTTPS Behind a CDN: Full (Strict) SSL and Origin Encryption Done Right”,
“content”: “

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 “HTTPS via CDN”, 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’s point of view everything looks secure, but in reality your traffic might be exposed on the most sensitive link – 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’s completely fixable. In this article we will walk through what “real HTTPS behind a CDN” actually means, how SSL termination and Full (Strict) SSL work, why “Flexible SSL” is dangerous, and how to configure origin encryption correctly on Nginx, Apache and common hosting stacks.

nnnn

When you put a CDN in front of your site, you suddenly have two separate HTTPS hops:

n

n
• Browser → CDN edge (visitor sees the CDN’s certificate)

n

• CDN edge → origin server (CDN talks to your VPS, dedicated server or hosting account)

n

nn

Real end-to-end HTTPS means both of these links are fully encrypted and properly validated:

n

n
• The browser gets a valid certificate for your domain from the CDN.

n

• The CDN verifies a valid certificate on your origin server before sending traffic there.

n

• HTTP traffic is redirected to HTTPS at both CDN and origin level.

n

• No “mixed content” (HTTP images, scripts, CSS) is left behind.

n

nn

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‑commerce or any login‑based system, this breaks compliance and your security model.

nn

If you are planning a full HTTP→HTTPS migration, it is worth reading our detailed guide on 301 redirects, HSTS and SEO‑safe HTTPS migrations alongside this article, as the concepts complement each other.

nn

SSL Termination, Passthrough and CDN SSL Modes

nn

To configure HTTPS correctly, you first need to understand how TLS termination works in a CDN setup.

nn

Key terms

n

n
• Origin server: Your actual web server at dchost.com (shared hosting, VPS, dedicated or colocated).

n

• CDN edge: The reverse proxy nodes distributed globally that cache and serve your content.

n

• TLS/SSL termination: The point where encrypted traffic is decrypted and becomes plain HTTP internally.

n

• Passthrough: TLS is not terminated; it is passed as-is to the origin (common in TCP load balancers, less common in HTTP-only CDNs).

n

nn

Pattern 1: SSL termination at the CDN only

n

In this pattern, the browser connects over HTTPS to the CDN, but the CDN connects over plain HTTP to your origin:

n

n
• Browser → HTTPS → CDN → HTTP → Origin

n

n

Some providers call this “Flexible SSL”. It is convenient because you do not need any certificate or HTTPS configuration on your origin. However, it is fundamentally insecure:

n

n
• The “last mile” (CDN → origin) is unencrypted.

n

• Attackers on the network path between CDN and origin can sniff or alter traffic.

n

• Your application may believe a request is HTTPS but actually receive it as HTTP, which can break security logic (cookies, redirects, HSTS assumptions).

n

n

For anything beyond a trivial marketing site, we strongly advise never using this mode.

nn

Pattern 2: End-to-end TLS with origin validation (Full Strict)

n

Here, both hops are encrypted and the CDN validates your origin certificate:

n

n
• Browser → HTTPS → CDN → HTTPS (validated) → Origin

n

n

This is usually called “Full (Strict) SSL” or similar. Requirements:

n

n
• Your origin server must present a valid TLS certificate (public CA or a trusted origin certificate).

n

• The certificate must match the hostname the CDN uses to reach your origin.

n

• The certificate must not be expired or revoked.

n

n

With this mode, tampering on the CDN→origin path becomes extremely difficult. This is the mode you should target.

nn

Pattern 3: End-to-end TLS without validation (Full / self‑signed)

n

Some CDNs have a middle mode often labeled simply as “Full” (without strict). In this case:

n

n
• Browser → HTTPS → CDN → HTTPS (not strictly validated) → Origin

n

n

The origin certificate may be self‑signed 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‑in‑the‑middle 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.

nn

Pattern 4: TLS passthrough (less common in CDNs)

n

Some reverse proxies or TCP load balancers can pass TLS straight through to the origin without terminating it:

n

n
• Browser → HTTPS (no decryption) → Proxy → HTTPS → Origin

n

n

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.

nn

Broken HTTPS Setups We Commonly See (and Why They Hurt)

nn

When we onboard new customers at dchost.com or run a security review, we repeatedly encounter a few broken-but-looks-OK configurations.

nn

1. “Flexible SSL” with HTTP origin

n

This is the most common problem:

n

n
• No certificate installed on the origin.

n

• CDN talks to origin over HTTP.

n

• Application thinks it is on HTTPS because of headers like X-Forwarded-Proto: https.

n

n

Issues:

n

n
• Data between CDN and origin is exposed.

n

• Any database queries, admin actions or API calls are visible on that link.

n

• If someone ever reaches the origin directly (bypassing CDN), they will see an HTTP endpoint that often lacks rate limits and WAF protection.

n

nn

2. Self-signed origin certificate without “Strict”

n

Here, an HTTPS origin is configured but the CDN accepts any certificate, even if it is self‑signed or mismatched. During a targeted attack inside the data path, an attacker could present their own certificate to the CDN and still terminate traffic.

nn

3. HTTPS on origin, but HTTP allowed in parallel

n

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:

n

n
• Some internal services or scripts still call the origin via HTTP.

n

• Developers access the server directly over HTTP for convenience.

n

• Search engines might discover and index HTTP URLs if any external link leaks.

n

n

This causes mixed content problems and inconsistent security. If you have already enabled SSL and see “Not fully secure” warnings in browsers, our guide on fixing mixed content and insecure HTTP requests after enabling SSL walks through typical fixes.

nn

4. HSTS enabled too early with misconfigured CDN

n

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:

n

n
• Flexible SSL or non‑strict HTTPS between CDN and origin, or

n

• HTTP endpoints that must remain reachable (e.g., legacy APIs),

n

n

you can lock yourself into a broken state. That is why we always treat HSTS as a final hardening step, after confirming real end‑to‑end HTTPS is working.

nn

Designing a Correct HTTPS + CDN Architecture

nn

Let’s build a mental model of a clean, production‑ready setup, assuming your site is hosted on a dchost.com VPS or dedicated server but the same logic applies to shared hosting as well.

nn

1. Canonical HTTPS domain and redirects

n

n
• Pick one canonical hostname (for example, https://www.example.com).

n

• Redirect all variants to it:
  n
  • http://example.com → https://www.example.com

  n

  • https://example.com → https://www.example.com

  n

  • http://www.example.com → https://www.example.com

  n

  n

n

• Do this first at the origin, then mirror it at the CDN level.

n

n

Our article on www vs non‑www canonical domains, 301 redirects and HSTS goes deeper into the SEO and technical details of this choice.

nn

2. TLS on the origin server

n

Your origin must present a valid certificate for the hostname the CDN uses:

n

n
• If the CDN connects using origin.example.com, that is what your certificate should cover.

n

• If the CDN uses the same hostname as visitors (www.example.com), then your origin certificate must match that.

n

n

You can use Let’s Encrypt or a commercial SSL depending on your needs; our comparison of Let’s Encrypt vs commercial SSL certificates for e‑commerce and corporate sites explains trade‑offs.

nn

3. CDN configured in Full (Strict) mode

n

Once your origin has a valid certificate, switch the CDN’s SSL mode to the strict variant:

n

n
• “Full (Strict)”, “Strict SSL”, “Verify certificate” or similar name.

n

• Avoid “Flexible” or “Full” without strict verification if at all possible.

n

n

In this mode, if the origin certificate breaks or expires, the CDN will fail hard instead of silently falling back to HTTP – which is exactly what you want in a secure design.

nn

4. Locking down direct origin access

n

Ideally, the public should not be able to hit your origin server directly over HTTP(S). Strategies:

n

n
• Bind your web server to a private IP used only by the CDN.

n

• Use firewall rules to allow only CDN IP ranges to reach port 80/443.

n

• Use mutual TLS (mTLS) or authenticated origin pulls when the CDN supports it.

n

n

We discuss authenticated origin pulls and mTLS in detail in our article Protect your origin like you mean it, which is a natural companion to the concepts in this guide.

nn

Step‑by‑Step: Enabling Full (Strict) SSL Behind a CDN

nn

Let’s go through a concrete setup. Assume:

n

n
• Your public site is https://www.example.com behind a CDN.

n

• The origin is a dchost.com VPS running Nginx or Apache on www.example.com as well.

n

nn

Step 1: Issue and install an origin certificate

n

n
1. On your server or control panel, request a certificate for www.example.com (or origin.example.com if you use a separate origin hostname).

n

2. Use HTTP‑01 or DNS‑01 validation as appropriate.

n

3. Install the certificate and private key in your web server configuration or via your panel (cPanel, DirectAdmin, Plesk, etc.).

n

n

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 monitoring SSL certificate expiry across many domains shows how to avoid unpleasant surprises.

nn

Step 2: Force HTTPS at the origin

n

You should enforce HTTPS even if the CDN usually connects via HTTPS, to ensure a consistent security posture and protect direct origin access.

nn

Nginx example

n

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

nn

Apache example (.htaccess)

n

<IfModule mod_rewrite.c>nRewriteEngine OnnRewriteCond %{HTTPS} !=onnRewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]n</IfModule>n

nn

Make sure your application (WordPress, Laravel, custom PHP, etc.) is configured to use HTTPS URLs as its base URL. For example:

n

n
• WordPress: set WordPress Address and Site Address to https://.

n

• Laravel: set APP_URL=https://www.example.com in .env.

n

nn

Step 3: Configure the CDN to use HTTPS for origin pulls

n

In your CDN dashboard:

n

n
• Set origin protocol to “HTTPS only” or “Use HTTPS”.

n

• Ensure the origin host the CDN uses matches the CN/SAN of your certificate.

n

• If your CDN supports it, pin the exact hostname and disallow certificate mismatches.

n

n

This ensures every request the CDN sends to your server is encrypted and validated.

nn

Step 4: Change SSL mode to Full (Strict)

n

Now switch the SSL mode to strict verification:

n

n
• Select “Full (Strict)” or “Strict SSL”.

n

• Disable “Flexible SSL” or any mode that allows HTTP origin fallbacks.

n

• Save and wait a minute for the change to propagate.

n

n

Test your site:

n

n
• Visit https://www.example.com in an incognito window.

n

• Check the certificate in your browser’s security panel – you should see the CDN’s edge certificate.

n

• Use curl -v https://www.example.com from a remote machine to verify you do not get SSL errors.

n

nn

Step 5: Clean up mixed content and old HTTP links

n

Even with perfect TLS, mixed content can cause security warnings and block some resources. You need to:

n

n
• Search your HTML, templates and database for http:// references to your domain.

n

• Update them to https:// or protocol‑relative URLs when safely possible.

n

• Stop emitting absolute HTTP URLs in your application templates.

n

n

Our dedicated article on fixing mixed content errors after enabling SSL includes WordPress and common CMS scenarios.

nn

Step 6: Enable HSTS once you are confident

n

After a few days of stable operation, you can enable HSTS to enforce HTTPS in user agents:

n

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;n

n

Be cautious with includeSubDomains and especially with HSTS preload lists. Our HTTP security headers guide walks through safe rollout strategies and common pitfalls.

nn

Origin Encryption Details: TLS Versions, Ciphers and OCSP

nn

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.

nn

Modern TLS versions only

n

n
• Disable TLS 1.0 and TLS 1.1.

n

• Support at least TLS 1.2, and preferably TLS 1.3 as well.

n

n

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 TLS 1.3, OCSP stapling and Brotli on Nginx.

nn

Cipher suites and PFS

n

Use strong cipher suites with forward secrecy (PFS). A typical Nginx example:

n

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

n

Adjust based on your stack and client base, and test with a TLS scanner to avoid compatibility issues.

nn

OCSP stapling and certificate chain health

n

OCSP stapling lets your server provide revocation status to the CDN efficiently. While the browser sees the CDN’s certificate, it is still best practice to keep your origin’s chain and OCSP responses healthy:

n

n
• Install intermediate certificates correctly.

n

• Enable OCSP stapling if your web server supports it.

n

• Monitor certificate expiration and renewal errors.

n

nn

Locking Down the Origin: IP Whitelisting, mTLS and Private Networks

nn

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’s IP directly.

nn

Strategy 1: Firewall restricts access to CDN IPs only

n

n
• Find your CDN’s official IP ranges (usually documented).

n

• On your VPS or dedicated server, use ufw, firewalld or iptables/nftables to allow ports 80/443 only from those ranges.

n

• Deny 80/443 from all other public IPs.

n

n

Our checklist on firewall configuration on VPS servers is a good reference while implementing this.

nn

Strategy 2: Authenticated origin pulls or mTLS

n

Some CDNs support:

n

n
• Authenticated origin pulls: CDN presents a client certificate, and your origin is configured to trust only that certificate.

n

• Mutual TLS (mTLS): Both sides verify each other’s certificates.

n

n

In such setups, even if someone discovers your origin IP and can reach it, the TLS handshake will fail without the CDN’s client certificate. For a hands‑on walkthrough of this approach, see our dedicated origin protection guide using authenticated origin pulls and mTLS.

nn

Strategy 3: Private networking and tunnels

n

In more advanced architectures:

n

n
• Your origin lives on a private network or RFC1918 address.

n

• The CDN connects through a private link, VPN or tunnel.

n

• No public routing exists for the origin’s IP.

n

n

This is ideal in multi‑region or high‑security deployments and combines well with strict TLS and mTLS at the same time.

nn

Testing, Monitoring and Automation

nn

Functional tests

n

n
• Use curl -I https://www.example.com from several locations (or via VPN) to make sure you always get HTTPS responses and 301 redirects behave as expected.

n

• Hit your origin directly (if allowed) with curl -I https://origin.example.com to confirm it enforces HTTPS and presents the right certificate.

n

• Use browser devtools “Security” tab to confirm no mixed content and a clean TLS chain.

n

nn

Failure tests

n

n
• 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.

n

• Try to access http://origin-ip directly; you should see either a redirect to HTTPS or a blocked connection.

n

nn

Monitoring and renewals

n

Do not rely on calendar reminders for certificate renewals. Instead:

n

n
• Automate issuance and renewal with ACME clients.

n

• Set up external checks that alert you well before expiry.

n

• Monitor both CDN edge certificates and origin certificates if they are separate.

n

n

Again, our article on SSL certificate expiry monitoring and automation gives practical scripts and service options to keep things sane at scale.

nn

Checklist: Real HTTPS Behind Your CDN

nn

To wrap the configuration into something actionable, here is a condensed checklist you can run through for each project:

nn

n
• Domain & redirectsn
  n
  • Decide on a canonical hostname (www vs non‑www).

  n

  • Implement 301 redirects to the canonical hostname at the origin.

  n

  • Mirror those redirects at the CDN edge where possible.

  n

  n

n

• Origin TLSn
  n
  • Issue a valid certificate for the origin hostname.

  n

  • Install certificate and key on the web server.

  n

  • Force HTTP→HTTPS on the origin.

  n

  • Disable TLS 1.0/1.1 and use modern cipher suites.

  n

  n

n

• CDN configurationn
  n
  • Set origin protocol to HTTPS only.

  n

  • Enable Full (Strict) SSL or equivalent.

  n

  • Disable Flexible SSL and HTTP fallbacks.

  n

  • Configure caching and WAF rules as needed.

  n

  n

n

• Origin hardeningn
  n
  • Restrict ports 80/443 to CDN IP ranges via firewall.

  n

  • Enable authenticated origin pulls or mTLS if available.

  n

  • Avoid exposing origin IPs in DNS records or public places.

  n

  n

n

• Application clean‑upn
  n
  • Update application configuration to use HTTPS base URLs.

  n

  • Fix mixed content and insecure asset URLs.

  n

  • Review cookies for Secure and SameSite flags.

  n

  n

n

• Security headers & HSTSn
  n
  • Add HSTS header after confirming all HTTPS paths are clean.

  n

  • Configure other security headers (CSP, X-Frame-Options, etc.).

  n

  n

n

• Monitoringn
  n
  • Automate SSL renewal on origin and at CDN.

  n

  • Set up expiry alerts for all domains.

  n

  • Periodically scan your site with TLS/HTTPS testing tools.

  n

  n

n

nn

Bringing It All Together: Secure, Fast and Maintainable HTTPS

nn

CDNs and HTTPS are often sold as simple toggles, but in real‑world hosting this is where small misconfigurations can quietly undermine your security model. As we have seen, “green padlock in the browser” does not automatically mean the entire path from your visitor’s 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.

nn

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—whether 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.

n”,
“focus_keyword”: “real https behind a cdn”,
“meta_description”: “Learn how to configure real HTTPS behind a CDN with Full (Strict) SSL, secure origin encryption, correct redirects and firewall rules on Nginx/Apache.”,
“faqs”: [
{
“question”: “What is the difference between Flexible SSL and Full (Strict) SSL behind a CDN?”,
“answer”: “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’s 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.”
},
{
“question”: “Do I really need an SSL certificate on the origin if my CDN already provides HTTPS?”,
“answer”: “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.”
},
{
“question”: “How should I secure my origin server so attackers cannot bypass the CDN?”,
“answer”: “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.”
},
{
“question”: “When is it safe to enable HSTS after moving a site behind a CDN?”,
“answer”: “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.”
},
{
“question”: “How can I monitor SSL certificate expiry for both CDN and origin certificates?”,
“answer”: “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’s Encrypt certificates automatically and log any failures. In parallel, set up external monitoring that checks each HTTPS hostname regularly, parses the certificate’s 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’s SSL expiry monitoring guide, can prevent last-minute surprises.”
}
]
}