PKI
CNX operates a dedicated certificate authority for mobile app and API traffic — rooted in Cambodian jurisdiction, and in hardware, from root to edge.
CNX operates a root CA for private trust — a tenant-isolated certificate authority, rooted in hardware, operating under Cambodian jurisdiction.
Private trust is a specific kind of relationship: a mobile app and its own backend API already know each other before the first request is ever made. Every connection between them is verified cryptographically against a CA built for exactly that relationship.
Jurisdiction
The root sits under Cambodian law. Cambodian courts and Cambodian regulators have standing to act on it.
PKI infrastructure
The root runs across networked hardware security modules — keys synchronized between them, no single point of hardware failure. Server and edge certificates are issued and renewed automatically via ACME (RFC 8555). Client certificates go through a login-gated enrollment: your own backend mints a signed JWT after a user authenticates, the app presents it once to request a certificate, and the CA issues against a signing key it already trusts.
CA configuration — certificate lifetimes, the JWS signer trusted for enrollment tokens, and other CA parameters — runs through the same GitOps change management as the CDN/WAF, reviewed as commits and deployed the same way.
Issuance and renewal counts, certificate expiry windows, and CA health are exported to Prometheus and available in Grafana, using your own SSO.
Standards
X.509 certificates per RFC 5280. Server and edge certificate issuance and renewal via ACME (RFC 8555). Client-certificate bootstrap tokens are signed JWTs (RFC 7519), verified as JWS (RFC 7515) against a JWK (RFC 7517). HSM key operations use PKCS #11 (OASIS). Site intermediate keys are TPM-backed per the TCG TPM 2.0 and TSS 2.0 specifications.
Hardware, root to edge
Every certificate in the CNX service chain is hardware-backed, root through edge. The root key lives in a hardware security module. Each site's intermediate key is generated and held in a TPM, never leaving the hardware it was created on. The leaf certificates presented by CNX's own CDN/WAF edge nodes are themselves TPM-backed: the private key for a server certificate never exists in software, on any node, at any point in the chain.
Certificates that don't need an app update to rotate
Public certificate lifetimes are shrinking on a fixed, published schedule. The CA/Browser Forum's Ballot SC-081v3 cuts every publicly-trusted certificate to 200 days from March 2026, 100 days from March 2027, and 47 days by March 2029. An app pinned to a literal leaf certificate is headed toward needing an app-store release on every renewal — untenable at a 47-day cadence. CNX's CA is private, outside that schedule entirely, and the app pins to the CA's SPKI — its public key — not the leaf. Leaf certificates rotate underneath, as often as needed, without ever touching the pin.
Banks and financial institutions
NBC TCRMG requires institutions to demonstrate control over where their data flows and who has access to it, including the keys that authenticate it. A dedicated CA, rooted in hardware inside Cambodia, gives an institution a trust anchor it can point to directly.
Trust hierarchy
Tenant-isolated: your CA is its own domain within CNX's HSM infrastructure, with its own root. The root key is reached only for the rare event of issuing or re-issuing a PoP's intermediate — routine, day-to-day certificate issuance never touches it.
Where this shows up
This CA is what makes mutual TLS possible: the CDN/WAF enforces the identity check on every connection, using certificates this CA issues. See mTLS for how the two directions — the app verifying the server, the server verifying the app — work together.