Vault
Overview
The Vault 1.19.x upgrade guide contains information on deprecations, important or breaking changes, and remediation recommendations for anyone upgrading from Vault 1.18. Please read carefully.
Important changes
Transit support for Ed25519ph and Ed25519ctx signatures
NOTE: This only applies to Transit Ed25519 keys.
On prior versions of Vault, when the sign and verify API endpoints backed by an Ed25519 key received the prehashed=true or the hash_algorithm=sha2-512 parameters they were ignored, returning back or verifying a Pure Ed25519 signature. As of 1.19.x, setting these values on Enterprise editions of Vault will now return an Ed25519ph signature and assume the input has been hashed using the SHA-512 algorithm.
If neither prehashed nor hash_algorithm values are provided, the existing default of using Pure Ed25519 signatures remains unchanged for both Enterprise and CE Vault editions. The change is if those values had been overridden they were previously ignored but now will be enforced based on the table below.
| Vault Edition | prehashed | hash_algorithm | 1.19.x Signature | Previous Vault Versions Signature |
|---|---|---|---|---|
| Enterprise | not set | not set | Pure Ed25519 | Pure Ed25519 |
| Enterprise | false | any value other than sha2-512 | Pure Ed25519 | Pure Ed25519 |
| Enterprise | false | sha2-512 | An error is returned | Pure Ed25519 |
| Enterprise | true | any value other than sha2-512 | An error is returned | Pure Ed25519 |
| Enterprise | true | sha2-512 | Ed25519ph | Pure Ed25519 |
| CE | not set | not set | Pure Ed25519 | Pure Ed25519 |
| CE | false | any value other than sha2-512 | Pure Ed25519 | Pure Ed25519 |
| CE | false | sha2-512 | An error is returned | Pure Ed25519 |
| CE | true | any value other than sha2-512 | An error is returned | Pure Ed25519 |
| CE | true | sha2-512 | An error is returned (not supported on CE) | Pure Ed25519 |
Known issues and workarounds
Duplicate HSM Keys and KV Read Failures
Affected Versions
- All versions that support migration from Shamir to HSM-backed unseal in HA configurations using HSMs.
Issue
During a migration from Shamir to an HSM-backed unseal configuration with High Availability (HA), duplicate HSM keys may be created. This issue has been observed specifically in setups using Thales Luna HSM, but it is not confirmed whether other HSM providers are unaffected.
- Duplicate HSM keys: These may be created, resulting in intermittent KV read failures with errors such as CKR_SIGNATURE_INVALID and CKR_KEY_HANDLE_INVALID.
- Unseal failures: Nodes may fail to unseal after a restart, with errors such as CKR_DATA_INVALID.
- Node risk: While remaining nodes may stay operational, restarting them could lead to similar unseal failures. These issues can occur even after a seal migration to HSM that initially appeared successful. The root cause is under investigation, with potential links to key handling during HA configuration or migration processes.
Workaround
As a workaround, always run Vault with generate_key = false, creating the required keys within the HSM manually during the setup process.