Module cert 

Client-certificate authentication (Phase 3.4 PG parity).

Validates mTLS client certificates against a trust store and extracts the user identity + role from the cert’s subject / extensions. Used by TLS-terminated listeners (wire, gRPC, PG wire) to authenticate callers without sending passwords.

Identity mapping

Two mapping modes, configured per deployment:

• CommonName — take the subject CN (“CN=alice”) as the RedDB username. Matches PG’s cert auth default. Simplest option but conflates identity with naming.
• SanRfc822Name — take the first rfc822Name (email) SAN entry as the username. Works well with corporate PKIs that encode email in the cert subject alternative name.

Additional extension-based mapping (custom OIDs for role tags) lives behind CertAuthConfig::role_oid — when set, the validator extracts the role string from that OID; otherwise the role defaults to CertAuthConfig::default_role.

Trust store

For Phase 3.4 the trust store is a file path holding one or more PEM-encoded CA certificates. Any leaf cert signed by any of those CAs validates. Chain verification delegates to the underlying TLS stack (rustls) — we only consume the already-validated certificate at the handler layer.

Structs

CertAuthConfig

Per-deployment cert-auth policy. Enabled on a per-listener basis (the TLS listeners inject this into their accept loop).

CertAuthenticator

Stateless validator. Holds the config + lookup closure; TLS listeners wrap it in an Arc and call validate on every accepted connection.

CertIdentity

Parsed identity extracted from a validated client certificate.

ParsedClientCert

Subset of the cert surface the validator consumes. TLS listeners construct this from their rustls::Certificate payload via an ASN.1 parser (x509-parser or similar); we model the fields we actually look at so tests don’t need a real PEM.

Enums

CertAuthError

Errors raised while validating a client certificate.

CertIdentityMode

How to derive the RedDB username from a client certificate.