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 |
Identity System Duplicate Cleanup
Users should review their server logs after upgrading to see if identity duplicates are reported.
Vault 1.19.0 enables users impacted by historical identity duplicate bugs to manually trigger a one-time de-duplication process. This process restores the cluster to supported default behavior by resolving the duplicates.
Vault 1.19.0 also includes improved reporting in server logs to help diagnose whether this de-duplication is required. No behavior will change until the operator activates the relevant flag via the API.
To understand if you need to take action, consult the resolution guide which demonstrates which log lines to watch for. If duplicates are found, the guide explains the process to ensure any duplicates found are safely resolved.
Known issues and workarounds
Seal/Seal Wrapped - Duplicate HSM Keys
Affected Versions
- All versions that support migration from Shamir to HSM-backed unseal/seal wrap in HSM-HA configurations.
Issue
During a migration from Shamir to an HSM-backed unseal configuration with HSM - High Availability (HA), duplicate HSM keys may be created. 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.
- Unseal failures: Nodes may fail to unseal after a restart, with errors such as CKR_DATA_INVALID.
- Duplicate HSM keys: These may be created, resulting in intermittent read failures with errors such as CKR_SIGNATURE_INVALID and CKR_KEY_HANDLE_INVALID for any seal wrapped value - see /vault/docs/enterprise/sealwrap#wrapped-parameters.
Workaround
As a workaround, always run Vault with generate_key = false, creating the required keys within the HSM manually during the setup process.