Track edge and origin certificates separately when a CDN or security proxy handles HTTPS. The edge certificate serves visitors; the origin certificate protects the connection from the proxy to the hosting server under the provider's supported secure configuration.
01 Configure both sides
- Draw a simple inventory of the public hostname, proxy service, origin hostname or address and the administrator responsible for each certificate.
- Confirm that the public edge certificate covers every customer-facing name. A CDN's default service hostname does not automatically cover your custom domain.
- Configure a valid origin certificate with the name and trust requirements expected by the proxy. In Cloudflare, for example, Full (strict) validates the origin certificate's validity, name and accepted issuer.
- Verify that the origin serves the intended site when the proxy uses the correct hostname. Check the relevant server binding and supported network access.
- Test the public path, redirects and application-generated URLs. Capture proxy errors separately from browser certificate warnings.
- Monitor renewals for both certificates and recheck the origin configuration after a hosting migration or firewall change.
Common questions
Can an origin-only certificate be used directly for visitors?
Some provider-specific origin certificates are trusted by the proxy but not ordinary browsers. Before bypassing a proxy, provide a certificate trusted by the clients that will connect directly.
Why is the public certificate new but the website still fails?
The proxy can fail its connection to an expired, mismatched or unreachable origin. Inspect that connection rather than repeatedly renewing the edge certificate.
Should I weaken certificate verification to restore service?
Repair the origin certificate and routing. Choose the provider's supported configuration that validates the origin, and document any tightly controlled temporary incident action with an expiry.