Vault Cert Auth in Practice and on the Exam: Secure Login with Client Certificates

Vault's cert auth method lets a client log in by presenting a client certificate and receive a token bound to a policy. The certificate is presented over mTLS, and the auth method handles the mapping between certificates and policies.

This article gives you a fast overview of the minimal setup aligned with official behavior, the key design points, how to think about revocation and rotation, and the spots that are easily confused on the exam.

Core Concepts and What the Exam Tests

With Vault's cert auth, the client presents a TLS client certificate to /auth/cert/login, Vault validates the certificate, and a policy-bound token is issued. Authentication itself is handled by the cert auth method, while transport encryption and server authentication are handled by the usual TLS configuration.

Certificate trust is rooted either in the specific client certificate registered with the cert auth method, or in the issuing CA certificate. When you trust at the CA level, narrowing the allowed range with attributes such as CN, SAN, and OU becomes essential (attribute names and detailed parameters can vary by version, so check the documentation when you deploy).

On the exam, the flow of "client certificate presented over mTLS → verified and mapped by Vault's cert auth method → token issued" is tested frequently, along with when to choose cert vs. AppRole, Kubernetes, or OIDC.

• Login is POST /auth/cert/login. On the CLI: vault login -method=cert
• The certificate is presented during the TLS handshake. Vault validates the certificate bound to the connection inside the auth method
• Mapping is "certificate (or CA) → policy". Narrow the scope with attributes when needed
• You receive a normal Vault token. TTL and re-authentication strategy follow standard token operations

Minimal login example (CLI and curl)

export VAULT_ADDR=https://vault.example.com:8200
export VAULT_CACERT=/path/to/vault-ca.pem
export VAULT_CLIENT_CERT=/path/to/client.pem
export VAULT_CLIENT_KEY=/path/to/client.key

# Login via CLI (cert auth)
vault login -method=cert

# Direct HTTP (mTLS required)
curl --cacert /path/to/vault-ca.pem \
     --cert /path/to/client.pem --key /path/to/client.key \
     https://vault.example.com:8200/v1/auth/cert/login

Setup: Minimal Configuration Steps

The minimal configuration is three steps: 1) enable the auth method, 2) register the client certificate or CA (tied to a policy), 3) log in over mTLS. Start in dev/test, then for production narrow the allowed range with attributes and design token TTL / Max TTL / Period.

Pinning to a specific certificate makes loss and revocation response explicit. Trusting at the CA level is more convenient but makes revocation propagation and attribute scope design much more important.

• Enable auth/cert: vault auth enable cert
• Create the mapping: register the certificate or CA at auth/cert/certs/<name> and attach a policy
• Access /auth/cert/login over mTLS to obtain a token

Minimal configuration example (both certificate pinning and CA trust patterns)

# Enable the auth method
vault auth enable cert

# Pattern A: pin a specific client certificate (register the certificate itself)
# client.pem is the public-key certificate (PEM). Attach the dev-app policy.
auth_path="auth/cert/certs/dev-client"
vault write ${auth_path} \
  certificate=@/path/to/client.pem \
  policies="dev-app" \
  display_name="dev-client"

# Pattern B: trust the issuing CA (accept any client certificate signed by the CA)
auth_path="auth/cert/certs/ci-clients-ca"
vault write ${auth_path} \
  certificate=@/path/to/ci-clients-ca.pem \
  policies="ci-build" \
  display_name="ci-clients"
# Add options to narrow the allowed range via attributes such as CN/SAN/OU (names vary by Vault version)
# e.g. allowed_common_names=..., allowed_dns_sans=..., allowed_organizational_units=...

# Login (specify the entry explicitly)
vault login -method=cert name=dev-client

Architecture and Flow (mTLS and Policy Mapping)

The client connects to Vault over mTLS and presents the client certificate during the TLS handshake. Vault secures the traffic with server TLS, and the cert auth method inspects the certificate associated with the connection, matching it against pre-registered mappings.

A token bearing the policies tied to the matched entry is issued and used for subsequent Vault API calls.

• mTLS handshake → certificate verified by the cert auth method → mapping matched → token issued
• If multiple entries might match, narrow it down with the name parameter
• The issued token's TTL / Max TTL / Period are important design parameters

Flow of mTLS and the cert auth method

