A site can work through Cloudflare while its origin still accepts direct traffic that bypasses the intended edge controls. Authenticated Origin Pulls (AOP) makes Cloudflare present a client certificate on its origin TLS connection. Protection requires the origin to verify and require that certificate, with a trust scope matching the identity you intend to allow.
This guide covers directly proxied origins, shared versus custom AOP credentials, Nginx/Apache trust settings, network controls, testing and rotation. It separates the origin’s server certificate from Cloudflare’s client certificate. Cloudflare Tunnel and client-to-edge mTLS have different connection models; enabling their settings does not automatically combine them into this AOP flow.
Why Direct Origin Access Needs a Policy
A CDN does not automatically close every direct path to the origin. Alternative DNS records, ports, addresses or hostnames may still reach an application without the edge’s controls. Inventory the exposed paths and decide which clients should be accepted. Keeping an origin IP obscure is not an access policy, while a working proxied homepage does not test what the origin would do with a direct request.
An IP allowlist limits network sources and can complement client-certificate verification. Maintain the intended Cloudflare IPv4 and IPv6 ranges and any tightly controlled administrative paths. Those ranges do not identify your particular account. The global shared AOP certificate also proves a Cloudflare network identity rather than your account or zone, so stronger account-specific requirements need a custom credential and appropriately restricted origin trust.
Define the accepted identity before selecting a certificate model. Trusting a CA normally accepts eligible client certificates under that trust, not merely one hostname because its name appears in a configuration comment. A dedicated issuer or supported explicit client-identity constraints can narrow the boundary. Application authorization and permitted HTTP hostnames still need their own checks after TLS succeeds.
AOP Uses Mutual TLS for the Origin Connection
AOP is Cloudflare’s application of mutual TLS to the Cloudflare-to-origin connection, not a separate protocol to which “full mTLS” is later added. Cloudflare presents a client certificate and the origin verifies it. For the other direction, the origin presents a server certificate and Cloudflare must validate it through the intended strict server-authentication configuration.
Global AOP uses a Cloudflare-provided certificate shared across all accounts. Zone-level and per-hostname AOP use a client certificate and private key that you upload. Each level has independent enablement; hostname settings take precedence over zone settings, and zone settings over global. Select by identity requirements rather than site count. Merely uploading a custom certificate does not remove a broader trust path still accepted at the origin.
Client-to-edge mTLS is a different direction: a visitor, service or API client presents a certificate to Cloudflare or Access. Workers can also have a separate outbound mTLS binding. These features do not establish the same origin trust as AOP. Describe which TLS peer presents which certificate at every hop instead of referring to all of them as one interchangeable setting.
Verify the Server and the Client Separately
The origin’s server certificate must be suitable for the actual configured origin name, valid and trusted by Cloudflare. Use Full (strict) for this server-identity check. AOP can operate with Full, but Full alone does not enforce the same certificate validation. Separately, the origin requires and validates Cloudflare’s AOP client certificate against its chosen client-CA trust and acceptance policy.
Asking for a client certificate is not equivalent to validating and requiring one. Optional modes can support a controlled observation stage, but are not final enforcement. Document the origin server certificate/key, AOP client certificate/key and client-CA trust file as distinct assets. Keep their lifetimes, owners and deployment paths clear through migrations and renewal.
Prepare and Enforce Authenticated Origin Pulls
Choose the AOP Scope and Origin TLS Mode
Start with a valid origin server certificate and a verified Full (strict) connection. Then select global, zone-level or per-hostname AOP using Cloudflare’s setup documentation. Prepare the corresponding origin trust before enforcing mandatory client authentication. Global and custom levels have separate settings; confirm which certificate the effective configuration actually presents rather than assuming one dashboard switch controls all levels.
Configure the Origin’s Client-CA Trust
For Nginx, ssl_client_certificate points to trusted PEM CA material for client verification, and ssl_verify_client on requires verification. The official global-AOP PEM is its client-auth trust CA, distinct from Cloudflare Origin CA. In a custom setup, upload the client leaf certificate and private key to Cloudflare and install appropriate issuing-CA trust at the origin. Do not treat a leaf and a CA bundle as arbitrary substitutes. Apache uses SSLCACertificateFile and SSLVerifyClient require in the relevant server or vhost scope.
Cloudflare receives the origin server certificate; it is not the AOP client credential Cloudflare presents. That server certificate may be issued by a public CA or Cloudflare Origin CA. Match the actual configured origin SNI/target and vhost: supported Origin Rules or load-balancer settings can override Host or SNI, so the origin name is not unconditionally identical to the public hostname. Check all fallback and default vhosts for consistent access behavior.
Apply Network Restrictions to Every Origin Path
On a public VPS or other direct origin, network filtering and certificate verification provide complementary controls. Cover all intended listeners and both address families, and preserve only explicitly authorized monitoring or administration paths. The VPS security guide provides related host controls. A firewall rejection alone does not prove that mTLS would reject a client allowed to reach the TLS listener.
Server Certificates and Renewal Responsibilities
Cloudflare Origin CA certificates are server certificates intended for the Cloudflare-origin leg and are not normally trusted by browsers. Other clients can trust them if explicitly configured with the appropriate CA and hostname verification; “only Cloudflare can ever trust them” is too absolute. A public server certificate may suit broader trust needs, but neither server-certificate choice grants access through a firewall or mandatory client authentication.
Direct debugging or monitoring still requires an authorized network path and a valid client credential accepted by the origin, as well as server-certificate trust. Do not assume a browser-trusted server chain bypasses AOP. Use a separately designed restricted monitoring path where necessary. The SaaS DNS-01 certificate guide concerns server-certificate automation; it does not automatically supply an AOP client credential or monitoring exception.
Before enforcement, inventory the certificate directions, trusted issuers and every origin environment. Test accepted traffic and deliberate rejection with the correct network and server-trust prerequisites. Record deployment and expiry responsibilities. A custom certificate change incompatible with origin trust can interrupt requests, so stage trust changes and inspect fresh connections before removing the prior valid path.
With custom zone-level or per-hostname AOP, you supply the client leaf and private key; Cloudflare does not simply issue a per-domain client identity when you toggle the feature. The origin must trust the appropriate issuer and enforce the intended scope. A dedicated AOP issuer can help avoid accepting unrelated clients from a broadly used CA. Remove unneeded global/shared trust if the objective is to accept only the custom identity.
Cloudflare’s client-certificate documentation also describes mTLS for application security, API clients and Access at the edge. Those clients authenticate to Cloudflare, whereas the AOP client is Cloudflare connecting to the origin. Keep the two certificate stores and policies separate. Neither automatically authorizes a logged-in user to every application resource.
Test Both Accepted and Rejected Connections
A direct curl test using --resolve can preserve the hostname while connecting to an origin IP. To isolate mTLS, the test source must be allowed to reach the listener and correctly trust the origin server certificate. A timeout does not prove client-certificate enforcement; an untrusted Origin CA chain can fail before that check. On a controlled allowed path, verify rejection without a client certificate and with an untrusted one. Also confirm a real origin fetch through the intended Cloudflare configuration succeeds, using origin logs rather than a cached edge response.
Nginx $ssl_client_verify reports SUCCESS, FAILED with a reason, or NONE when no certificate was supplied. Correlate it with the actual hostname, connection and origin response. Review the expected issuer or other supported identity details during rollout without logging private keys. Verification success under a broad shared CA is not evidence that the request used your intended custom identity.
Cloudflare 525 indicates a failed edge-origin TLS handshake; in the ordinary proxy flow, 526 indicates that Cloudflare cannot validate the origin’s server SSL certificate. Neither is the universal response for every rejected AOP client. An origin may return an HTTP error or close the TLS connection. Correlate timestamps and both endpoints’ logs, and determine which peer rejected which certificate before changing trust.
Measure Performance and Keep Cache Rules Separate
Client-certificate verification adds handshake work. Its measured effect depends on connection reuse, TLS settings, traffic and origin load; it is not guaranteed to be negligible. Measure handshake frequency, latency and errors on requests that actually reach the origin. Connection reuse can change the cost profile, but performance tuning must preserve verification and the intended identity boundary.
The stale-while-revalidate and stale-if-error guide describes cache behavior with separate correctness and privacy requirements. AOP does not make personalized responses safe for shared caching or authorize stale delivery in every context. Configure cache keys, response directives and tenant separation for the application independently of origin TLS authentication.
Cloudflare Tunnel and Direct Proxy Origins
Cloudflare’s current documentation explicitly states that AOP is not compatible with origins connected through Cloudflare Tunnel; AOP settings have no effect on those hostnames. Tunnel uses outbound connector connections and connector credentials. Any TLS verification between cloudflared and the local service is a separately configured hop. Do not describe Tunnel plus AOP as automatically adding another origin-authentication layer.
For direct public origins, maintain appropriate network restrictions and AOP trust. For Tunnel origins, assess connector access, local-service protection and any remaining public listener separately. A tunnel does not itself close another exposed origin port. Access mTLS protects configured user/service access to the edge and should not be confused with AOP on the connector path.
Protect Staging and Alternative Hostnames
A staging service can remain directly reachable even when its main hostname is proxied. Inventory alternative names, IPs and ports rather than assuming the production AOP settings cover it. Apply the intended identity and application-access policy to that environment, then test each relevant route. This is an example failure scenario, not a claim that a specific past incident was solved with one toggle.
The SSL/TLS maintenance guide covers related certificate lifecycle checks. Staging and production can require distinct trust boundaries, so copying one broad CA list everywhere may be inappropriate. Track which environment accepts which client identity, and verify a new deployment has not introduced an unprotected default listener.
Diagnose Certificate and Routing Failures
Check the exact AOP trust file, server certificate and selected vhost. The official global-AOP CA file is not the Origin CA server certificate. Nginx ssl_trusted_certificate also defines trusted CAs but does not send their list to clients; verification still needs to be required. Ensure the client chain and configured verification depth fit. Apache likewise needs a suitable CA bundle and mandatory verification, not optional_no_ca.
Distinguish deliberate rejection from accidental breakage by checking the expected result on each test path. A server-chain trust failure on a test laptop, a firewall block and an origin rejecting a missing AOP client certificate are different observations. TLS alerts such as unknown ca must be interpreted from the sending peer’s direction. Avoid assuming every successful lockout has one specific HTTP code or diagnostic string.
Trust Proxy Metadata Only on the Intended Path
CF-Connecting-IP and CF-Ray provide useful proxy metadata and correlation, not independent authorization. Read them only under the intended trusted-proxy policy, and account for Workers and other intermediaries that can alter header behavior. Do not blindly trust the first X-Forwarded-For value. Record the actual network peer separately and verify configured Host/SNI overrides rather than assuming all upstreams preserve them unchanged.
During rollout, correlate client verification, actual requested hostname, selected origin and response status. A request ID helps join logs but does not prove user identity. Keep enough monitoring to detect renewal or trust failures after the rollout, with controlled retention and no private-key exposure. HTTP/2 or HTTP/3 on the visitor connection does not establish what protocol or headers the separate origin connection uses.
Roll Out AOP in Verified Stages
Prepare the origin server certificate and Full (strict) first. Install the selected AOP CA trust, optionally observe client certificates briefly in a controlled stage, enable the correct AOP level, and confirm the expected credential arrives. Then require verification and test no-certificate, untrusted-certificate and expected Cloudflare paths. Validate every origin listener and network restriction, and confirm success with fresh origin requests. Document expiry, rotation and recovery ownership before declaring completion.
If an intermediate load balancer terminates TLS, AOP authenticates at that terminator. A separate connection to the application needs its own appropriate verification and authorization; the first handshake does not automatically secure every downstream hop. Check for alternate access to the application and maintain explicit trusted-proxy boundaries for forwarded metadata.
Rotate Client Certificates and CA Trust
For a planned client-CA change, stage the required new trust while retaining the old valid path, validate the configuration, switch to the new client credential, and observe fresh successful connections before removing obsolete trust. Leaf renewal under the same issuer can have a different sequence. The SSL/TLS maintenance guide covers related lifecycle practice. A symlink swap or reload alone does not prove the new files were accepted; test the result. A compromised key requires replacement and removal of its authority, not rollback to that exposed key.
Use Cloudflare’s AOP documentation for client-certificate scope and enablement, and Origin CA documentation for the origin server-certificate role. Keep the selected configuration levels and trust paths visible in your records. Product settings and support can change, so recheck the relevant implementation when migrating between direct origins and Tunnel.
Related Certificate and Cache Workflows
DNS changes, certificate distribution and caching are related operational workflows with separate acceptance criteria. A new origin target must satisfy the same identity and network policy; cached traffic can conceal an origin failure during a superficial test. Similarly, authenticated origin transport does not justify broader caching of private content. Test each relevant layer with requests that actually exercise it.
Cache behavior with stale responses explains freshness and error handling. SaaS custom-domain SSL automation concerns tenant/domain and server-certificate lifecycles. SSL/TLS maintenance covers renewal and deployment checks. Use each within its scope instead of assuming AOP automatically configures those workflows.
Define the Acceptance Boundary
The desired boundary has an explicitly trusted server at the Cloudflare side and an explicitly accepted client at the origin side, plus the intended network and application controls. Full (strict) and mandatory AOP verification serve those different certificate directions. Global shared trust is not account-specific; custom identity works only when the origin’s complete acceptance policy is appropriately restricted.
Completion Criteria for Origin Protection
Consider the direct-origin rollout complete when the intended Cloudflare path reaches the application, rejected clients fail for the expected reason, all relevant listeners enforce the policy and certificate changes are monitored. Validate hostname and environment scope as well as a successful chain. Keep Tunnel, Access and downstream service authentication distinct from AOP rather than presenting them as interchangeable layers.
Maintain the trust files, active credentials, actual origin target names and renewal responsibilities after deployment. Recheck the same acceptance and rejection paths after DNS, proxy, certificate or network changes. Preserve enough evidence to identify the failing hop without weakening server validation or making client certificates optional as a routine workaround.
