HTTPS and CDN Combination: Should Origin Pull Use HTTPS and How to Configure It Correctly

After integrating CDN, HTTPS becomes two segments: one from the user to the CDN edge node, and another from the CDN back to your origin server. The certificates for these two segments are independent and can be configured separately.

The most common confusion is: “Should origin pull also use HTTPS?” and “Are the edge certificate and the origin certificate the same?”

Two Connection Segments

Key Concept: These two certificates are not the same, nor do they need to be.

• Users see the certificate configured on the CDN at the edge.
• What users care about—validity period and chain integrity—refers to the edge certificate.
• However, if the origin pull segment uses HTTPS, the origin server’s certificate must also be valid; otherwise, origin pull will fail.

Should Origin Pull Use HTTPS?

Recommendation: Use HTTPS for origin pull as well. The reason is not just encryption, but to avoid issues caused by protocol inconsistencies—if the origin server redirects HTTP to HTTPS, using HTTP for origin pull may result in a 301 redirect, potentially causing origin pull failures or loops.

# Check the behavior of the origin server under HTTP (simulating CDN origin pull)
curl -I -H 'Host: example.com' http://OriginServerIP/
# If it returns a 301 redirect to https, and the origin pull protocol is set to HTTP, problems will occur

Requirements for the Origin Server

When using HTTPS for origin pull, the origin server’s certificate must:

• Be valid and not expired
• Have a complete chain (fullchain)
• Match the domain name (the origin pull Host must match the certificate SAN)

# ① Check if the origin server's chain is complete (Note: CDN nodes usually do not complete the chain)
openssl s_client -connect OriginServerIP:443 -servername example.com 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

# ② Simulate CDN origin pull (access origin with Host header)
curl -I -H 'Host: example.com' https://OriginServerIP/

# ③ Confirm that the origin pull Host configuration matches the certificate
openssl s_client -connect OriginServerIP:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

Self-Signed Certificates for Origin Pull

In some scenarios, the origin server can use a self-signed certificate (select “Do not verify origin certificate” on the CDN side). This saves certificate management effort but loses verification of the origin server’s identity.

How to Configure the Edge Certificate

Upload the certificate when configuring the domain in the CDN console. Key points:

• Must be fullchain (users will not complete the chain themselves)
• Private key must match the certificate
• Update before expiration (and monitor it)

# Verify the certificate seen by users after configuration
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -dates -issuer

# Chain integrity (from user perspective, must return 0)
openssl s_client -connect example.com:443 -servername example.com 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

Protocol Configuration and Redirects

# Origin redirect rules should avoid affecting origin pull
# Recommendation: Do not force redirect requests from CDN on the origin, or use HTTPS directly for origin pull

Expiration Monitoring Must Cover Both Ends

# ① Certificate seen by users (Edge)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -enddate

# ② Origin server certificate (if origin pull uses HTTPS)
openssl s_client -connect OriginServerIP:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -enddate
# Note: Direct connection to the origin may be blocked by security groups (only allowing CDN); test from an allowed source

The most easily overlooked part is the origin certificate. Since users cannot see it, expiration leads to origin pull failure—manifesting as “edge works normally but content cannot be retrieved”.

Decision Tree

CDN + HTTPS
├─ Two-segment certificates are independent
│  ├─ Edge: Configured on CDN, visible to users
│  └─ Origin: Only needed if origin pull uses HTTPS
├─ Origin Pull Protocol
│  ├─ Origin forces HTTPS → Origin pull must also use HTTPS (otherwise 301 loop)
│  └─ Recommended to unify on HTTPS
├─ Origin Requirements (when origin pull uses HTTPS)
│  ├─ Valid certificate + Complete chain (fullchain)
│  └─ Origin pull Host matches certificate SAN
├─ Edge Requirements
│  └─ Fullchain, users will not complete it themselves
└─ Monitoring
   ├─ Edge certificate expiration (Visible to users, easy to remember)
   └─ Origin certificate expiration (Easily overlooked, but affects origin pull)

