HTTP or HTTPS for CDN Origin Fetches? Choosing Certificates, SNI, and Ports

After a website is connected to a CDN, users access CDN edge nodes, but edge nodes may still need to fetch pages, APIs, or uncached files from the origin server. This process is called origin pull.

Many websites encounter this during onboarding: users access over HTTPS and the origin server has a certificate installed, yet as soon as the CDN performs an origin pull, 502 errors, TLS handshake failures, certificate domain mismatches, or redirect loops occur. The issue is usually not simply whether a certificate exists, but that the origin pull protocol, port, SNI, HTTP Host, and certificate domain are not aligned.

For a normally running production website, the following is recommended first:

Use HTTPS for CDN-to-origin connections, on port 443 or a vendor-supported HTTPS port, enable strict certificate validation, and ensure that the domain corresponding to the origin SNI is included in the origin certificate's SAN.

HTTP origin pull is not entirely unusable, but if the CDN and origin communicate over the public internet, HTTP removes transport encryption and origin authentication from this link. Login credentials, cookies, API data, and origin authentication headers may all be exposed over an unencrypted link.

User access over HTTPS does not mean CDN origin pull is also HTTPS

An HTTPS visit through a CDN may actually involve two independent connections:

用户浏览器
    │
    │ HTTPS：验证CDN边缘证书
    ▼
CDN边缘节点
    │
    │ HTTP或HTTPS：由CDN回源配置决定
    ▼
源站服务器

The first is the edge connection between the user and the CDN, using the edge certificate configured for the accelerated domain.

The second is the origin connection between the CDN and the origin server, using the origin certificate. Even if the browser shows a padlock, this does not indicate whether the origin link is encrypted.

Therefore, the following configurations are all technically possible:

For simple configuration and stable results, you should generally redirect HTTP access to HTTPS at the edge and have the CDN consistently use HTTPS for origin pulls, rather than letting the origin protocol vary with the visitor's protocol.

Should CDN origin pull use HTTP or HTTPS?

Production websites should prefer HTTPS origin pulls

The following services should not rely solely on HTTP origin pulls:

• Login, registration, and user center;

• E-commerce order and payment pages;

• API endpoints and requests carrying tokens;

• Websites that use cookies to maintain sessions;

• Admin panels and internal enterprise systems;

• Pages involving personal information or business-sensitive data;

• Services where traffic between the origin and CDN nodes crosses the public internet.

In addition to encrypting data, HTTPS origin pulls can verify origin identity through certificates. If the CDN strictly checks the certificate, it can reduce the risk of traffic being forwarded to the wrong server or an intermediary node.

When HTTP origin pull may be used

HTTP origin pull is generally suitable only in the following limited scenarios:

• The origin genuinely does not support TLS and is temporarily in a migration phase;

• The CDN and origin communicate over a controlled dedicated line, private network, or encrypted tunnel;

• Purely public static content, and the risks of the origin link have been assessed;

• Internal test environments that do not carry real user data.

Even if the origin is on a private network, confirm that the link is truly isolated. Do not assume transmission is secure just because an internal IP is used. HTTP origin pull is better suited as a temporary compatibility measure, not the default choice for production.

First distinguish origin address, origin Host, and SNI

When configuring HTTPS origin pulls, these three values are most easily confused:

These three values may be the same or different, depending on the origin architecture and the configuration capabilities offered by the CDN vendor.

The origin address determines the connection target

The origin address can be an IP or a dedicated origin domain. For example:

源站地址：203.0.113.10
回源端口：443

Or:

源站地址：origin.example.net
回源端口：443

The origin address answers “where should the CDN connect?” If you use an origin domain, avoid having that domain resolve back to the current CDN, or an origin pull loop may occur.

To further distinguish edge nodes from the actual origin, see CdnChart'sCDN node IP vs. origin IP.

SNI determines which certificate the origin returns

