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:

Server presents its certificate + any intermediate certificates
Client builds a chain from the server cert up to a trusted root CA
Client verifies each signature in the chain
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.

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
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

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.

Kubernetes Architecture — API server, etcd, kubelet TLS communication flows and PKI paths
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
TLS Explained Simply — TLS theory prerequisite
CKA Day 21 — Manage TLS Certificates In a Kubernetes Cluster — Source video

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

Rakesh's Brain

Explorer

SSL/TLS Fundamentals

SSL/TLS Fundamentals

What Is TLS?

The TLS Handshake

TLS 1.2 Handshake (Full)

TLS 1.3 Handshake (Simplified)

Cryptographic Building Blocks

Asymmetric Cryptography (Public/Private Keys)

Symmetric Cryptography (Shared Secret)

Why Both?

Certificates and the PKI Ecosystem

What Is a TLS Certificate?

Certificate Authorities (CAs)

The Trust Chain

Self-Signed Certificates

TLS in Kubernetes

Kubernetes TLS Secret Type

Cipher Suites

Certificate Management Tools

Essential openssl Commands

TLS Version Evolution

Troubleshooting Matrix

CKA Exam Relevance

Kubernetes Certificate Management

The Kubernetes PKI Directory

The CertificateSigningRequest (CSR) API

Creating and Approving a CSR (CKA Pattern)

Signer Names

Certificate Expiry and Renewal

From Signed Certificate to TLS Secret

Table of Contents

Graph View

Latest Blog Posts

Backlinks

Rakesh's Brain

Explorer

SSL/TLS Fundamentals

SSL/TLS Fundamentals

What Is TLS?

The TLS Handshake

TLS 1.2 Handshake (Full)

TLS 1.3 Handshake (Simplified)

Cryptographic Building Blocks

Asymmetric Cryptography (Public/Private Keys)

Symmetric Cryptography (Shared Secret)

Why Both?

Certificates and the PKI Ecosystem

What Is a TLS Certificate?

Certificate Authorities (CAs)

The Trust Chain

Self-Signed Certificates

TLS in Kubernetes

Kubernetes TLS Secret Type

Cipher Suites

Certificate Management Tools

Essential openssl Commands

TLS Version Evolution

Troubleshooting Matrix

CKA Exam Relevance

Related Pages

Kubernetes Certificate Management

The Kubernetes PKI Directory

The CertificateSigningRequest (CSR) API

Creating and Approving a CSR (CKA Pattern)

Signer Names

Certificate Expiry and Renewal

From Signed Certificate to TLS Secret

Related Pages

Table of Contents

Graph View

Latest Blog Posts

Backlinks