Skip to main content
In this lesson you’ll learn how to locate, inspect, and audit TLS certificates in an existing Kubernetes cluster. This is useful for troubleshooting TLS handshake failures, validating certificate issuers, and tracking expirations during a security audit. When you join a new team as an administrator and are asked to review certificate health across a cluster, the first step is to determine how the cluster was provisioned. Certificate locations and management vary depending on the deployment method.
Kubernetes clusters are commonly provisioned in two ways:
  • Self-managed (manual): control-plane binaries are often run as systemd services and certificates are managed by the cluster operator.
  • kubeadm-managed: kubeadm usually generates certificates and runs control-plane components as static pods with manifests under /etc/kubernetes/manifests.
Identify which model your cluster uses so you know where to look for certificate references and files.

​
Quick checklist

  • Identify how the control plane is launched: systemd services vs kubeadm static pods.
  • Collect certificate file paths from service unit files or static pod manifests.
  • Inspect certificates with openssl to extract CN, SANs, issuer, and expiration.
  • Build an inventory (spreadsheet) for ongoing tracking.
  • Use logs (journalctl, kubectl logs, crictl logs) to find TLS handshake errors.

​
Where to find certificate configuration

  • Self-managed control plane (systemd): check the unit file for ExecStart arguments that reference certificate files.
Example unit file:
Typical kube-apiserver unit snippet:
  • kubeadm-managed control plane (static pods): check the static pod manifest for the API server (usually under /etc/kubernetes/manifests).
Example:
You will see container command arguments pointing to certificate files. Example excerpt:
Collect each referenced path as part of your audit inventory.

​
Create an inventory of certificates

Maintain a spreadsheet or CSV that records, per certificate:
  • File path
  • Common Name (CN)
  • Subject Alternative Names (SANs)
  • Organization (O)
  • Issuer
  • Expiration date (UTC)
  • Purpose / Usage (e.g., API server TLS, etcd server, kubelet client)
This makes it easy to spot soon-to-expire certs or certificates issued by an unexpected CA. Sample inventory rows (illustrative): Refer to Kubernetes docs for recommended CN/SAN values: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/

​
Inspect certificate details with OpenSSL

Use openssl x509 to display certificate fields. Replace the path with the certificate you want to inspect.
Example trimmed output:
From this output you can extract:
  • Subject CN (e.g., CN=kube-apiserver)
  • SANs (DNS and IP entries)
  • Issuer CN (e.g., CN=kubernetes)
  • Not Before / Not After (validity window)
  • Key usage and extended key usage to determine server/client role
Repeat for each certificate in your inventory.
Pay attention to SANs and expiration:
  • Modern TLS validation prefers SANs over the CN for hostname verification.
  • Expired certificates cause immediate TLS handshake failures; rotate/replace them before expiry.
A screenshot titled "Kubernetes Documentation Page" showing two boxed tables listing certificate common names, hosts, recommended key/cert paths and command arguments on a dark blue background. The page includes a small "© Copyright KodeKloud" notice at the bottom.

​
What to verify during an audit

  • SAN coverage: Ensure the certificate’s SANs cover the hostnames/IPs clients use (API server cluster IP, service DNS names, node IPs as required).
  • Issuer: Confirm certificates are issued by the expected CA (e.g., the kubeadm CA or an organization CA).
  • Validity: Certificates must not be expired and should have renewal policies consistent with your security guidelines.
  • Usage flags: Check Key Usage / Extended Key Usage are appropriate (server vs client certificates).
  • Ownership: Confirm organization fields and intended subject match usage (e.g., system:masters for privileged clients).

​
Troubleshooting with logs

TLS-related failures typically show up in component logs. How you collect logs depends on how the control plane runs.
  • systemd-managed components:
  • kubeadm / pod-managed components:
Example TLS error lines:
If the API server or etcd is down and kubectl cannot reach the cluster, fetch container logs from the container runtime: For runtimes with crictl (e.g., containerd):
Example:
Messages like “tls: bad certificate” mean the presented certificate failed validation (mismatched SAN/CN, wrong issuer, or expired certificate).

​
Summary

  • Determine how the control plane is launched (systemd vs static pods).
  • Extract certificate file paths from service unit files or static pod manifests.
  • Inspect certificates with openssl to verify CN, SANs, issuer, key usage, and expiration.
  • Create and maintain a certificate inventory for proactive rotation.
  • Use journalctl, kubectl logs, or crictl logs to diagnose TLS handshake failures.
Further reading:

Watch Video