Multiple HTTPS websites can be hosted on the same IP and port 443. At the time of the TLS handshake, no HTTP request has been sent yet, so the server cannot select a site based on the HTTP Host. The client therefore uses SNI during the handshake to tell the server which hostname it intends to access.

RFC 6066 definition of SNIexplains how clients include the server name in the TLS ClientHello so that multiple virtual hosts on the same address can select the appropriate certificate.

For example, the origin hosts multiple websites at the same time:

203.0.113.10
├── www.example.com
├── api.example.com
└── static.example.com

If the CDN does not send SNI or sends the wrong SNI during origin pull, the server may return the default site's certificate. In this case, the port may be reachable, but the TLS handshake can still fail due to a certificate domain mismatch.

Origin Host determines which website receives the request

After the TLS handshake completes, the CDN sends the HTTP request. The Host in the request determines which virtual host Nginx, Apache, a load balancer, or an application gateway routes the request to.

Therefore, the following may occur:

源站地址：203.0.113.10
SNI：origin.example.net
Host：www.example.com

This means:

1. CDN connects to203.0.113.10:443;

2. TLS handshake usesorigin.example.netas SNI;

3. Origin returns a certificate coveringorigin.example.net;

4. After TLS succeeds, the HTTP request usesHost: www.example.com;

5. The web server routes the request towww.example.comthe corresponding site.

Not all CDNs allow SNI and origin Host to be set separately. Some vendors keep them consistent by default, some synchronize SNI when Host is changed, and others require a separate origin rule. Check the current vendor's documentation before configuring; do not assume all CDNs behave the same.

Which domain should the origin certificate include?

The origin certificate must match the name the CDN actually uses for certificate validation, typically the origin SNI or the vendor-defined origin hostname.

For example:

回源SNI：origin.example.net

Then the origin certificate's Subject Alternative Name (SAN) should include at least:

DNS:origin.example.net

RFC 9525 service identity specificationexplicitly emphasizes that DNS names should be verified through the certificate'ssubjectAltNameSAN, not by relying only on the certificate Common Name.

When checking, do not just look at whether the certificate has expired; also verify:

• Whether the certificate is within its validity period;

• Whether the SAN includes the origin validation domain;

• Whether the intermediate certificate chain is complete;

• Whether the issuing CA is trusted by the CDN;

• Whether the origin returns the correct certificate on the target port;

• Whether every server in a multi-origin environment has consistent configuration.

Wildcard certificates also have boundaries.*.example.comThey can usually coverorigin.example.combut not the root domainexample.comand cannot covera.origin.example.commulti-level subdomains such as this.

Public CA certificate vs. CDN origin certificate

Origins can generally use the following certificates:

For example, Cloudflare'sFull (strict) mode documentationrequires a valid origin certificate, a matching domain, and issuance by a trusted public CA or its Origin CA. This is specific to Cloudflare. Whether other CDNs accept vendor origin certificates, self-signed certificates, or private CAs must be confirmed separately.

If you may switch CDNs or use multiple CDNs in the future, a public CA certificate is usually easier to migrate. A vendor-specific origin certificate suits an architecture where the origin allows only that vendor to access it, but it should not be treated as an ordinary public certificate that all clients can validate.

Should the origin port be 80, 443, or 8443?

Protocol and port are two independent configuration items, but common mappings are as follows:

Changing the port to 8443 does not automatically improve security. Security comes from TLS, certificate validation, access control, and proper origin authentication, not from whether the port number is uncommon.

Also distinguish two concepts:

• The edge port users use to access the CDN;

• The destination port the CDN uses to connect to the origin.

Users accessing the CDN over port 443 does not mean the CDN must connect to the origin on 443. But if you configure HTTPS origin pull to port 80 and the origin's port 80 accepts only plain HTTP, the CDN's TLS handshake will fail. Conversely, sending HTTP to port 443 that only listens for TLS can also result in connection resets, no valid response, or protocol errors.

Before launching a custom port, confirm at least:

