Introduction

x509: certificate signed by unknown authority means some Kubernetes client was presented with a certificate chain it does not trust. The important first step is to identify which client is complaining, because the fix is different for kubectl, an admission webhook, an image pull, an in-cluster app, or a node component.

What the Error Really Means

TLS verification succeeds only when the presented certificate chains back to a certificate authority in the client's trust store. This error means that trust chain failed.

In Kubernetes contexts, common places it appears are:

• 'kubectl talking to the API server'
• Pods talking to internal HTTPS services
• kubelets or controllers talking to webhooks
• image pulls through a private registry with a custom CA

So "Kubernetes x509 error" is really a family of trust-store problems, not one single bug.

If kubectl Is Failing

Check the current kubeconfig:

kubectl config view --raw

Look for the cluster certificate authority data or file path. A typical kubeconfig entry looks like:

1clusters:
2  - cluster:
3      certificate-authority: /path/to/ca.crt
4      server: https://my-cluster.example.com

If that CA file is wrong, missing, or does not match the API server certificate chain, kubectl will fail with the unknown-authority error.

This is one of the most common local causes.

If a Webhook or Internal Service Is Failing

Admission webhooks and other in-cluster HTTPS calls often fail when the caller does not trust the service certificate's CA.

For webhooks, inspect:

• the serving certificate presented by the webhook service
• the caBundle configured in the webhook object

If those do not match, the API server cannot trust the webhook endpoint.

That is a classic certificate-distribution mismatch: the server certificate may be valid, but the client was not given the right CA bundle.

If Image Pulls or App Calls Are Failing

If the error appears while pulling from a private registry or calling an HTTPS service from inside a Pod, then the trust problem is in that specific runtime environment.

Useful checks:

kubectl describe pod my-pod
kubectl logs my-pod

Then inspect whether the container image, node OS, or application runtime actually contains the required CA certificate.

For example, an app container based on a minimal image may not trust your internal CA by default even though your laptop does.

Verify the Presented Certificate Chain

Outside Kubernetes-specific config, a plain TLS inspection still helps:

openssl s_client -showcerts -connect my-service.example.com:443

This lets you see:

• the certificate chain being served
• whether intermediates are missing
• what hostname the certificate is issued for

Sometimes the problem is not the CA bundle at all. Sometimes the server is simply presenting the wrong certificate or an incomplete chain.

Do Not "Fix" This by Disabling Verification

It is tempting to add insecure flags, skip TLS verification, or trust everything. That may get you unstuck temporarily, but it removes the security guarantee the certificate system is supposed to provide.

The durable fix is always one of these:

• install or reference the correct CA
• fix the presented certificate chain
• fix hostname and SAN mismatches
• distribute trust properly to the client that is failing

Skipping verification should be treated as temporary debugging only, not as the real solution.

A Practical Debugging Sequence

Use this order:

1. identify which client emitted the error
2. inspect what server certificate it received
3. inspect what CA bundle or trust store that client uses
4. compare issuer, chain, and hostname expectations
5. repair trust distribution rather than disabling checks

This is much faster than guessing because every version of this error is fundamentally a trust-chain mismatch.

Common Pitfalls

• Treating every Kubernetes x509 error as if it came from kubectl.
• Fixing the server certificate while forgetting the client still lacks the CA bundle.
• Assuming a certificate trusted on your laptop is automatically trusted inside a container or node.
• Using insecure skip-verify flags as a permanent solution.
• Forgetting that missing intermediate certificates can cause the same error even when the root CA is correct.

Summary

• 'certificate signed by unknown authority means the failing client does not trust the presented certificate chain.'
• In Kubernetes, the right fix depends on which client is failing: kubectl, webhook, registry pull, or in-cluster app.
• Check both sides: the certificate being served and the CA trust store being used.
• Missing CA bundles and incomplete chains are more common than Kubernetes-specific magic.
• Repair trust distribution instead of turning TLS verification off.