kubeseal: error: cannot fetch certificate from controller

Not specified by the original author.

TL;DR

kubeseal cannot reach the sealed-secrets controller to fetch its public cert: wrong controller name, wrong namespace, or wrong cluster context. Pass the right --controller-name, --controller-namespace, and context, and the fetch succeeds.

Error

kubeseal: error: cannot fetch certificate from controller

Steps

1. Check your context: confirm kubectl points at the cluster running the controller. Expected: the right cluster, not a stale context.
2. Find the controller: list deployments or pods for the sealed-secrets controller and note its name and namespace. Expected: the real name and namespace, which often differ from defaults after custom installs.
3. Fetch with explicit flags: run kubeseal with the controller name and namespace you found. Expected: the certificate downloads.
4. Check RBAC: the fetching identity needs permission to read the controller's service or secret. Expected: no forbidden errors once the flags are right.
5. Save the certificate and use it for offline sealing. Expected: kubeseal --cert works without contacting the cluster.

When to use

• kubeseal fails fetching the controller certificate
• Custom controller names or namespaces
• Sealing for a different cluster than your current context

When not to use

• Sealing succeeds but the controller cannot decrypt (key mismatch)
• Controller not installed (install it first)

Tool compatibility

• kubeseal CLI; sealed-secrets controller service

Variant phrasings

kubeseal wrong controller namespace

Pass --controller-namespace explicitly; the default only fits default installs.

fetch cert wrong cluster

Switch kubectl context to the target cluster before fetching.

Why it happens

kubeseal discovers the controller via the Kubernetes API using default name and namespace assumptions. Custom installs, multiple clusters, or a stale context break those assumptions, and the fetch fails before any crypto happens.

Provenance

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

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

Thread query: kubeseal: error: cannot fetch certificate from controller

TL;DR: kubeseal cannot reach the sealed-secrets controller to fetch its public cert: wrong controller name, wrong namespace, or wrong cluster context. Pass the right --controller-name, --controller-namespace, and context, and the fetch succeeds.

Not specified by the original author.

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.

Not specified by the original author.

Fix kubectl "certificate signed by unknown authority"

TL;DR

The CA bundled in your kubeconfig does not match the CA that signed the API server's certificate. Get a fresh kubeconfig from your cluster admin or cloud console, or fix the certificate-authority-data entry for that cluster. kubectl pins the cluster CA in the kubeconfig, so any mismatch fails the TLS handshake before auth even starts.

Kubernetes "certificate signed by unknown authority": kubeconfig debugging

Steps

1. Identify the broken context. Run kubectl config get-contexts and kubectl config current-context. Expected: you know exactly which cluster entry fails.

2. Inspect the cluster entry. Run kubectl config view and look at the certificate-authority-data (or certificate-authority file path) for that cluster. Expected: you see the CA data present, missing, or pointing at a stale file.

3. Get a fresh kubeconfig. Regenerate it from your cloud console, cluster admin, or the provider CLI for your platform. Expected: the new file carries the current CA and kubectl connects.

4. If the cluster CA was rotated, expect this. Old kubeconfigs break by design after rotation. Distribute the new CA to everyone and everything that talks to the cluster. Expected: kubectl works everywhere again once the new CA is in place.

5. If you sit behind a TLS-intercepting proxy, fix trust properly. Add the proxy's CA to your system trust store rather than hacking the kubeconfig. Expected: kubectl trusts the full chain through the proxy.

Use this when

• kubectl fails with x509: certificate signed by unknown authority
• A kubeconfig that used to work suddenly stops after a cluster upgrade
• Setting up kubectl on a new machine against an existing cluster

Not for this skill when

• The error says the certificate has expired (different fix: renew, not replace CA)
• Auth fails with token or credential errors (the TLS handshake already succeeded)
• The error is "connection refused" (the API server is not reachable at all)

Variant phrasings

• kubectl x509 certificate signed by unknown authority
• kubeconfig ca mismatch
• unknown authority kubernetes
• kubectl certificate authority invalid

Why it happens

Every cluster has a certificate authority that signs the API server's serving certificate. kubectl verifies that serving cert against the CA pinned in the kubeconfig. Rotation, a copied kubeconfig from another cluster, or a proxy inserting its own cert all break that pin, and TLS fails closed.

Edge cases

• An expired CA produces a nearly identical error. Check the CA dates before assuming mismatch.
• Multiple contexts across merged kubeconfig files get mixed up easily. Always verify current-context first.
• Some tools cache the old CA or the old kubeconfig. Restart them after replacing the file.
• Service account tokens mounted in pods use the cluster's own CA bundle, so in-cluster clients are unaffected by your local kubeconfig problem.

Provenance

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

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

Thread query: Kubernetes "certificate signed by unknown authority": kubeconfig debugging

TL;DR: The CA bundled in your kubeconfig does not match the CA that signed the API server's certificate. Get a fresh kubeconfig from your cluster admin or cloud console, or fix the certificate-authority-data entry for that cluster. kubectl pins the cluster CA in the kubeconfig, so any mismatch fails the TLS handshake before auth even starts.