CDN支持该回源端口
源站服务正在该端口监听
监听协议与回源协议一致
防火墙允许CDN回源网络访问
证书在该端口正确加载
健康检查使用相同或兼容的协议

A more robust production configuration

For a typical website, you can start with the following configuration:

用户访问协议：HTTP自动跳转HTTPS
CDN回源协议：HTTPS Only
回源端口：443
源站地址：专用源站域名或源站负载均衡地址
回源SNI：源站证书覆盖的域名
回源Host：应用实际识别的业务域名
证书校验：严格验证
源站访问控制：限制CDN回源来源或启用回源认证

If the origin certificate coverswww.example.com, and the web server also useswww.example.comas a virtual host, SNI and Host can both use that domain.

If the origin uses a dedicated domain, you can use:

源站地址：origin.example.net
回源SNI：origin.example.net
回源Host：www.example.com

provided the CDN supports setting SNI and Host separately and the origin certificate coversorigin.example.net.

Do not use “ignore certificate errors” as a long-term configuration. It may temporarily restore origin pull, but it removes origin identity verification, leaving HTTPS with encryption but no reliable authentication.

Validate an HTTPS origin directly with curl

When testing the origin, do not directly access:

curl https://203.0.113.10/

This may fail to send the correct SNI and will validate the certificate by IP, so it cannot accurately simulate a CDN domain origin pull.

If both SNI and Host should bewww.example.com, you can use:

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

--resolveOnly in this request, connectwww.example.com:443to the specified IP, while the domain in the URL is still used for TLS SNI, certificate validation, and HTTP Host. curl's official manual defines--resolveas temporarily setting the connection address for the specified hostname and port.

Focus on:

• Whether the TLS handshake completes successfully;

• The HTTP status code returned;

• Whether certificate validation passes;

• Whether the response comes from the correct site;

• Whether the request appears in the origin logs.

If origin SNI and Host differ, you can simulate them separately:

curl -sS -D - -o /dev/null \
  --resolve origin.example.net:443:203.0.113.10 \
  https://origin.example.net/ \
  -H 'Host: www.example.com'

This command usesorigin.example.netto establish the TLS connection and validate the certificate, then sends in the HTTP requestHost: www.example.com.

Test only origins you manage or are authorized to test. Do not expose real origin IPs, internal domains, cookies, or authentication tokens in public articles, ticket screenshots, or chat logs.

Check SNI and certificate chain with OpenSSL

To inspect the certificate actually returned by the origin, run:

openssl s_client \
  -connect 203.0.113.10:443 \
  -servername origin.example.net \
  -verify_hostname origin.example.net \
  -verify_return_error \
  -showcerts </dev/null

Check the following output:

subject=
issuer=
X509v3 Subject Alternative Name
Verify return code

Normally, the SAN should includeorigin.example.net, the certificate should still be within its validity period, the certificate chain should be complete, and the verification result should be successful.

If you do not add-servername, a server on a shared IP may return the default certificate. This can help confirm what happens when the CDN does not send the correct SNI, but this result alone cannot determine that the origin certificate is misconfigured.

Do not rely oncurl -koropensslignoring verification errors to prove the configuration is fixed. Skipping validation can only be used to determine whether the issue indeed comes from certificate validation; it is not a production fix.

What different test results indicate

Different CDNs do not use exactly the same error codes. For example, some vendors display all origin TLS failures as 502, while others provide separate handshake or certificate error codes. Therefore, do not draw conclusions only from the front-end error page; also check the origin error reason in the CDN console.

Why does a redirect loop occur after enabling HTTPS origin pull?

A common misconfiguration is:

1. The user accesses the CDN over HTTPS;

2. The CDN connects to the origin over HTTP;

3. The origin sees the request as HTTP and redirects to HTTPS;

4. The CDN still pulls from the origin over HTTP;

5. The origin redirects again.

Another case is that the CDN already uses HTTPS origin pull, but the origin application does not correctly recognize the protocol passed by the reverse proxy and still treats the request as HTTP.

