What “Real HTTPS Behind a CDN” Actually Means

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.

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

• Browser → CDN edge (visitor sees the CDN’s certificate)
• CDN edge → origin server (CDN talks to your VPS, dedicated server or hosting account)

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

• The browser gets a valid certificate for your domain from the CDN.
• The CDN verifies a valid certificate on your origin server before sending traffic there.
• HTTP traffic is redirected to HTTPS at both CDN and origin level.
• No “mixed content” (HTTP images, scripts, CSS) is left behind.

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.

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.

SSL Termination, Passthrough and CDN SSL Modes

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

Key terms

• Origin server: Your actual web server at dchost.com (shared hosting, VPS, dedicated or colocated).
• CDN edge: The reverse proxy nodes distributed globally that cache and serve your content.
• TLS/SSL termination: The point where encrypted traffic is decrypted and becomes plain HTTP internally.
• Passthrough: TLS is not terminated; it is passed as-is to the origin (common in TCP load balancers, less common in HTTP-only CDNs).

Pattern 1: SSL termination at the CDN only

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

• Browser → HTTPS → CDN → HTTP → Origin

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:

• The “last mile” (CDN → origin) is unencrypted.
• Attackers on the network path between CDN and origin can sniff or alter traffic.
• Your application may believe a request is HTTPS but actually receive it as HTTP, which can break security logic (cookies, redirects, HSTS assumptions).

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

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

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

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

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

• Your origin server must present a valid TLS certificate (public CA or a trusted origin certificate).
• The certificate must match the hostname the CDN uses to reach your origin.
• The certificate must not be expired or revoked.

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

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

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

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

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.

Pattern 4: TLS passthrough (less common in CDNs)

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

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

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.

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

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

1. “Flexible SSL” with HTTP origin

This is the most common problem:

• No certificate installed on the origin.
• CDN talks to origin over HTTP.
• Application thinks it is on HTTPS because of headers like X-Forwarded-Proto: https.

Issues:

• Data between CDN and origin is exposed.
• Any database queries, admin actions or API calls are visible on that link.
• If someone ever reaches the origin directly (bypassing CDN), they will see an HTTP endpoint that often lacks rate limits and WAF protection.

2. Self-signed origin certificate without “Strict”

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.

3. HTTPS on origin, but HTTP allowed in parallel

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:

• Some internal services or scripts still call the origin via HTTP.
• Developers access the server directly over HTTP for convenience.
• Search engines might discover and index HTTP URLs if any external link leaks.

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.

4. HSTS enabled too early with misconfigured CDN

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:

• Flexible SSL or non‑strict HTTPS between CDN and origin, or
• HTTP endpoints that must remain reachable (e.g., legacy APIs),

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.

Designing a Correct HTTPS + CDN Architecture

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.

1. Canonical HTTPS domain and redirects

• Pick one canonical hostname (for example, https://www.example.com).
• Redirect all variants to it:
  • http://example.com → https://www.example.com
  • https://example.com → https://www.example.com
  • http://www.example.com → https://www.example.com
• Do this first at the origin, then mirror it at the CDN level.

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

2. TLS on the origin server

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

• If the CDN connects using origin.example.com, that is what your certificate should cover.
• If the CDN uses the same hostname as visitors (www.example.com), then your origin certificate must match that.

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.

3. CDN configured in Full (Strict) mode

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

• “Full (Strict)”, “Strict SSL”, “Verify certificate” or similar name.
• Avoid “Flexible” or “Full” without strict verification if at all possible.

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.

4. Locking down direct origin access

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

• Bind your web server to a private IP used only by the CDN.
• Use firewall rules to allow only CDN IP ranges to reach port 80/443.
• Use mutual TLS (mTLS) or authenticated origin pulls when the CDN supports it.

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.

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

Let’s go through a concrete setup. Assume:

• Your public site is https://www.example.com behind a CDN.
• The origin is a dchost.com VPS running Nginx or Apache on www.example.com as well.

Step 1: Issue and install an origin certificate

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).
2. Use HTTP‑01 or DNS‑01 validation as appropriate.
3. Install the certificate and private key in your web server configuration or via your panel (cPanel, DirectAdmin, Plesk, etc.).

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.

Step 2: Force HTTPS at the origin

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

Nginx example

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

Apache example (.htaccess)

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

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

• WordPress: set WordPress Address and Site Address to https://.
• Laravel: set APP_URL=https://www.example.com in .env.

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

