How to fix x509: certificate has expired or is not yet valid in Kubernetes

KubernetesINTERMEDIATECRITICALUpdated Dec 6, 2025· 337 views

Kubernetes cluster certificates expire after 1 year by default, causing API server, kubelet, etcd, and other control plane components to become unavailable. The cluster becomes inaccessible when certificates expire. Fix by renewing certificates proactively or implementing automatic rotation.

Quick fix

Fixes x509: certificate has expired or is not yet valid

sudo kubeadm certs check-expiration
  1. Check certificate expiration dates
  2. Renew all certificates immediately (kubeadm)
  3. Verify certificate renewal
  4. Check for system time skew
kubernetes — error
sudo kubeadm certs check-expiration
x509: certificate has expired or is not yet valid

What this error means

Kubernetes uses TLS certificates for all control plane communication (API server, kubelet, etcd, webhooks). Certificates have expiration dates (default 1 year). When a certificate expires, the system rejects TLS connections with x509 errors. This affects entire cluster functionality.

Typical symptoms

  • kubectl commands fail: "Unable to connect to the server: x509 certificate expired"
  • Kubelet unable to authenticate to API server
  • Control plane pods cannot communicate (API server, etcd, controller-manager)
  • Admission webhooks reject requests with certificate errors
  • API server becomes unavailable
  • Nodes fail to join cluster (kubelet cert auth fails)
  • etcd cluster loses quorum (peer certs expired)

Common causes

  1. Certificates not renewed within 1-year window (default expiry)
  2. Kubelet CSR (Certificate Signing Request) approval blocked during rotation
  3. System clock drift (certificate appears "not yet valid")
  4. CA (Certificate Authority) certificate rotated without updating all nodes
  5. Cluster upgrade skipped (renewal usually happens during upgrade)
  6. Manual certificate replacement without proper rotation

How to fix "x509: certificate has expired or is not yet valid"

1Check certificate expiration dates

For kubeadm clusters:

bash
sudo kubeadm certs check-expiration

Shows all control plane certs with residual time. For manual check:

bash
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep "Not After"
# Or just the date:
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -enddate
2Renew all certificates immediately (kubeadm)

Renew all control plane certificates:

bash
sudo kubeadm certs renew all

Then restart kubelet:

bash
sudo systemctl restart kubelet
# OR (static pods):
kubectl delete pod -n kube-system <apiserver-pod>
kubectl delete pod -n kube-system <etcd-pod>
3Verify certificate renewal

Confirm new certificates are loaded:

bash
sudo kubeadm certs check-expiration
# Should show ~1 year residual time for all certs

# Verify kubectl works
kubectl get nodes

Cluster should become accessible immediately.

4Check for system time skew

Certificate appears "not yet valid" if system clock is behind:

bash
timedatectl status
ntpstat

# Sync time if needed
sudo timedatectl set-ntp true
sudo ntpdate -s time.nist.gov

Ensure all nodes synchronized (within 1-2 seconds).

5For kubelet certificate rotation, approve CSR

Kubelet auto-rotates 30 days before expiry. Approve CSRs:

bash
kubectl get csr
kubectl certificate approve <csr-name>

# Check new cert is loaded
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate
6For cluster recovery (offline)

If cluster completely down:

bash
# 1. SSH to control plane node or boot recovery image
# 2. Mount root filesystem if needed
# 3. Renew certs
sudo kubeadm certs renew all

# 4. Copy renewed certs to all control plane nodes
sudo scp -r /etc/kubernetes/pki <node2>:/etc/kubernetes/

# 5. Restart kubelet on all nodes
sudo systemctl restart kubelet
7Implement automatic renewal (cert-manager)

Install cert-manager for automatic rotation:

bash
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.0/cert-manager.yaml

# Create issuer for internal CA
kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: kubernetes-ca
spec:
  ca:
    secretName: kubernetes-ca-secret
EOF

cert-manager auto-renews certs 30 days before expiry.

Advanced notes

Default kubeadm cert expiry is 1 year; plan renewal before expiry (ideally during regular upgrades). Cluster certificates include: API server, kubelet, etcd, controller-manager, scheduler, front-proxy-client. CA certificates (10-year TTL) rarely need renewal. Always have verified backup of /etc/kubernetes/pki before renewal. kubelet auto-rotation (enabled by default) requires kube-controller-manager CSR approval enabled.

Frequently asked questions

What does "x509: certificate has expired or is not yet valid" mean?
Kubernetes uses TLS certificates for all control plane communication (API server, kubelet, etcd, webhooks). Certificates have expiration dates (default 1 year). When a certificate expires, the system rejects TLS connections with x509 errors.
How do I fix "x509: certificate has expired or is not yet valid"?
Kubernetes cluster certificates expire after 1 year by default, causing API server, kubelet, etcd, and other control plane components to become unavailable. The cluster becomes inaccessible when certificates expire. Fix by renewing certificates proactively or implementing automatic rotation.
What causes "x509: certificate has expired or is not yet valid"?
Certificates not renewed within 1-year window (default expiry) Kubelet CSR (Certificate Signing Request) approval blocked during rotation System clock drift (certificate appears "not yet valid")
Is the "x509: certificate has expired or is not yet valid" error serious?
Yes. This is a critical-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading