Vault’s PKI secrets engine can issue short-lived TLS certificates that are automatically revoked when they expire, simplifying certificate lifecycle management and enhancing security by reducing the window of opportunity for compromised certificates.

Let’s see Vault’s PKI engine in action. We’ll start by configuring a basic PKI backend and then issuing a certificate.

First, enable the PKI secrets engine at the pki path:

vault secrets enable pki

This creates a default internal CA for the PKI backend. Now, we need to configure the CA certificate and its TTL. For this example, let’s set the CA’s certificate TTL to 8760 hours (1 year).

vault write pki/config \
    max_lease_ttl="8760h" \
    default_lease_ttl="720h"

Next, we’ll generate a root CA certificate and key. This certificate will be self-signed and will be used to sign all subsequent certificates issued by this PKI backend.

vault write pki/root \
    common_name="my-vault-root-ca" \
    ttl="8760h"

Now that we have a root CA, we can configure a role. A role defines a set of permissions and configurations for certificates issued by this PKI backend. Let’s create a role named my-app-role that allows issuing certificates with a maximum TTL of 24 hours.

vault write pki/roles/my-app-role \
    max_ttl="24h" \
    allowed_domains="myapp.example.com,localhost" \
    allow_subdomains=true \
    key_type="rsa" \
    key_bits="2048"

With the PKI backend configured and a role defined, we can now issue a certificate. We’ll request a certificate for myapp.example.com using the my-app-role.

vault read pki/issue/my-app-role \
    common_name="myapp.example.com" \
    ttl="1h"

The output will contain the certificate chain (certificate), the private key (private_key), and other metadata. This certificate can be used by your application.

{
  "request_id": "...",
  "lease_id": "pki_issue/my-app-role/...",
  "lease_duration": 3600,
  "renewable": true,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "client_cert": "...",
    "issuing_ca": "...\n-----END CERTIFICATE-----",
    "private_key": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----",
    "private_key_type": "rsa",
    "serial_number": "..."
  }
}

The lease_duration in the output corresponds to the ttl we specified when issuing the certificate (1 hour in this case). Vault automatically manages the revocation of this certificate once its lease expires, meaning you don’t need to manually track and revoke expired certificates. This is a critical security feature, as it minimizes the attack surface by ensuring that only valid, unexpired certificates are in use.

When you issue a certificate, Vault associates a lease with it. This lease has a specific duration (TTL). As long as the lease is active, the certificate is considered valid. Once the lease expires, Vault automatically marks the certificate as revoked in its internal CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) responder, effectively disabling it. This automatic revocation process is fundamental to the security benefits of using Vault for short-lived certificates.

The allowed_domains and allow_subdomains parameters in the role definition are crucial for controlling which hostnames or FQDNs can be included in the certificate’s Subject Alternative Name (SAN) field. This prevents the issuance of certificates for unintended domains.

The key_type and key_bits parameters allow you to specify the type and strength of the private key generated for the certificate, adhering to your organization’s security policies.

While Vault handles automatic revocation upon lease expiry, understanding how to manually revoke a certificate can be useful for immediate invalidation. You can do this using the pki/revoke endpoint, providing the serial number of the certificate:

vault write pki/revoke \
    serial_number="<serial_number_from_issued_cert>"

This immediately revokes the certificate, even if its lease has not yet expired. This is a powerful tool for responding to potential compromises or policy violations.

The concept of "leases" in Vault is central to managing secrets, including certificates. When a certificate is issued, it’s not just handed over; it’s leased to the client for a specific duration. This lease is what Vault uses to track the certificate’s validity and to perform automatic revocation. If your application needs to renew a certificate, it must do so before the lease expires, effectively requesting a new lease for a potentially new certificate.

The next step in managing your PKI infrastructure with Vault is often integrating it with your services for automatic certificate rotation, ensuring continuous availability and security without manual intervention.

Want structured learning?

Take the full Tls-ssl course →