From 0f927ce663ff48b9e5f3ffbcbcaa2fc4d04cb5ac Mon Sep 17 00:00:00 2001 From: Jeff Mitchell Date: Wed, 24 Feb 2016 21:24:20 -0500 Subject: [PATCH] Add information about the cert renewal enhancements to the upgrade guide --- .../docs/install/upgrade-to-0.5.1.html.md | 23 +++++++++++++++++++ .../docs/install/upgrade-to-0.6.html.md | 23 +++++++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/website/source/docs/install/upgrade-to-0.5.1.html.md b/website/source/docs/install/upgrade-to-0.5.1.html.md index b8fa46c177..9094656920 100644 --- a/website/source/docs/install/upgrade-to-0.5.1.html.md +++ b/website/source/docs/install/upgrade-to-0.5.1.html.md @@ -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. diff --git a/website/source/docs/install/upgrade-to-0.6.html.md b/website/source/docs/install/upgrade-to-0.6.html.md index 8763f3600f..1997cee417 100644 --- a/website/source/docs/install/upgrade-to-0.6.html.md +++ b/website/source/docs/install/upgrade-to-0.6.html.md @@ -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.