upstream/vault
1
0
Fork 0
mirror of https://github.com/hashicorp/vault.git synced 2026-06-13 19:00:44 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 11

Add information about the cert renewal enhancements to the upgrade guide

Browse source
This commit is contained in:
Jeff Mitchell 2016-02-24 21:24:20 -05:00
parent 25547d400b
commit 0f927ce663
2 changed files with 46 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
website/source/docs/install/upgrade-to-0.5.1.html.md
View file

@ -34,3 +34,26 @@ flexibly determine whether to tidy up from the revocation list, the general
certificate storage, or both. In addition, you can specify a safety buffer
(defaulting to 72 hours) to ensure that any time discrepancies between your
hosts is accounted for.
## Cert Authentication Backend Performs Client Checking During Renewals
The `cert` backend now performs a variant of channel binding at renewal time
for increased security. In order to not overly burden clients, a notion of
identity is used, as follows:
* At both login and renewal time, the validity of the presented client
certificate is checked
* At login time, the key ID of both the client certificate and its issuing
certificate are stored
* At renewal time, the key ID of both the client certificate and its issuing
certificate must match those stored at login time
Matching on the key ID rather than the serial number allows tokens to be
renewed even if the CA or the client certificate used are rotated; so long as
the same key was used to generate the certificate (via a CSR) and sign the
certificate, renewal is allowed. As Vault encourages short-lived secrets,
including client certificates (for instance, those issued by the `pki`
backend), this is a useful approach compared to strict issuer/serial number
checking.
You can use the new `cert/config` endpoint to disable this behavior.

23
website/source/docs/install/upgrade-to-0.6.html.md
View file

@ -36,3 +36,26 @@ flexibly determine whether to tidy up from the revocation list, the general
certificate storage, or both. In addition, you can specify a safety buffer
(defaulting to 72 hours) to ensure that any time discrepancies between your
hosts is accounted for.
## Cert Authentication Backend Performs Client Checking During Renewals
The `cert` backend now performs a variant of channel binding at renewal time
for increased security. In order to not overly burden clients, a notion of
identity is used, as follows:
* At both login and renewal time, the validity of the presented client
certificate is checked
* At login time, the key ID of both the client certificate and its issuing
certificate are stored
* At renewal time, the key ID of both the client certificate and its issuing
certificate must match those stored at login time
Matching on the key ID rather than the serial number allows tokens to be
renewed even if the CA or the client certificate used are rotated; so long as
the same key was used to generate the certificate (via a CSR) and sign the
certificate, renewal is allowed. As Vault encourages short-lived secrets,
including client certificates (for instance, those issued by the `pki`
backend), this is a useful approach compared to strict issuer/serial number
checking.
You can use the new `cert/config` endpoint to disable this behavior.