| --- |
| layout: docs |
| page_title: Upgrading to Vault 0.5.1 - Guides |
| description: |- |
| 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. |
