Skip to main content
Hello — welcome to this lesson. You’ll learn how to locate, inspect, and validate TLS certificates used by Kubernetes control plane components so you can perform a cluster-wide certificate health check. Scenario: you’re a new administrator asked to audit certificates in an existing cluster. The first diagnostic step is to identify how the cluster was provisioned, because certificate storage and component invocation change depending on the provisioning method:
  • If the control plane runs as native systemd services (custom from-scratch installs), certificate file paths and TLS flags are visible from unit files or the running processes.
  • If the cluster was provisioned with kubeadm, control plane components run as static pods; manifests live under /etc/kubernetes/manifests and certificates are typically under /etc/kubernetes/pki.
Note: kubeadm places static manifests under /etc/kubernetes/manifests and certificates under /etc/kubernetes/pki by default.
When doing a certificate health check, create a simple spreadsheet (paths, CN, SANs, organization, issuer, expiry) to track the findings across all nodes. Use this spreadsheet format to guide your tracking.
Why inspect certificates?
  • Confirm each component presents the correct Subject Common Name (CN) for identity.
  • Ensure required Subject Alternative Names (SANs) — DNS and IP — are present.
  • Verify the issuer matches your expected CA.
  • Detect expired or soon-to-expire certificates to plan rotations and prevent outages.
How to identify certificate files used by control plane components
  1. Systemd-managed control plane
  • If the control plane is managed via systemd, inspect unit files (typically in /etc/systemd/system or /lib/systemd/system) to find flags pointing at cert/key files. Example unit excerpt for kube-apiserver:
  1. kubeadm / static pod control plane
  • Inspect the static pod manifest for the kube-apiserver under /etc/kubernetes/manifests to find the exact certificate paths and filenames used by the control plane container:
Once you have the certificate file list, inspect each certificate to extract metadata (subject CN, SANs, issuer, validity, etc.). How to decode and inspect certificates
  • Use openssl to read a PEM certificate and inspect its fields:
What to verify for each certificate
  • Subject CN matches the component (e.g., CN=kube-apiserver).
  • Expected DNS and IP SANs are present.
  • Issuer is the expected CA (kubeadm typically uses CA with CN=kubernetes).
  • Certificate validity period is current (check the Not After date for expiry).
Use the table in the first figure below as a pattern for your spreadsheet: include certificate path, CN, SANs, organization, issuer, and expiration.
A dark-themed slide titled "kubeadm" showing a table of Kubernetes certificate files with columns for certificate path, CN name, ALT names (DNS/IP SANs), organization, issuer, and expiration dates. It lists entries like /etc/kubernetes/pki/apiserver.crt, ca.crt, kubelet-client and etcd client certificates with their SANs and expiry timestamps.
Reference the official Kubernetes documentation for recommended certificate CNs, default paths, and component requirements: https://kubernetes.io/docs/concepts/cluster-administration/certificates/. The docs include tables of default CNs and expected parent CA relationships.
A slide titled "Kubernetes Documentation Page" showing two tables that list default CNs, parent CAs, recommended key/cert paths, commands and cert/key arguments for Kubernetes components. The content is on a dark teal background with a small "© Copyright KodeKloud" notice in the corner.
Checking logs when certificates fail
  • If components run under systemd, start with the system journal to find TLS handshake and certificate errors:
Example etcd log snippets showing TLS configuration and handshake failure:
  • If control plane components are running as static pods (kubeadm), view pod logs with kubectl. Replace <etcd-pod> with the actual pod name and add -n kube-system if necessary:
Example pod log output (you may see TLS/handshake errors similar to the systemd example above).
  • If the control plane is down and kubectl cannot reach the API server, check the container runtime logs directly:
    • For CRI-based runtimes (containerd/crio) use crictl:
  • For Docker runtime:
What to do with findings
  • Missing SANs: reissue the certificate including the correct DNS/IP SANs.
  • Expired certificates: rotate/reissue them. Kubeadm provides certificate management helpers (see kubeadm certs docs).
  • Unexpected issuer: investigate whether a certificate was manually replaced or issued by an unknown CA.
Quick verification checklist Useful links and references Closing notes
  • Collect findings into the spreadsheet described in the callout to track certificate path, CN, SANs, issuer, and expiry across nodes.
  • Test these steps in a lab environment before running them on production clusters to avoid accidental outages.

Watch Video