mTLS
Mutual TLS between your app and your API — enforced at the edge, issued by CNX's private CA, protecting every call once the app has enrolled.
Mutual TLS verifies both directions on every connection: the app confirms it's talking to your real API, and the API confirms the caller is a legitimate instance of your app — before either side exchanges a single byte of application data.
Two directions
| Direction | What's verified | How |
|---|---|---|
| Server → client | The app confirms it's talking to your API, not an impostor | A CNX CA-issued certificate, presented at whichever edge serves the request — CNX's own CDN/WAF, or an existing CDN if one sits in the path, via its Custom SSL / BYOPKI feature |
| Client → server | The API confirms the caller is a legitimate instance of your app | The edge validates the app-presented certificate against the CNX CA — native on CNX's own CDN/WAF; on a third-party CDN this is typically an Enterprise-tier feature (Cloudflare BYOCA, Akamai Mutual TLS Edge Truststore) |
Enforced at the edge, at the TLS layer
Certificate verification happens before the HTTP request is even parsed — identical whether the connection arrives over QUIC or TCP+TLS (see CDN/WAF). An unauthenticated connection never reaches the schema validator or the application.
A standard pattern in banking APIs
FAPI — the OpenID Foundation's Financial-grade API standard — names mutual TLS (RFC 8705) as one of its standard client-authentication methods for confidential clients. Both major CDN vendors already support it as a supported configuration: Cloudflare's BYOCA and Akamai's Mutual TLS Edge Truststore each accept a private CA for client-certificate validation.
Before enrollment
Enrollment runs through a dedicated endpoint, scoped on the CDN/WAF to do exactly one thing: authenticate a user and establish a session. Nothing else is reachable through it. A successful session there mints the JWT the app uses to request its certificate (see PKI). After enrollment, every call goes to the API, fully protected by mTLS.
Certificate lifecycle
CA configuration runs through the same GitOps change management as the CDN/WAF: certificate lifetimes, the JWS signer trusted for enrollment tokens, and other CA parameters are configurable, reviewed as commits, and deployed the same way. Defaults:
| Client certificate lifetime | 30 days |
| Renewal | At 15–20 days, using the still-valid certificate itself as the renewal credential — no new login required |
| If fully expired | Falls back to the login-gated enrollment flow (see PKI) |