TLS in Kubernetes Certificate Creation

In this lesson you’ll learn how to create the TLS certificates required for a Kubernetes cluster using OpenSSL. While there are several tooling options (Easy-RSA, CFSSL, OpenSSL, etc.), this guide demonstrates concepts and examples using OpenSSL so you can understand the certificate types, common fields (CN/OU), and SANs required by Kubernetes components. Tools & references:

CA (Certificate Authority)

The cluster CA signs all other cluster certificates. Keep its private key secret and backed up: losing the CA key prevents signing new certs and can complicate cluster recovery.

Protect your CA private key (ca.key). If it is compromised, all certificates signed by that CA must be revoked and reissued. Use strict filesystem permissions and consider storing the CA key in a secure secret management system.

Generate the CA private key, then a CSR and a self-signed root certificate:

# generate CA private key
openssl genrsa -out ca.key 2048

# generate CA CSR (Common Name = KUBERNETES-CA)
openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr

# self-sign the CA CSR to produce the root certificate (10 years)
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt -days 3650

Important: ensure the root certificate contains the Basic Constraints CA:TRUE. Use an OpenSSL config with a v3_ca section or pass -extensions/-extfile when creating a CA certificate so TLS clients treat it as a CA.

The image is a diagram titled "Certificate Authority (CA)" showing a decorative certificate labeled "KUBERNETES_CA" flanked by UI buttons for ca.key, ca.csr and ca.crt. To the right are actions like "Generate Keys," "Certificate Signing Request," and "Sign Certificates."

Client certificates (users and system components)

Client certificates authenticate users and components to the API server and etcd. The certificate Common Name (CN) identifies the user or component in audit logs and RBAC. For example, to make a user a cluster admin include OU=system:masters in the CSR. Generate an admin client certificate signed by your CA:

# generate admin private key
openssl genrsa -out admin.key 2048

# generate admin CSR with CN and OU (group)
openssl req -new -key admin.key -subj "/CN=kubernetes-admin/OU=system:masters" -out admin.csr

# sign the admin CSR with the CA
openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out admin.crt -days 365

You can use the certificate pair with curl or kubectl. Example: curl using the client certs (API server must be reachable at the host/port shown):

curl https://kube-apiserver:6443/api/v1/pods \
  --key admin.key --cert admin.crt --cacert ca.crt

Minimal kubeconfig snippet for kubectl using the admin cert:

apiVersion: v1
kind: Config
clusters:
- name: kubernetes
  cluster:
    certificate-authority: ca.crt
    server: https://kube-apiserver:6443
users:
- name: kubernetes-admin
  user:
    client-certificate: admin.crt
    client-key: admin.key

Common certificate file naming (examples):

File(s)	Purpose
`ca.key`, `ca.crt`	Root CA private key and certificate (signs cluster certs)
`admin.key`, `admin.crt`	Client cert/key for an admin user (CN=kubertenes-admin)
`apiserver.key`, `apiserver.crt`	kube-apiserver server certificate (must include SANs)
`kubelet.key`, `kubelet.crt`	Per-node kubelet server certificate (CN or SAN identifies node)
`etcdserver.key`, `etcdserver.crt`	etcd server certificate for HTTPS endpoint

A diagram showing Kubernetes client and server TLS certificates, with labeled certificate/key filenames (e.g., admin.crt/admin.key, apiserver.crt/apiserver.key) grouped by components like kube-apiserver, kubelet, etcd and kube-proxy. Icons and green checkmarks indicate status or completion for each certificate pair.

etcd server certificates

etcd requires TLS for both client-server and peer-to-peer communication. Create a server certificate for the etcd HTTPS endpoint and separate peer certificates for inter-member TLS if running an HA cluster. Configure etcd to require client certs (mutual TLS) so only trusted clients signed by your CA can connect. Representative etcd flags and their purpose:

Flag	Purpose
`--cert-file`	Path to etcd server certificate (serves HTTPS)
`--key-file`	Path to etcd server private key
`--client-cert-auth`	Require client certificate authentication for clients
`--trusted-ca-file`	CA cert to validate client certs
`--peer-cert-file`	Peer certificate for member-to-member TLS
`--peer-key-file`	Peer private key
`--peer-client-cert-auth`	Require client certs for peer connections
`--peer-trusted-ca-file`	CA to validate peer certs

Example etcd configuration flags (provide correct paths for your environment):

# example etcd configuration flags
- --advertise-client-urls=https://127.0.0.1:2379
- --key-file=/path-to-certs/etcdserver.key
- --cert-file=/path-to-certs/etcdserver.crt
- --client-cert-auth=true
- --trusted-ca-file=/path-to-certs/ca.crt
- --peer-cert-file=/path-to-certs/etcdpeer1.crt
- --peer-key-file=/path-to-certs/etcdpeer1.key
- --peer-client-cert-auth=true
- --peer-trusted-ca-file=/path-to-certs/ca.crt
- --data-dir=/var/lib/etcd
- --initial-advertise-peer-urls=https://127.0.0.1:2380
- --initial-cluster=master=https://127.0.0.1:2380
- --listen-client-urls=https://127.0.0.1:2379
- --listen-peer-urls=https://127.0.0.1:2380
- --name=master
- --snapshot-count=10000

kube-apiserver certificate (server certificate with SANs)

