A kubeadm cluster will run for a full year without a single complaint, then lock you out the morning after its first birthday. That expiration date ships with every cluster kubeadm builds, and almost nobody writes it down. The client certificates kubeadm generates for the control plane are valid for one year. There’s no banner in a dashboard counting down to it. A year after install, on a cluster nobody has upgraded, kubectl starts answering every command with x509: certificate has expired or is not yet validand the control plane components that authenticate to each other with those same certificates start failing right along with it.
The fix takes a few minutes once you know it. Run kubeadm certs check-expiration on a control plane node to see what’s expiring, renew with kubeadm certs renew allthen restart the control plane static Pods so they load the new certificates. Better still, never get there. kubeadm renews every control plane certificate automatically during a cluster upgrade, so a cluster that gets upgraded at least once a year never hits the wall.
Every kubeadm client certificate lasts 8,760 hours. That’s one year, and the countdown starts the moment you run kubeadm init.
Why Do Kubernetes Certificates Expire After One Year?
When you run kubeadm initkubeadm quietly builds a private certificate authority for your cluster and stores it under /etc/kubernetes/pki. Everything in the control plane talks over mutual TLS using certificates signed by that CA, which makes a Kubernetes control plane a small working example of the zero trust idea that most certifications barely coversince no component gets trusted just for being on the same network. The API server proves its identity to kubectl and to the kubelets. Between the API server and etcd, authentication runs in both directions. The controller manager and scheduler each carry their own client certificates, embedded in their kubeconfig files. It’s a small, self contained PKI, and it works well right up until the leaf certificates run out.
According to the Kubernetes documentation on kubeadm certificate managementclient certificates default to 8760 hours, which is one year, while the CAs default to 87600 hours, or ten years. Both are adjustable. The v1beta4 kubeadm configuration API exposes certificateValidityPeriod and caCertificateValidityPeriod in the ClusterConfiguration if you want different lifetimes.
Why a year? Look at how Kubernetes itself ships. The project maintains branches for the three most recent minor releases, each getting roughly a year of patch support, per the Kubernetes releases page. A cluster that stays on a supported version gets upgraded well inside twelve months, and every upgrade renews the certificates as a side effect. The one year default only bites the clusters that drifted out of support, which is its own warning sign.
If certificate authorities and chains of trust still feel abstract, the guide to how an SSL certificate chain works and why it breaks covers the same trust model that kubeadm uses internally.
Not the same as the 47 day rule: The CA/Browser Forum’s move toward shorter certificate lifetimes applies to publicly trusted TLS certificates, the kind a browser checks on your website. kubeadm’s internal certificates come from your own private CA, so those browser rules don’t touch them. For the public side of that story, see the breakdown of the 47 day certificate rule and when it hits. Your cluster’s ingress certificates are a different story, since anything a browser loads from your cluster still plays by public rules.
What Happens When Kubernetes Certificates Expire?
The first sign is almost always kubectl. Your admin.conf kubeconfig carries a client certificate with the same one year lifetime, so the moment it lapses, the API server rejects you. Then the control plane starts coming apart in less obvious ways. The scheduler and controller manager lose their ability to authenticate. And if the lapsed certificate is the one the API server uses to reach etcd? Then it can’t read or write cluster state at all.
Your applications, meanwhile, may look perfectly fine.
Pods that were already running usually keep running, because the container runtime on each node doesn’t need the API server to keep a process alive. What stops is everything that depends on the control plane. New Pods don’t get scheduled, Deployments don’t roll out, and a crashed node’s workloads don’t get rescheduled anywhere. So the cluster looks healthy from the outside until something needs to change, and then nothing can. That delay is exactly why teams lose hours troubleshooting networking or DNS before anyone thinks to check a certificate date. The classic tell is kubectl failing with x509 errors while your application still answers requests. When you see that combination, check certificate dates before you touch anything else.
How to Check Kubernetes Certificate Expiration
On a control plane node, with root access, run this:
sudo kubeadm certs check-expirationThe output lists each certificate with its expiry date, a RESIDUAL TIME column showing how long it has left, the CA that signed it, and whether it’s externally managed. A second table covers the CAs themselves. If you’d rather check a single file directly, openssl works on any of them, and it’s one of the Linux commands worth keeping in muscle memory anyway:
sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -enddatePut that date somewhere a human will see it. A calendar reminder 60 days out costs nothing. An alert in your monitoring stack is better, since calendar owners change jobs.
How to Renew Kubernetes Certificates With kubeadm
If the cluster is on a supported version and you can upgrade, upgrading is the cleaner path, since it renews everything and moves you forward at the same time. When upgrading isn’t an option right now, renew manually:
sudo kubeadm certs renew allRenewing the files isn’t enough on its own. The control plane components are static Pods, and they only load certificates at startup, so they need a restart. Per the Kubernetes docs, you move each manifest out of /etc/kubernetes/manifests/wait about 20 seconds for the kubelet to stop the Pod, then move it back:
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/
# wait roughly 20 seconds
sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/Repeat for kube-controller-manager, kube-scheduler, and etcd. Then refresh your own access, because the renewed admin.conf has a new client certificate and your old ~/.kube/config copy still holds the expired one. Copy the new file over, and treat both admin.conf and super-admin.conf as secrets. The Kubernetes docs explicitly warn against sharing them.
Running a highly available control plane? The renewal is local to the node you run it on, so every control plane node needs its own pass.
One more thing people miss about the kubelet. Its client certificate rotates on its own, but its serving certificate, the one the API server sees when it connects to the kubelet for logs and exec, is self signed by default. Setting serverTLSBootstrap: true in the kubelet configuration has the kubelet request a properly signed serving certificate instead, though those requests then need to be approved.
What About the Ten Year CA Certificates?
kubeadm certs renew uses the existing CA as its source of truth and doesn’t touch the CA certificates themselves. Ten years sounds like forever, and for most clusters it is, since very few survive that long without a rebuild. If you do run long lived infrastructure, CA rotation is a manual, multi step procedure that has to be rolled out to every component that trusts the old CA. Give it the planning you’d give a migration, with a rollback path and a maintenance window.
Where This Shows Up on the CKA and CKS
Certificate management sits right on the border between the two Linux Foundation exams most platform teams care about. The CKA’s Cluster Architecture, Installation and Configuration domain is built around kubeadm, and its Troubleshooting domain, 30 percent of the exam, is where a broken control plane component tends to show up. Knowing where /etc/kubernetes/pki lives and how static Pods restart pays off everywhere from exam questions to 3 AM production incidents. Training Camp covers it in the 5 day CKA Boot Camp and the shorter CKA Fast Track Boot Camp.
The CKS picks up from there with TLS, access restrictions on the API server, and cluster hardening, and it requires a passing CKA first. That path is covered in the CKS Boot Camp. If kubeadm and static Pods are still unfamiliar terms, the Kubernetes Fundamentals course is the better starting point. The full lineup is on the Linux Foundation training page.
Frequently Asked Questions About Kubernetes Certificate Expiration
How long are kubeadm certificates valid?
Client certificates generated by kubeadm are valid for one year (8760 hours) by default. The cluster certificate authorities are valid for ten years (87600 hours). Both lifetimes can be changed with the certificateValidityPeriod and caCertificateValidityPeriod fields in the v1beta4 kubeadm ClusterConfiguration.
How do I check when my Kubernetes certificates expire?
Run sudo kubeadm certs check-expiration on a control plane node. It lists every kubeadm managed certificate with its expiration date and remaining time. You can also check an individual file with openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -enddate.
Does kubeadm upgrade renew certificates automatically?
Yes. kubeadm renews all control plane certificates during a control plane upgrade. Clusters that are upgraded at least once a year will not reach the default one year expiration.
What error do you get when Kubernetes certificates expire?
The most common symptom is kubectl returning x509: certificate has expired or is not yet valid. Control plane components such as the scheduler and controller manager also fail to authenticate, so scheduling and rollouts stop even though existing Pods may keep running.
Do I need to restart anything after kubeadm certs renew all?
Yes. The control plane components run as static Pods and only load certificates at startup. Restart each one by temporarily moving its manifest out of /etc/kubernetes/manifests, waiting about 20 seconds, and moving it back. Then copy the renewed admin.conf to your kubeconfig.
Does kubeadm certs renew renew the CA certificate?
No. kubeadm certs renew uses the existing CA as the authoritative source and does not renew the CA certificates, which default to ten years. Rotating a cluster CA is a separate manual procedure.
Consultant | Freelance
Nora Grace is a tech writer and social engineering consultant who specializes in cybersecurity and IT content. She creates practical, easy-to-digest blog articles on topics like cloud computing, Linux, and security awareness. Nora lives and travels across Europe with her two dogs, blending her freelance writing with consulting work that helps organizations strengthen their human-layer defenses. Known for her clear voice and deep curiosity, she brings both technical know-how and real-world insight to everything she writes.