SSL at the Origin: Why the Padlock Does Not Mean the Connection Is Encrypted

When a CDN sits in front of your server, there are two separate TLS connections: browser to CDN, and CDN to origin. The padlock in the browser only tells you about the first one. If the second is plain HTTP, your traffic crosses the public internet unencrypted while the site looks perfectly secure.

This gap has a name — Flexible mode — and it exists because it makes a legacy site show a padlock with no server changes at all. That convenience is exactly why it is still switched on in a lot of places where nobody intended it, and it is worth knowing how to check.

Table of contents

• Two connections, two different guarantees
• Origin certificates, and why they are different
• Locking the origin so it can only be reached through the CDN
• Checking what you actually have
• How this fits the rest of the stack
• FAQ

Two connections, two different guarantees

With a CDN or reverse proxy in the path, a request makes two hops:

Browser  --- TLS ---> CDN edge  --- ??? --->  Your origin server

The browser only ever evaluates the first hop. It sees a valid certificate for your hostname presented by the edge, shows a padlock, and has no way of knowing what happens beyond it.

The common modes, and what each actually does:

• Off. No encryption anywhere. Nothing to discuss.
• Flexible. Browser to CDN is encrypted; CDN to origin is plain HTTP. Padlock shown, second hop in the clear.
• Full. Both hops encrypted, but the origin’s certificate is not validated — a self-signed or expired certificate is accepted. Encrypted against passive eavesdropping, not against an active attacker who can intercept.
• Full (Strict). Both hops encrypted and the origin certificate validated against a trusted CA. This is the one that means what people think the padlock means.

Flexible is the problem case. Login credentials, session cookies, personal data and API payloads travel unencrypted between the CDN’s network and your server, across whatever infrastructure sits between them. Anyone positioned along that path sees everything, and the site gives no visible indication.

There is a second-order effect too: your origin server sees the CDN’s address and an http scheme, so any application logic that redirects HTTP to HTTPS can end up in a redirect loop, and any code checking whether the request was secure gets the wrong answer.

Origin certificates, and why they are different

An origin certificate is issued by the CDN’s own certificate authority for use on your server. It is trusted by that CDN and by nothing else — a browser connecting directly would reject it — which is precisely the point.

The practical advantages over a public certificate on the origin:

• Long validity. Origin certificates are typically issued for years rather than months, because the only party that has to trust them is the CDN. That removes the renewal treadmill on the origin.
• No domain validation each time. You are already proving control by being the CDN’s customer.
• They work on a server with no public exposure. A public CA cannot validate a host that is not reachable from the internet; the CDN’s CA does not need to.

Installation is ordinary: generate the certificate in the CDN dashboard, choose PEM for anything OpenSSL-based like Apache or nginx, install the certificate and key on the origin, upload the CA root where the platform requires it, and enable TLS on port 443 at the origin.

Then switch the mode to Full (Strict). Installing an origin certificate and leaving the mode on Flexible achieves nothing — the CDN will keep talking plain HTTP to a server that is perfectly capable of TLS.

The alternative is a normal publicly-trusted certificate on the origin, which is equally valid and lets the origin serve traffic correctly if it is ever reached directly. The trade is the usual ninety-day renewal cycle.

Locking the origin so it can only be reached through the CDN

Encryption on the second hop is half the job. The other half is making sure nobody bypasses the CDN entirely.

If your origin’s address is reachable directly, an attacker who finds it — and there are search engines that index exactly this — can hit your server without passing through any of the CDN’s protections. Your WAF rules, rate limiting and bot filtering all live at the edge.

Three layers, best first:

1. Firewall to the CDN’s address ranges only. The provider publishes them. Everything else is dropped, so the origin is unreachable except through the edge.
2. Authenticated origin pulls. The CDN presents a client certificate that your server requires. Even a request from an allowed address without the certificate is rejected — this survives an attacker on the same provider network.
3. A shared secret header. The CDN adds a header with a value your origin checks. Weakest of the three, and better than nothing when you cannot do the others.

Also be careful not to leak the origin address, because the usual causes are mundane: DNS records for direct.example.com or origin.example.com still resolving, mail sent from the same host revealing it in headers, an old A record in a historical DNS dataset, or an error page printing the internal hostname.

Checking what you actually have

Do not trust the dashboard setting alone. Verify from outside.

# What does the browser-facing hop present?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

# Does the origin itself answer TLS? (test against its address directly)
echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer

# Is the origin reachable on plain HTTP from anywhere?
curl -sI http://203.0.113.10/ -H 'Host: example.com' | head -n 1

If that last command returns a page rather than timing out, your origin is directly reachable and the firewall step above has not been done.

Two configuration details that matter once the second hop is encrypted:

• HSTS. Send Strict-Transport-Security so browsers refuse plain HTTP for your domain in future. Start with a short max-age, confirm nothing breaks, then raise it — the header is difficult to walk back once browsers have cached it.
• Forwarded headers. Configure your application to read the real client address from X-Forwarded-For and the real scheme from X-Forwarded-Proto. Without it, every request appears to come from the CDN, which breaks rate limiting, geolocation and audit logs — and only trust those headers from the CDN’s addresses, since a client can send them too.

How this fits the rest of the stack

The general lesson is that a padlock is a statement about one hop, and a security posture is a statement about all of them. Anywhere a proxy sits in front of a server, it is worth knowing what the second connection is doing rather than assuming it inherits the first.

RunxBuild removes the question by handling the certificate itself. A custom domain on a static site or a web service gets a certificate that is issued and renewed automatically, with the route terminated properly rather than assembled from an edge setting plus an origin you configured separately. Services in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploy from your GitHub repository, and managed MySQL and Postgres sit behind them on private networking rather than on a public address that needs firewalling. Response headers, redirects and rewrites are configuration. To see what a site, a service and a database add up to, the RunxBuild hosting calculator lists them as separate line items.

Useful related references:

• How to Renew an SSL Certificate: A 2026 Guide
• What Does SSL Mean? And Why Nobody Actually Uses SSL Anymore
• SSL_connect Error 5: What SSL_ERROR_SYSCALL Actually Means
• Database connection limits on RunxBuild

FAQ

What is an origin certificate?

A certificate issued by a CDN’s own certificate authority for installation on your server. It is trusted by that CDN and by no browser, which is fine because only the CDN connects to your origin. In exchange it is valid for years rather than months and needs no repeated domain validation.

Does the padlock mean my whole connection is encrypted?

No. It only describes the hop between the browser and whatever terminates TLS — usually a CDN edge. If the CDN is configured in Flexible mode, it talks to your origin over plain HTTP while the browser still shows a padlock, so credentials and session data cross the internet unencrypted.

What is the difference between Full and Full (Strict)?

Full encrypts the CDN-to-origin hop but accepts any certificate, including self-signed or expired ones, so it protects against passive eavesdropping but not against an active interception. Full (Strict) also validates the origin certificate against a trusted CA, which is what most people assume they already have.

Should I use an origin certificate or a public one?

Either works. An origin certificate lasts years and needs no renewal automation, which suits a server that is only ever reached through the CDN. A publicly-trusted certificate means the origin still serves valid TLS if reached directly, at the cost of the usual ninety-day renewal cycle.

How do I stop people bypassing the CDN?

Firewall the origin to the CDN’s published address ranges so nothing else can connect, and enable authenticated origin pulls so the CDN presents a client certificate your server requires. Also check that no DNS record still points at the origin directly and that error pages do not print the internal hostname.