c5665920f6
This removes all references I could find to: - credential provider - authentication backend - authentication provider - auth provider - auth backend in favor of the unified: - auth method
2.7 KiB
| layout | page_title | sidebar_current | description |
|---|---|---|---|
| guides | Upgrading to Vault 0.5.1 - Guides | guides-upgrading-to-0.5.1 | This page contains the list of breaking changes for Vault 0.5.1. Please read it carefully. |
Overview
This page contains the list of breaking changes for Vault 0.5.1. Please read it carefully.
PKI Backend Disallows RSA Keys < 2048 Bits
The PKI backend now refuses to issue a certificate, sign a CSR, or save a role that specifies an RSA key of less than 2048 bits. Smaller keys are considered unsafe and are disallowed in the Internet PKI. Although this may require updating your roles, we do not expect any other breaks from this; since its inception the PKI backend has mandated SHA256 hashes for its signatures, and software able to handle these certificates should be able to handle certificates with >= 2048-bit RSA keys as well.
PKI Backend Does Not Automatically Delete Expired Certificates
The PKI backend now does not automatically delete expired certificates, including from the CRL. Doing so could lead to a situation where a time mismatch between the Vault server and clients could result in a certificate that would not be considered expired by a client being removed from the CRL.
Vault strives for determinism and putting the operator in control, so expunging
expired certificates has been moved to a new function at pki/tidy. You can
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 auth method 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.