Client Certificate

Overview

A client certificate is an X.509 digital certificate presented by a client during a TLS connection so the server can authenticate the calling system, device, or organization. A compromise response for Client Certificate should support rapid revocation, replacement, affected-client identification, and review of prior use.

The main risks include expired or revoked certificates, incorrect hostname or identity mapping, leaked private keys, weak enrollment controls, and outages caused by uncoordinated rotation. It is commonly used in mutual TLS for machine-to-machine payment APIs. For Client Certificate, secrets and tokens should remain outside browser bundles, URLs, ordinary logs, and unprotected configuration.

In production, teams should define ownership and apply trusted certificate authorities, certificate-chain validation, private-key protection, rotation, revocation checks, and environment-specific trust stores. It is different from an API key because possession of the private key is proven during the TLS handshake rather than by sending a reusable secret in an application header.

Useful measures include handshake failure rate, certificate age, days to expiry, revocation-check failures, and successful rotation rate. Client Certificate is closely connected to Payment API Authentication, Dedicated RPC Endpoint, and Live Mode. The Client Certificate boundary should identify the principal, credential or key, permitted audience, scope, lifetime, and revocation path.

The Client Certificate recovery process should restore access without bypassing the original identity and authorization controls. Least-privilege configuration for Client Certificate should be verified against the operations used by each environment and consuming service.

Changes to Client Certificate should preserve overlap or recovery where required while preventing old credentials from remaining active indefinitely.