In your CDN dashboard:

• Set origin protocol to “HTTPS only” or “Use HTTPS”.
• Ensure the origin host the CDN uses matches the CN/SAN of your certificate.
• If your CDN supports it, pin the exact hostname and disallow certificate mismatches.

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

Step 4: Change SSL mode to Full (Strict)

Now switch the SSL mode to strict verification:

• Select “Full (Strict)” or “Strict SSL”.
• Disable “Flexible SSL” or any mode that allows HTTP origin fallbacks.
• Save and wait a minute for the change to propagate.

Test your site:

• Visit https://www.example.com in an incognito window.
• Check the certificate in your browser’s security panel – you should see the CDN’s edge certificate.
• Use curl -v https://www.example.com from a remote machine to verify you do not get SSL errors.

Step 5: Clean up mixed content and old HTTP links

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

• Search your HTML, templates and database for http:// references to your domain.
• Update them to https:// or protocol‑relative URLs when safely possible.
• Stop emitting absolute HTTP URLs in your application templates.

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

Step 6: Enable HSTS once you are confident

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

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

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

Origin Encryption Details: TLS Versions, Ciphers and OCSP

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.

Modern TLS versions only

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

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.

Cipher suites and PFS

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

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

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

OCSP stapling and certificate chain health

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:

• Install intermediate certificates correctly.
• Enable OCSP stapling if your web server supports it.
• Monitor certificate expiration and renewal errors.

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

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.

Strategy 1: Firewall restricts access to CDN IPs only

• Find your CDN’s official IP ranges (usually documented).
• On your VPS or dedicated server, use ufw, firewalld or iptables/nftables to allow ports 80/443 only from those ranges.
• Deny 80/443 from all other public IPs.

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

Strategy 2: Authenticated origin pulls or mTLS

Some CDNs support:

• Authenticated origin pulls: CDN presents a client certificate, and your origin is configured to trust only that certificate.
• Mutual TLS (mTLS): Both sides verify each other’s certificates.

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.

Strategy 3: Private networking and tunnels

In more advanced architectures:

• Your origin lives on a private network or RFC1918 address.
• The CDN connects through a private link, VPN or tunnel.
• No public routing exists for the origin’s IP.

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

Testing, Monitoring and Automation

Functional tests

• 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.
• Hit your origin directly (if allowed) with curl -I https://origin.example.com to confirm it enforces HTTPS and presents the right certificate.
• Use browser devtools “Security” tab to confirm no mixed content and a clean TLS chain.

Failure tests

• 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.
• Try to access http://origin-ip directly; you should see either a redirect to HTTPS or a blocked connection.

Monitoring and renewals

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

• Automate issuance and renewal with ACME clients.
• Set up external checks that alert you well before expiry.
• Monitor both CDN edge certificates and origin certificates if they are separate.

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

Checklist: Real HTTPS Behind Your CDN

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

• Domain & redirects
  • Decide on a canonical hostname (www vs non‑www).
  • Implement 301 redirects to the canonical hostname at the origin.
  • Mirror those redirects at the CDN edge where possible.
• Origin TLS
  • Issue a valid certificate for the origin hostname.
  • Install certificate and key on the web server.
  • Force HTTP→HTTPS on the origin.
  • Disable TLS 1.0/1.1 and use modern cipher suites.
• CDN configuration
  • Set origin protocol to HTTPS only.
  • Enable Full (Strict) SSL or equivalent.
  • Disable Flexible SSL and HTTP fallbacks.
  • Configure caching and WAF rules as needed.
• Origin hardening
  • Restrict ports 80/443 to CDN IP ranges via firewall.
  • Enable authenticated origin pulls or mTLS if available.
  • Avoid exposing origin IPs in DNS records or public places.
• Application clean‑up
  • Update application configuration to use HTTPS base URLs.
  • Fix mixed content and insecure asset URLs.
  • Review cookies for Secure and SameSite flags.
• Security headers & HSTS
  • Add HSTS header after confirming all HTTPS paths are clean.
  • Configure other security headers (CSP, X-Frame-Options, etc.).
• Monitoring
  • Automate SSL renewal on origin and at CDN.
  • Set up expiry alerts for all domains.
  • Periodically scan your site with TLS/HTTPS testing tools.

Bringing It All Together: Secure, Fast and Maintainable HTTPS

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.

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.