Client                         Vault
  |    TLS ClientHello             |
  |------------------------------>|
  |  presents client certificate   |
  |<------------------------------|
  |      TLS handshake complete    |
  |                                |
  |  POST /auth/cert/login (mTLS)  |
  |------------------------------>|
  |  verify cert → match mapping  |
  |  issue token with policies     |
  |<------------------------------|
  |    use token for secrets/API   |
  |------------------------------>|

Using the token after login (example: reading from KV)

# Set the token from login into an environment variable
export VAULT_TOKEN="s.xxxxx"

# Read a KV v2 secret
auth_header="X-Vault-Token: ${VAULT_TOKEN}"
curl --cacert /path/to/vault-ca.pem \
     -H "${auth_header}" \
     https://vault.example.com:8200/v1/secret/data/app/config

Scoping and Security Design Essentials

Registering a CA to accept a wide range is operationally easy, but insufficient revocation checks or attribute scoping become risks. Strictly limit what is allowed with CN, SAN (DNS/URI/Email), and organization/unit (O/OU), and keep policies at least privilege.

Vault's cert auth decides based on whether the presented certificate is consistent with a pre-registered entry. It is safer not to assume external CRL/OCSP will be consulted automatically. Aim for fast revocation by issuing short-lived client certificates, pinning, and deleting mappings.

By leveraging token TTL / Max TTL / Period, you can keep access short-lived even if the certificate is long-lived. This is especially effective for machine-centric use cases rather than human authentication.

• With CA trust, tighten via attributes (CN/SAN/OU and so on)
• Achieve immediate revocation through short-lived certs + pinning + mapping deletion
• Control the effective access window with token TTL / Period

Example of narrowing the allowed range via attributes (conceptual)

# Register the CA but restrict CN/SAN/OU (verify actual parameter names against your Vault version)
vault write auth/cert/certs/ci-clients-ca \
  certificate=@/path/to/ci-clients-ca.pem \
  policies="ci-build,artifact-read" \
  display_name="ci-clients" \
  # The following is conceptual (verify the names of allowed_* / required_* against your Vault)
  allowed_common_names="ci-*,build-*" \
  allowed_dns_sans="*.corp.local" \
  allowed_organizational_units="CI,Build"

Operations, Rotation, and Troubleshooting

Think about rotation in two layers: the certificate (the client key material) and the Vault token. Automate short-lived issuance and renewal for the certificate, and shrink the blast radius on the Vault side with token TTL/Period and least-privilege policies.

Triage connection failures across two layers: TLS and the auth method. Rejections at TLS are usually caused by missing certificate presentation, broken chains, or key mismatch; rejections at the auth method usually mean an unregistered mapping or an attribute mismatch.

• List entries: vault list auth/cert/certs
• Inspect details: vault read auth/cert/certs/<name>
• Revoke: vault delete auth/cert/certs/<name> (effective for instant access shutoff)
• TLS triage: openssl s_client and curl with --cert/--key/--cacert
• Logs: check the Vault server log and the response body of HTTP 400/403 responses

Inspection command set

# List all registered entries
vault list auth/cert/certs

# Inspect a single entry
vault read auth/cert/certs/dev-client

# Immediate revocation (delete the mapping)
vault delete auth/cert/certs/dev-client

# Verify the TLS handshake (check certificate presentation)
openssl s_client -connect vault.example.com:8200 \
  -cert /path/to/client.pem -key /path/to/client.key \
  -CAfile /path/to/vault-ca.pem -quiet

Spots Easily Confused on the Associate Exam

Cert auth issues "client certificate → policy-bound token". TLS itself (its lifetime and server certificate) is managed separately, and exam choices often try to conflate these.

AppRole fits environments where you can distribute and manage a secret (SecretID); cert fits machine-to-machine traffic with PKI and mTLS already in place. For human logins, OIDC/SAML are the appropriate choice — a framing the exam asks about often.

• The login endpoint for cert auth is /auth/cert/login. TLS only handles transport and server authentication
• With CA trust, attribute-scoped narrowing is mandatory (accepting too much is a penalty point)
• What you receive is a Vault token. Subsequent authorization is decided by policy

One-liner to test your understanding

# Specify name to log in via a specific entry (avoid conflicts)
vault login -method=cert name=ci-clients-ca

Check with a Question

Frequently Asked Questions