🔐 Vault Error: 'failed to unseal: invalid key' Wrong or Mismatched Unseal Shares

Exact Error Message

$ vault operator unseal
Unseal Key (will be hidden):
Error unsealing: Error making API request.

URL: PUT https://vault.example.com:8200/v1/sys/unseal
Code: 400. Errors:

* failed to unseal: invalid key

Partway through a multi-share unseal you may instead see progress that never completes:

Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    1/3
Unseal Nonce       9f2c1a44-6c0e-4a1b-9d5b-2f77c3e0b118
Version            n/a
Storage Type       raft
HA Enabled         true

What It Means

When Vault is initialised with the default Shamir seal, the master key is split into Total Shares fragments, of which Threshold are needed to reconstruct it. Each call to vault operator unseal submits one share; Vault holds the accumulated shares in memory against an unseal nonce and only attempts reconstruction once the threshold is reached. failed to unseal: invalid key means the share you submitted did not pass validation — it is malformed, it is not a share of this Vault’s master key, or it belongs to a different initialization entirely.

The distinction that trips people up most often is that shares are only meaningful for the initialization that produced them. If someone ran vault operator init a second time — against a fresh storage backend, a wiped Raft data directory, or a new cluster — every key from the previous init is permanently useless, even though it looks identical in format. Similarly, submitting the same valid share twice does not advance progress: Vault deduplicates shares against the current nonce, so Unseal Progress stays at 1/3 while operators become convinced the keys are broken. And under auto-unseal, the values in your key file are recovery keys, not unseal keys, and cannot be fed to vault operator unseal at all.

Common Causes

• Fewer distinct shares supplied than Threshold requires, or the same share pasted more than once.
• Keys come from an earlier vault operator init that was superseded by a re-initialization.
• The share was copied with leading or trailing whitespace, a line break, or a shell-mangled character.
• The key is PGP-encrypted (initialization used -pgp-keys) and was never decrypted before use.
• Vault uses auto-unseal, so the stored values are recovery keys and the Shamir unseal path does not apply.
• A rekey operation completed and old shares were never replaced in the escrow or password manager.

Diagnostic Commands

Start with the seal state, which tells you the seal type, the threshold, and how far the current attempt has progressed:

vault status

Read the same information from the API when the CLI is unavailable — this endpoint is unauthenticated and works on a sealed node:

curl -s https://vault.example.com:8200/v1/sys/seal-status | jq

Key fields are type (shamir versus awskms, azurekeyvault, gcpckms, transit and so on), initialized, sealed, t (threshold), n (total shares), progress, and nonce. If type is anything other than shamir, this is an auto-unsealed cluster and the error belongs to a different family — see Vault error: auto-unseal KMS access denied.

Check whether your share is even the right shape. A base64 share and a hex share are both valid inputs, but a truncated one is not:

printf '%s' "$UNSEAL_KEY" | wc -c
printf '%s' "$UNSEAL_KEY" | od -c | tail -3

The od output makes stray \n, \r, or a trailing space obvious — the most common cause of an otherwise-correct key being rejected.

Confirm you are talking to the node you think you are. Each node in a Raft cluster maintains its own seal state:

for node in vault-0 vault-1 vault-2; do
  echo "== $node"
  VAULT_ADDR="https://$node.example.com:8200" vault status | grep -E 'Sealed|HA Mode|Unseal Progress'
done

If a node reports a TLS verification failure while you are diagnosing, you can confirm the hypothesis with -tls-skip-verify as a temporary diagnostic only — never leave it in scripts or environment files, and restore proper CA trust (VAULT_CACERT or the system trust store) before proceeding.

Step-by-Step Resolution

1. Clear any partial progress. A half-finished attempt with a bad share mixed in will keep failing until you reset it:

vault operator unseal -reset
vault status | grep "Unseal Progress"

2. Supply distinct shares, one per invocation, from different key holders. Passing the key as an argument leaks it into shell history, so prefer the interactive prompt or stdin:

vault operator unseal            # holder 1, interactive prompt
vault operator unseal            # holder 2
vault operator unseal            # holder 3 -> Sealed false

3. If the shares were PGP-encrypted at init time, decrypt each one before submitting it. The stored value is base64-wrapped ciphertext, not a usable share:

echo "$PGP_ENCRYPTED_SHARE" | base64 --decode | gpg --decrypt

4. Verify the shares belong to this initialization. If vault status shows Initialized true but every share is rejected, compare the cluster ID against what you recorded at init time:

curl -s https://vault.example.com:8200/v1/sys/seal-status | jq '{cluster_id, cluster_name, t, n, nonce}'

A cluster ID that does not match your records means the storage backend was re-initialised and the old shares are unrecoverable. Restore from a snapshot instead — see Vault error: Raft snapshot failed.

5. Unseal every node. In a Raft HA cluster without auto-unseal, each node must be unsealed independently after a restart; unsealing only the leader leaves the cluster without quorum-capable peers:

for node in vault-0 vault-1 vault-2; do
  export VAULT_ADDR="https://$node.example.com:8200"
  vault operator unseal "$KEY_1"
  vault operator unseal "$KEY_2"
  vault operator unseal "$KEY_3"
done

6. Once unsealed, rotate the shares if any were exposed during troubleshooting. A rekey generates a fresh set and invalidates the old ones:

vault operator rekey -init -key-shares=5 -key-threshold=3
vault operator rekey -nonce=<nonce>    # repeat with old shares until complete

For an auto-unsealed cluster the equivalent command is vault operator rekey -target=recovery, which rotates the recovery keys rather than the Shamir shares. Consider distributing new shares with -pgp-keys so no single operator ever sees a plaintext share:

# vault.hcl - auto-unseal removes the manual unseal step entirely
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "alias/vault-unseal"
}

Prevention

• Store each share with a different holder and record the initialization date and cluster ID alongside it.
• Use -pgp-keys at init so shares are never written to disk or a terminal in plaintext.
• Adopt auto-unseal for anything running unattended; keep recovery keys escrowed for break-glass operations.
• Document the threshold prominently — teams routinely try to unseal with two shares when three are required.
• Take and test Raft snapshots regularly so a lost key set is an inconvenience rather than a total loss.
• Never re-run vault operator init against storage you might still need; treat it as a destructive command.

Related Errors

• Vault is already initialized — you tried to init an existing cluster; the existing shares remain the only valid ones.
• Code: 503. Errors: * Vault is sealed — normal for a sealed node, not a key problem; complete the unseal.
• stored unseal keys are supported only with auto unseal — Shamir shares were passed on an auto-unsealed cluster.
• failed to decrypt encrypted stored keys — the auto-unseal KMS key is unreachable or the seal config changed.

Frequently Asked Questions

Why does Unseal Progress stay at 1/3 when I keep entering keys? Vault deduplicates shares against the current nonce, so submitting the same share repeatedly does not advance progress. You need three different shares. Run vault operator unseal -reset and gather the shares from separate holders.

Can I mix base64 and hex shares? Yes — Vault accepts either encoding and detects the format per share, so shares from an init that emitted hex and a rekey that emitted base64 both validate. What breaks is whitespace, truncation, or a share from a different initialization.

Do recovery keys work with vault operator unseal? No. Under auto-unseal the master key is protected by an external KMS and recovery keys exist only for privileged operations such as generating a root token or rekeying. Feeding a recovery key to the unseal command produces exactly this invalid-key error.

Do I have to unseal every node in the cluster? With Shamir, yes — sealing state is per node, so every restarted node needs the threshold of shares. Auto-unseal removes this entirely, which is the main operational reason to adopt it. For more Vault operations fixes, see the Vault guides.