The kube-apiserver certificate must include every DNS name and IP address clients use to reach the API server in the Subject Alternative Names (SANs). Common names include kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local and the cluster IP (e.g., 10.96.0.1) and node IPs. Generate the API server key, CSR using an OpenSSL config containing SANs, and sign with the CA:

# generate apiserver private key
openssl genrsa -out apiserver.key 2048

# generate CSR using an openssl.cnf that defines subjectAltName
openssl req -new -key apiserver.key -subj "/CN=kube-apiserver" -out apiserver.csr -config openssl.cnf

# sign the CSR with the CA and include SANs via v3_req extensions
openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out apiserver.crt -extensions v3_req -extfile openssl.cnf -days 1000

Example openssl.cnf fragment specifying SANs:

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = 10.96.0.1
IP.2 = 172.17.0.87

Always list all relevant hostnames and IPs in alt_names. Modern TLS implementations prioritise SANs over CN and will reject certs that lack correct SAN entries.

A stylized certificate graphic labeled "Kube-api Server" showing certificate details, IPs and encoded text. The left side displays a box with icons for apiserver.crt and apiserver.key.

kube-apiserver runtime flags and certificate locations

When starting the kube-apiserver, supply the CA and server certificate/key, plus any client certificates the API server uses to connect to etcd and kubelets. Example systemd ExecStart snippet (paths correspond to the certificate files above):

ExecStart=/usr/local/bin/kube-apiserver \
  --advertise-address=${INTERNAL_IP} \
  --allow-privileged=true \
  --apiserver-count=3 \
  --authorization-mode=Node,RBAC \
  --bind-address=0.0.0.0 \
  --enable-swagger-ui=true \
  --etcd-cafile=/var/lib/kubernetes/ca.crt \
  --etcd-certfile=/var/lib/kubernetes/apiserver-etcd-client.crt \
  --etcd-keyfile=/var/lib/kubernetes/apiserver-etcd-client.key \
  --etcd-servers=https://127.0.0.1:2379 \
  --event-ttl=1h \
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.crt \
  --kubelet-client-certificate=/var/lib/kubernetes/apiserver-kubelet-client.crt \
  --kubelet-client-key=/var/lib/kubernetes/apiserver-kubelet-client.key \
  --kubelet-https=true \
  --runtime-config=api/all \
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \
  --service-cluster-ip-range=10.32.0.0/24 \
  --service-node-port-range=30000-32767 \
  --client-ca-file=/var/lib/kubernetes/ca.crt \
  --tls-cert-file=/var/lib/kubernetes/apiserver.crt \
  --tls-private-key-file=/var/lib/kubernetes/apiserver.key \
  --v=2

Note: the API server needs the CA (--client-ca-file) to verify client (user/component) certificates and it also supplies its own server certificate (--tls-cert-file) to clients.

kubelet server and client certificates (per-node)

Each kubelet exposes an HTTPS endpoint on the node and therefore requires a server certificate that identifies the node (CN or SAN). Kubelets also act as clients (when making requests to the API server) and need client certs. Use the system:node:<nodeName> CN format and include the system:nodes group in OU for node client certs. Example subject for a node client certificate:

/CN=system:node:node01/OU=system:nodes

Generate per-node server and client certs for each node (node01, node02, node03) and place the cert/key pairs plus ca.crt into the kubelet kubeconfig or provide them via kubelet flags.

An infographic showing Kubernetes "kubectl Nodes (Server Certificates)" with three nodes (node01, node02, node03), each displaying a certificate image and kubelet components. The top also highlights kubelet.crt and kubelet.key used by the kubelet server.

After generating node client certs, include them in the kubeconfig used by each kubelet so kubelets authenticate to the API server as a node identity.

A Kubernetes diagram showing kubelet client certificates. It depicts a kubelet server with kubelet-client.crt/.key and three node certificates labeled system:node:node01, node02, and node03, each tied to a kubelet.

Inspecting certificates

To view certificate details (SANs, issuer, validity), use OpenSSL:

# view certificate details and SANs
openssl x509 -in apiserver.crt -text -noout

# or view CSR details
openssl req -in apiserver.csr -text -noout

Final notes

Distribute the CA root certificate (ca.crt) to every component that must validate certificates.
Restrict access to private keys and use secure storage or secret management where possible.
Always include all DNS names and IP addresses in SANs for server certificates — modern clients require SANs.
Rotate certificates before expiration and maintain a certificate inventory.

Always include the correct Subject Alternative Names (SANs) in server certificates. Many TLS clients reject certificates that only set the CN and omit SANs.

References

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

TLS in Kubernetes Certificate Creation

CA (Certificate Authority)

Client certificates (users and system components)

etcd server certificates

kube-apiserver certificate (server certificate with SANs)

kube-apiserver runtime flags and certificate locations

kubelet server and client certificates (per-node)

Inspecting certificates

Final notes

Watch Video

​CA (Certificate Authority)

​Client certificates (users and system components)

​etcd server certificates

​kube-apiserver certificate (server certificate with SANs)

​kube-apiserver runtime flags and certificate locations

​kubelet server and client certificates (per-node)

​Inspecting certificates

​Final notes

Watch Video

CA (Certificate Authority)

Client certificates (users and system components)

etcd server certificates

kube-apiserver certificate (server certificate with SANs)

kube-apiserver runtime flags and certificate locations

kubelet server and client certificates (per-node)

Inspecting certificates

Final notes