scottk/vault
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/vault.git synced 2026-01-11 14:35:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

backport of commit 5fd3c6db47 (#17937)

Browse Source 
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
This commit is contained in:
hc-github-team-secure-vault-core
2022-11-15 06:02:59 -08:00
committed by GitHub
parent 73ec6ed04f
commit eae20b0c2a
1 changed files with 24 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
website/content/docs/secrets/pki/considerations.mdx
View File

@@ -73,6 +73,14 @@ recommended that operators limit a mount to a single issuer. If you want to issu
certificates from multiple disparate CAs, mount the PKI secrets engine at multiple
mount points with separate CA certificates in each.
The rationale for separating mounts is to simplify permissions management:
very few individuals need access to perform operations with the root, but
many need access to create leaves. The operations on a root should generally
be limited to issuing and revoking intermediate CAs, which is a highly
privileged operation; it becomes much easier to audit these operations when
they're in a separate mount than if they're mixed in with day-to-day leaf
issuance.
A common pattern is to have one mount act as your root CA and to use this CA
only to sign intermediate CA CSRs from other PKI secrets engines.
@@ -175,13 +183,12 @@ store generated private keys, except for CA certificates). In most cases, if the
key is lost, the certificate can simply be ignored, as it will expire shortly.
If a certificate must truly be revoked, the normal Vault revocation function can
be used; alternately a root token can be used to revoke the certificate using
the certificate's serial number. Any revocation action will cause the CRL to be
regenerated. When the CRL is regenerated, any expired certificates are removed
from the CRL (and any revoked, expired certificate are removed from secrets
engine storage). This is an expensive operation! Due to the structure of the
CRL standard, Vault must read **all** revoked certificates into memory in order
to rebuild the CRL and clients must fetch the regenerated CRL.
be used, and any revocation action will cause the CRL to be regenerated. When
the CRL is regenerated, any expired certificates are removed from the CRL (and
any revoked, expired certificate are removed from secrets engine storage). This
is an expensive operation! Due to the structure of the CRL standard, Vault must
read **all** revoked certificates into memory in order to rebuild the CRL and
clients must fetch the regenerated CRL.
This secrets engine does not support multiple CRL endpoints with sliding date
windows; often such mechanisms will have the transition point a few days apart,
@@ -202,6 +209,16 @@ is down.
This is again a rationale for keeping TTLs short and avoiding revocation
if possible.
~> Note: Since Vault 1.12.0, we support two complementary revocation
mechanisms: Delta CRLs, which allow for rebuilds of smaller, incremental
additions to the last complete CRL, and OCSP, which allows responding to
revocation status requests for individual certificates. When coupled with
the new CRL auto-rebuild functionality, this means that the revoking step
isn't as costly (as the CRL isn't always rebuilt on each revocation),
outside of storage considerations. However, while the rebuild operation
still can be expensive with lots of certificates, it will be done on a
schedule rather than on demand.
### NotAfter Behavior on Leaf Certificates
In Vault 1.11.0, the PKI Secrets Engine has introduced a new