Scenario Analysis: After Enabling Acceleration, the Origin Certificate Exposes the Real Address

Phenomenon: The site has integrated acceleration services, and external access works normally.
However, after some time, it is discovered that accessing the origin address directly (bypassing acceleration nodes) still opens the site, and the origin’s own certificate is visible.

1. First, confirm what this implies →
   Once the origin address is directly accessible, the hiding function of the acceleration service is lost,
   and probes/direct connections targeting the origin bypass all pre-processing policies.
2. Check if the origin restricts access sources →
   The origin has no restrictions on access sources; any location can connect directly.
3. On the origin side, only accept requests from acceleration nodes →
   Restrict sources to the IP ranges provided by the acceleration service, or use agreed-upon validation headers.
4. Confirm how to configure the origin certificate →
   This segment can also be encrypted, and the origin needs a usable certificate to complete the handshake;
   Self-signed certificates are acceptable here because the verifier is only the acceleration node.
5. Verify consistency of origin pull protocol settings →
   Mismatched settings (one end encrypted, the other plaintext) cause handshake failures,
   which manifest as intermittent errors.
6. Verify externally whether the origin can still be accessed directly →
   Request the origin address without going through acceleration to confirm it is rejected.

# Bypass acceleration and request the origin directly (should be rejected)
curl -sS -o /dev/null -w '%{http_code}n' -H 'Host: example.com' https://OriginServerIP/

# See whose certificate is obtained during direct access
echo | openssl s_client -connect OriginServerIP:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -subject -dates

# Compare response header differences between going through acceleration and direct connection
curl -sSI https://example.com/ | head -8
curl -sSI -H 'Host: example.com' https://OriginServerIP/ | head -8

# Restrict sources on the origin side (example)
# nginx: allow AccelerationNodeIPRange; deny all;

Root Cause: Only “integration availability” was achieved, not “unavailability upon bypass”.
If the origin address is directly accessible, all pre-processing policies of the acceleration layer can be skipped.

Two key takeaways:

• After enabling acceleration, you must do one thing: Make the origin accept requests ONLY from acceleration nodes.
  Otherwise, hiding, rate limiting, and protection can all be bypassed via direct connection.
• Origin pull protocol settings on both ends must be consistent.
  One end encrypted and the other plaintext causes handshake failures, manifesting as intermittent errors, which are easily misdiagnosed as application issues.

8 Common Pitfalls

1. Assuming edge and origin use the same certificate: They are two separate certificates.
2. Only monitoring the edge certificate: Origin expiration causes origin pull failure.
3. Origin Pull HTTP but Origin Forces HTTPS: 301 Loop.
4. Using cert instead of fullchain on origin: Origin pull handshake failure.
5. Mismatch between origin pull Host and certificate: Certificate alerts.
6. Failure to update edge certificate upon expiration: Users see alerts directly.
7. Not verifying the chain from the user’s perspective: Must use -verify_return_error.
8. Changing origin configuration without verifying origin pull: Must simulate origin pull requests for testing.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and peers, provided solely for reference of real feedback, not fictional tickets from this site):

a****8 Rating: 5.0 2025-08-22 14:43 r****8 Rating: 5.0 2025-05-22 15:34 t****c Rating: 5.0 2025-04-18 13:58 Cai****Kang Rating: 5.0 2024-08-31 12:05 2****2 Rating: 5.0 2024-02-21 11:08

n****6 Rating: 5.0 2026-08-28 17:55 n****6 Rating: 3.7 2026-08-28 15:37 Tai****Si Rating: 5.0 2026-08-08 09:29 b****4 Rating: 5.0 2024-07-25 10:44 5****3 Rating: 5.0 2024-06-12 15:44

z****j Rating: 5.0 2026-08-04 14:44 z****j Rating: 5.0 2025-08-08 10:52 z****j Rating: 5.0 2024-08-08 15:08