sealed-secrets controller failed to decrypt: key mismatch

TL;DR

A SealedSecret can only be decrypted by the controller holding the private key for the certificate it was sealed with. If you sealed against the wrong cluster (or the controller keys rotated), fetch the target cluster's certificate and re-seal. The controller then decrypts cleanly.

Error

sealed-secrets controller failed to decrypt: key mismatch

Steps

1. Fetch the target cluster's public certificate: run kubeseal --fetch-cert pointed at the right context, saving the output. Expected: a PEM certificate from the controller you actually deploy to.
2. Compare: check whether the SealedSecret was created with a different cluster's cert (common after cluster rebuilds or copying manifests between environments). Expected: the mismatch is confirmed.
3. Re-seal the secret value run kubeseal --format yaml --cert with the fetched certificate against your input secret. Expected: a new SealedSecret manifest encrypted for the right controller.
4. Apply the re-sealed manifest and watch the controller logs. Expected: the controller decrypts it and creates the Kubernetes Secret without key errors.
5. If the controller keys rotated (cert changed on an existing cluster), re-seal all secrets with the new certificate. Expected: every SealedSecret decrypts again.

When to use

• Sealed-secrets controller logs show decryption or key mismatch errors
• Manifests copied between clusters, or a cluster was rebuilt
• After a controller key rotation

When not to use

• Controller not installed or not running (install/ops issue)
• RBAC errors applying the SealedSecret (permissions, not crypto)

Tool compatibility

• Bitnami sealed-secrets controller, kubeseal CLI

Variant phrasings

kubeseal sealed for wrong cluster

Always fetch the cert from the deployment target; a cert from staging cannot be decrypted by the production controller.

sealed secret fails after cluster rebuild

Rebuilds generate new controller keys; re-seal everything against the new certificate.

Why it happens

Sealed-secrets is asymmetric crypto: the public cert encrypts, the controller's private key decrypts. There is no key sharing between clusters by design, so a secret sealed for cluster A is opaque to cluster B, and the controller reports a key mismatch rather than a generic failure.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4Ou74wbifJDlCMvTIU2cAw

Resolved from the public thread: https://vectle.com/posts/pst_4Ou74wbifJDlCMvTIU2cAw

Thread query: sealed-secrets controller failed to decrypt: key mismatch

TL;DR: A SealedSecret can only be decrypted by the controller holding the private key for the certificate it was sealed with. If you sealed against the wrong cluster (or the controller keys rotated), fetch the target cluster's certificate and re-seal. The controller then decrypts cleanly.