Vault unseal failing when auto unseal enabled

In the process of restoration of the vault from the same back end I observed the vault is already initiated but in a sealed state, the backend perfectly configured, when I am trying to unseal it using the keys which are collected prior installation of vault I see it is not allowed.

Note: Auto unseal enabled not allowing to change seal to unseal or vice-versa

Expectation: when all the nodes in vault down and wanted to recover then, provisioning new vault with same back end table should allow to access the secrets.

[ec2-user@ip ~]$ more /opt/vault/config/default.hcl
ui = true
seal “awskms” {
kms_key_id = “adXXXXXXXXad”
region = “us-west-1”


listener “tcp” {
address = “”
cluster_address = “”
tls_cert_file = “/opt/vault/tlscert/vault.crt.pem”
tls_key_file = “/opt/vault/tlscert/vault.key”
tls_disable_client_certs = “true”

storage “dynamodb” {
ha_enabled = “true”
region = “us-west-1”
table = “vault-table”

HA settings

cluster_addr = “https://:8201”
api_addr = “https://:8200”

[ec2-user@ip- ~]$ vault operator unseal -tls-skip-verify
Unseal Key (will be hidden):
Error unsealing: Error making API request.

Code: 500. Errors:

  • failed to decrypt encrypted stored keys: error decrypting data encryption key: AccessDeniedException: The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access.
    status code: 400, request id: a4gh789-59ba-4a8841aef4c6-411a-8c91

VAULT_ADDRESS ENV pointing to cluster

Some ideas to investigate:

  • verify that the KMS key still exists using the AWS console or API
  • make sure that the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env vars are populated with values that allow access to that KMS key

Issue resolved on the same day after identifying KMS key ID is wrong