SSL/TLS Fundamentals

The cryptographic protocol that secures the modern internet — from browser connections to Kubernetes API servers. Synthesized from TLS Explained Simply.

What Is TLS?

TLS (Transport Layer Security) is the successor to SSL (Secure Sockets Layer). It is a protocol that operates between the transport layer (TCP) and the application layer (HTTP), providing three security guarantees:

Guarantee	What It Means	Attack It Prevents
Encryption	Only the intended recipient can read the data	Eavesdropping, packet sniffing
Authentication	The client verifies the server’s identity	Man-in-the-middle, impersonation
Integrity	Data cannot be altered in transit without detection	Tampering, replay attacks

Terminology Note: SSL 2.0 and 3.0 are deprecated and insecure. All modern systems use TLS 1.2 or TLS 1.3. In practice, people still say “SSL certificate” when they mean “TLS certificate.” Source: CKA Day 20

---

The TLS Handshake

Before any application data is exchanged, the client and server perform a handshake to negotiate encryption parameters and authenticate each other.

TLS 1.2 Handshake (Full)

Client                                          Server
   │                                               │
   │────── ClientHello ────────────────────────────▶│
   │  (TLS version, supported cipher suites,       │
   │   random nonce, compression methods)           │
   │                                               │
   │◀───── ServerHello ────────────────────────────│
   │  (Chosen TLS version & cipher suite,          │
   │   server random nonce)                         │
   │◀───── Certificate ─────────────────────────────│
   │  (Server's X.509 certificate chain)            │
   │◀───── ServerKeyExchange (optional) ──────────│
   │  (For DHE/ECDHE key exchange)                  │
   │◀───── ServerHelloDone ────────────────────────│
   │                                               │
   │────── ClientKeyExchange ──────────────────────▶│
   │  (Pre-master secret encrypted with server's    │
   │   public key)                                  │
   │────── ChangeCipherSpec ───────────────────────▶│
   │  ("I will now use encrypted communication")    │
   │────── Finished (encrypted handshake hash) ────▶│
   │                                               │
   │◀───── ChangeCipherSpec ───────────────────────│
   │◀───── Finished ───────────────────────────────│
   │                                               │
   │========== Encrypted Application Data ==========│

TLS 1.3 Handshake (Simplified)

TLS 1.3 reduces the handshake to a single round trip (1-RTT) by combining key exchange with the initial hello:

Client                                          Server
   │                                               │
   │────── ClientHello + KeyShare ─────────────────▶│
   │                                               │
   │◀───── ServerHello + KeyShare + EncryptedExt ──│
   │◀───── {Certificate + Finished} ───────────────│
   │  (Everything after ServerHello is encrypted)    │
   │                                               │
   │────── {Finished + Application Data} ────────────▶│

Key Improvement: In TLS 1.3, the server’s certificate is already encrypted, and the handshake completes in one fewer round trip. This improves both speed and privacy.

---

Cryptographic Building Blocks

Asymmetric Cryptography (Public/Private Keys)

Aspect	Detail
Keys	Two mathematically related keys: public (shared freely) and private (kept secret)
Encryption	Anyone can encrypt with the public key; only the private key holder can decrypt
Authentication	Only the private key holder can sign; anyone with the public key can verify the signature
Algorithms	RSA (legacy), ECDSA (elliptic curve, faster, smaller keys), Ed25519 (modern)
Speed	Slow — used only during the handshake

Symmetric Cryptography (Shared Secret)

Aspect	Detail
Keys	One key shared between both parties after the handshake
Encryption	Same key encrypts and decrypts
Algorithms	AES-GCM, AES-CBC, ChaCha20-Poly1305
Speed	Fast — used for all bulk data encryption during the session

Why Both?

Asymmetric cryptography solves the key distribution problem (how do two strangers agree on a secret?), but it is too slow for encrypting large amounts of data. TLS uses asymmetric crypto only to bootstrap the connection; once both sides agree on a shared symmetric key, all application data flows over fast symmetric encryption.

---

Certificates and the PKI Ecosystem

What Is a TLS Certificate?

A TLS certificate is a digital document that binds a public key to an identity (domain name, organization name). It follows the X.509 standard and contains:

Field	Purpose
Subject	Identity of the certificate owner (CN, O, OU, L, ST, C)
Subject Alternative Name (SAN)	List of DNS names and IP addresses the certificate is valid for
Public Key	The owner’s public key for encryption/verification
Issuer	The Certificate Authority that signed this certificate
Validity Period	Not Before / Not After dates
Serial Number	Unique identifier for revocation tracking
Signature	The CA’s digital signature proving authenticity

Certificate Authorities (CAs)

A Certificate Authority is a trusted organization that signs certificates, vouching that the public key belongs to the claimed identity.

CA Type	Examples	Use Case
Public CAs	Let’s Encrypt, DigiCert, Sectigo	Public-facing websites and APIs
Private/Enterprise CAs	Active Directory Certificate Services, HashiCorp Vault	Internal services, microservices mTLS
Self-Signed	Generated with openssl req -x509	Development, testing, controlled trust stores

The Trust Chain

┌─────────────────┐
│   Root CA       │  ← Trusted by browsers/OS (pre-installed)
│   (Self-signed) │
└────────┬────────┘
         │ signs
┌────────▼────────┐
│ Intermediate CA  │
└────────┬────────┘
         │ signs
┌────────▼────────┐
│  Server Cert     │  ← Presented by the website/API
│  (example.com)   │
└─────────────────┘

Validation steps:

1. Server presents its certificate + any intermediate certificates
2. Client builds a chain from the server cert up to a trusted root CA
3. Client verifies each signature in the chain
4. Client checks expiry, hostname match (SAN), and revocation status (CRL/OCSP)

Self-Signed Certificates

A self-signed certificate is signed by its own private key rather than a CA. No third party vouches for it.

# Generate a self-signed certificate
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
  -days 365 -nodes -subj "/CN=localhost"

Use Case	Rationale
Development / Local testing	No public CA needed; add to local trust store
Kubernetes bootstrap	kubeadm generates a self-signed CA for cluster internal trust
Private PKI	You control the trust store (enterprise CA replacement)

Warning: Browsers and standard HTTP clients reject self-signed certificates unless explicitly configured to trust them. Never use self-signed certs for public-facing production services.

X.509 Client Certificates for Kubernetes Authentication

Kubernetes uses X.509 client certificates as a primary authentication mechanism. When a user presents a client certificate signed by the cluster CA, the API server extracts the Common Name (CN) as the username and the Organization (O) as the group membership. This is the default authentication method for kubeadm clusters and is critical for the CKA exam.

Client certificate generation pattern (CKA):

# 1. Generate private key
openssl genrsa -out alice.key 2048
 
# 2. Create CSR with CN and O fields
openssl req -new -key alice.key -out alice.csr \
  -subj "/CN=alice/O=developers"
 
# 3. Sign with cluster CA (or submit as Kubernetes CSR)
openssl x509 -req -in alice.csr -CA /etc/kubernetes/pki/ca.crt \
  -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial \
  -out alice.crt -days 365

The resulting alice.crt and alice.key are then referenced in the kubeconfig user’s client-certificate-data and client-key-data fields. See Kubernetes Kubeconfig for the full client credential configuration. Source: CKA Day 22

---

TLS in Kubernetes

TLS is woven throughout the Kubernetes control plane and data plane:

Component	TLS Role
kube-apiserver	Serves HTTPS on port 6443; validates client certificates from kubelets and users
etcd	Peer-to-peer TLS between etcd members; client TLS for API server connections. The same certificates authenticate etcdctl snapshot save/restore commands.
kubelet	Uses client certificates (issued by cluster CA) to authenticate to the API server
kube-controller-manager / kube-scheduler	Communicate with API server over HTTPS with client certs
Ingress Controllers	Terminate TLS at the cluster edge; route plain HTTP to backend Services
Service Mesh (Istio/Linkerd)	mTLS between all Pod-to-Pod traffic inside the cluster
kubernetes.io/tls Secret	Stores certificate + key pairs for Ingress, webhooks, and admission controllers

Kubernetes TLS Secret Type

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTi...  # base64-encoded certificate
  tls.key: LS0tLS1CRUdJTi...   # base64-encoded private key

Exam Tip: The tls.crt field must contain the full certificate chain (server cert + intermediates), not just the leaf certificate. Source: CKA Day 19

---

Cipher Suites

A cipher suite is a named combination of algorithms used during the handshake and session:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
│     │    │   │    │      │     │
│     │    │   │    │      │     └── MAC / PRF algorithm
│     │    │   │    │      └──────── Symmetric encryption mode
│     │    │   │    └─────────────── Symmetric encryption algorithm
│     │    │   └──────────────────── Key exchange algorithm
│     │    └──────────────────────── Authentication (signature) algorithm
│     └───────────────────────────── Key exchange type (Ephemeral Diffie-Hellman)
└─────────────────────────────────── Protocol version

Modern recommendations:

• Prefer ECDHE or DHE for forward secrecy (ephemeral keys — compromise of long-term key does not decrypt past sessions)
• Prefer AES-GCM or ChaCha20-Poly1305 for authenticated encryption
• Avoid RSA key exchange (no forward secrecy) and CBC modes (padding oracle risks)

TLS 1.3 simplifies this by eliminating obsolete cipher suites entirely and offering only a small, modern set.

---

Certificate Management Tools

Tool	Purpose
openssl	Swiss army knife: generate keys, CSRs, certificates, inspect PEM files
cert-manager	Kubernetes-native certificate provisioning (Let’s Encrypt, Vault, self-signed)
Let’s Encrypt	Free, automated public CA with ACME protocol
cfssl / cfssljson	CloudFlare’s PKI toolkit — popular in Kubernetes bootstrap scripts
HashiCorp Vault	Dynamic secrets, PKI engine for internal certificate issuance

Essential openssl Commands

# Inspect a certificate
openssl x509 -in cert.pem -text -noout
 
# Check expiry date
openssl x509 -in cert.pem -noout -dates
 
# Verify certificate chain
openssl verify -CAfile ca.crt -untrusted intermediate.crt server.crt
 
# Generate a private key + CSR
openssl req -newkey rsa:2048 -keyout key.pem -out csr.pem -nodes
 
# Check which certificate a server presents
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -text -noout

---

TLS Version Evolution

Version	Year	Status
SSL 1.0	1994	Never publicly released
SSL 2.0	1995	Deprecated, insecure
SSL 3.0	1996	Deprecated (POODLE attack)
TLS 1.0	1999	Deprecated (BEAST attack)
TLS 1.1	2006	Deprecated
TLS 1.2	2008	Widely supported; minimum acceptable today
TLS 1.3	2018	Latest; faster handshake, fewer cipher suites, encrypted SNI

---

Troubleshooting Matrix

Symptom	Likely Cause	Diagnostic
curl: (60) SSL certificate problem	Self-signed or expired cert; missing CA in trust store	openssl s_client -connect host:443
x509: certificate has expired	Certificate past Not After date	openssl x509 -in cert.pem -noout -dates
x509: certificate signed by unknown authority	Missing intermediate CA in chain; untrusted root	openssl verify -CAfile ca.crt cert.pem
x509: certificate is valid for ...	Hostname mismatch (SAN/CN does not match URL)	openssl x509 -in cert.pem -noout -subject -ext subjectAltName
Kubernetes API server unreachable	Expired API server certificate	Check /etc/kubernetes/pki/apiserver.crt expiry
Pod ImagePullBackOff with registry	Registry TLS cert expired/invalid	openssl s_client -connect registry:443

---

CKA Exam Relevance

While the CKA exam does not require building a CA from scratch, TLS appears in multiple exam tasks:

• Cluster Architecture (~25%): Understand that API server, etcd, and kubelets all use TLS certificates stored in /etc/kubernetes/pki/
• Troubleshooting (~30%): Expired certificates are a common failure mode. Know how to check certificate validity with openssl
• Workloads: kubernetes.io/tls Secrets are used for Ingress and admission webhooks
• Certificate rotation: kubeadm-managed clusters store certs in /etc/kubernetes/pki/; know how to renew them

---

Related Pages

• Kubernetes Architecture — API server, etcd, kubelet TLS communication flows
• Kubernetes ConfigMaps and Secrets — kubernetes.io/tls Secret type for cert + key storage
• Sidecar Pattern — TLS termination sidecars (Envoy, nginx, Istio)
• Kubernetes Health Probes — HTTPS scheme for secure health checks
• Client-Server Architecture — HTTPS as the secured application layer protocol
• Zero Trust Access — mTLS and identity-aware security patterns
• AI Security — Securing AI-generated code pipelines with TLS
• Security Index — Broader security domain
• CKA Certification — Exam domains where TLS knowledge is tested
• CKA Study Roadmap — Day 20: SSL/TLS Fundamentals
• TLS Explained Simply — Source video

---

Kubernetes Certificate Management

Practical certificate operations inside a Kubernetes cluster — CertificateSigningRequests, kubeadm PKI, and certificate renewal. Synthesized from CKA Day 21 — Manage TLS Certificates In a Kubernetes Cluster.

The Kubernetes PKI Directory

kubeadm bootstraps a complete PKI under /etc/kubernetes/pki/:

File	Purpose
ca.crt / ca.key	Cluster root CA — signs all component certificates
apiserver.crt / apiserver.key	API server HTTPS serving cert (port 6443)
apiserver-kubelet-client.crt / .key	API server client cert for kubelet auth
etcd/ca.crt / etcd/ca.key	etcd’s independent CA
etcd/server.crt / .key	etcd server serving cert
etcd/peer.crt / .key	etcd peer-to-peer mTLS
front-proxy-ca.crt / .key	Aggregator proxy CA (for extension API servers)
sa.pub / sa.key	ServiceAccount token signing key pair

Exam Trap: /etc/kubernetes/pki/ is owned by root with 600/644 permissions. If you accidentally delete ca.key, you cannot sign new certificates and must rebuild the PKI from scratch. Source: CKA Day 21

The CertificateSigningRequest (CSR) API

Kubernetes has a native CSR object (certificates.k8s.io/v1) that lets users or automation request signed certificates without direct access to the CA private key.

Use cases:

• Onboarding new kubectl users with client certificates
• Issuing certs for admission webhooks or custom controllers
• Automating kubelet client certificate rotation

The CSR lifecycle:

User                        Kubernetes API              CA Signer
  │                              │                         │
  │── Generate key + CSR ──────▶│                         │
  │── Create CSR object ────────▶│                         │
  │                              │─── Pending ─────────────▶│
  │                              │◀── Admin approves ───────│
  │◀── Retrieve signed cert ────│◀── Signed cert stored ──│

Creating and Approving a CSR (CKA Pattern)

# 1. Generate private key
openssl genrsa -out developer.key 2048
 
# 2. Create CSR with CN and O fields
openssl req -new -key developer.key -out developer.csr \
  -subj "/CN=developer/O=engineering"
 
# 3. Base64 encode the CSR (remove newlines for YAML)
cat developer.csr | base64 | tr -d '\n'
 
# 4. Create the Kubernetes CSR object
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: developer-csr
spec:
  request: <base64-encoded-csr>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
  expirationSeconds: 86400  # 1 day
EOF
 
# 5. Check status
kubectl get csr developer-csr
 
# 6. Approve (admin action)
kubectl certificate approve developer-csr
 
# 7. Extract the signed certificate
kubectl get csr developer-csr -o jsonpath='{.status.certificate}' \
  | base64 -d > developer.crt

Signer Names

Kubernetes 1.19+ requires an explicit signerName. Built-in signers:

Signer Name	Issues	Best For
kubernetes.io/kube-apiserver-client	Client certificates	Human users, service accounts, webhook clients
kubernetes.io/kube-apiserver-client-kubelet	Client certificates	Kubelet client auth (auto-rotated)
kubernetes.io/kubelet-serving	Serving certificates	Kubelet HTTPS serving (server auth)
kubernetes.io/legacy-unknown	Legacy compatibility	Avoid in production

Exam Trap: A CSR without a valid signerName will not be processed. If kubectl get csr shows Pending indefinitely, check that signerName is set correctly. Source: CKA Day 21

Certificate Expiry and Renewal

Check expiry (essential exam skill):

# All kubeadm-managed certificates
kubeadm certs check-expiration
 
# Single certificate with openssl
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates
 
# Decode and inspect
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

Renew certificates:

# Renew all certificates
kubeadm certs renew all
 
# Renew a specific certificate
kubeadm certs renew apiserver
kubeadm certs renew apiserver-kubelet-client
kubeadm certs renew front-proxy-client

Critical Step: After renewing API server, etcd, or controller-manager certificates, you must restart the corresponding static Pod so it picks up the new certificate files from disk. kubelet auto-restarts static Pods when their manifest changes, but if only the cert file changed, you may need to move the manifest out and back in, or restart the node. Source: CKA Day 21

Auto-approval: In managed Kubernetes (EKS, GKE, AKS), node certificate bootstrapping uses the Node auto-approval controller. New nodes request a kubelet client cert via CSR; the controller approves it automatically if the node is authorized.

From Signed Certificate to TLS Secret

After extracting a signed certificate, store it in a Secret for workload consumption:

# From PEM files
kubectl create secret tls my-tls-secret --cert=developer.crt --key=developer.key
 
# The Secret appears as:
# type: kubernetes.io/tls
# data:
#   tls.crt: <base64 cert>
#   tls.key: <base64 key>

Ingress controllers, admission webhooks, and custom operators all consume kubernetes.io/tls Secrets. See Kubernetes ConfigMaps and Secrets for the full Secret type catalog.

---

Related Pages

• Kubernetes Architecture — API server, etcd, kubelet TLS communication flows and PKI paths
• Kubernetes ETCD Backup and Restore — etcdctl snapshot save/restore commands require mTLS certificate authentication using the same PKI
• Kubernetes ConfigMaps and Secrets — kubernetes.io/tls Secret type for cert + key storage
• Kubernetes Static Pods — Control plane components run as Static Pods that must restart to load renewed certs
• Sidecar Pattern — TLS termination sidecars (Envoy, nginx, Istio)
• Kubernetes Health Probes — HTTPS scheme for secure health checks
• Client-Server Architecture — HTTPS as the secured application layer protocol
• Zero Trust Access — mTLS and identity-aware security patterns
• AI Security — Securing AI-generated code pipelines with TLS
• Security Index — Broader security domain
• CKA Certification — Exam domains where TLS and CSR knowledge is tested
• CKA Study Roadmap — Day 20: SSL/TLS Fundamentals; Day 21: K8s Certificate Management; Day 22: Authentication & Authorization
• Kubernetes Authentication & Authorization — X.509 client certificates as authentication method
• Kubernetes Kubeconfig — Client certificate credential configuration
• TLS Explained Simply — TLS theory prerequisite
• CKA Day 21 — Manage TLS Certificates In a Kubernetes Cluster — CSR API and kubeadm PKI
• CKA Day 22 — Kubernetes Authentication and Authorization Simply Explained — Client cert auth in practice

---

Tags: security tls ssl certificates encryption pki kubernetes cka devops networking openssl csr kubeadm