When troubleshooting, check:

curl -sS -I https://www.example.com/

ObserveLocationwhether it repeatedly points to the same URL, and check whether the origin application correctly and trustworthily handlesX-Forwarded-Protoor the vendor-provided equivalent request header.

Only forwarding headers from trusted CDNs or reverse proxies should be used for protocol determination. Do not allow arbitrary public clients to forge forwarding headers and influence security redirects or application logic.

How to confirm origin pull is truly recovered after changes

Do not test only the homepage once. Review the following scope:

• Whether the homepage, static assets, and dynamic APIs work normally;

• Whether origin pull succeeds on first access or cache MISS;

• Whether content can still be re-fetched after purging the test object cache;

• Whether different origins and load balancer backends return the same set of certificates;

• Whether HTTP correctly redirects to HTTPS;

• Whether API cookies, authentication headers, and request bodies are passed correctly;

• Whether the CDN console still records TLS or connection errors;

• Whether the Host, protocol determination, and status codes in origin logs match expectations.

You can use CdnChart'swebsite speed test toolto observe status codes and access performance in different regions from the public user path. However, public speed tests cannot directly show the origin SNI and certificate validation results used internally by the CDN. That part still requires the CDN console, origin logs, and targeted commands.

If you have not yet confirmed whether requests actually go through the CDN, you can first useCDN detection toolto help check DNS resolution, nodes, and vendor clues. For the boundaries of certificate chain and public endpoint checks, seeTLS notes in CDN security scoring.

FAQ

User access is already HTTPS; will using HTTP for origin pull affect the browser padlock?

The browser may still show the padlock because it validates the connection from the user to the CDN edge node. However, the CDN-to-origin segment is still plaintext, and the browser does not directly perceive this link. Therefore, a padlock does not mean both end-to-end segments are encrypted.

The origin uses an IP as the origin address; does the certificate need to include this IP?

Not necessarily. The CDN can connect to the origin IP while using a domain as the SNI and certificate validation name. As long as the vendor supports this configuration, the certificate only needs to cover the SNI domain. If the CDN actually validates the certificate by IP, the certificate must include the corresponding IP address identifier, but public certificates and different CDNs have limited support for this; it is usually better to configure an explicit origin domain.

Must SNI and origin Host be the same?

Not necessarily. SNI is used during the TLS handshake for certificate selection and identity verification, while Host is used in the HTTP request after TLS completes for site routing. They can differ, but both the CDN and origin must support this configuration. If the vendor automatically synchronizes them, they cannot be designed as completely independent fields.

The origin has a certificate installed. Why does the CDN still return 502?

“Certificate installed” only means the origin has a TLS configuration; it does not prove the certificate is valid. Expired certificates, SAN mismatches, missing intermediate chains, wrong SNI, a CA not trusted by the CDN, a port not listening, and incompatible TLS versions can all cause origin pull failures. Some CDNs present all these errors uniformly as 502.

Must HTTPS origin pull use port 443?

Not necessarily, but 443 has the best compatibility. Before using 8443 or another port, confirm that the CDN allows that origin port, the origin actually listens with TLS, the firewall permits it, and health checks and business requests use a compatible protocol. Changing the port itself does not increase encryption strength.

Can a self-signed certificate be used for HTTPS origin pull?

Only if the CDN explicitly supports self-signed certificates, private CAs, or certificate pinning and the corresponding trust relationship has been configured. Otherwise, strict validation will fail. Do not maintain compatibility with self-signed certificates by disabling certificate verification long term.

After HTTPS origin pull is configured correctly, is it still necessary to restrict origin access?

Yes. HTTPS encrypts and verifies the connection, but it does not mean the origin has prohibited access that bypasses the CDN. You can protect the origin with CDN origin IP allowlists, origin authentication, vendor-provided authenticated origin pull, or mTLS. When configuring access control, retain management and emergency access paths to avoid making the entire origin unreachable due to changes in the vendor's IP ranges.