What is SSL/TLS? Explained Simply for Beginners (2026)

SSL/TLS is mentioned in almost every DevOps context — HTTPS, TLS certificates, cert-manager, Let's Encrypt, mTLS. But the explanation is always either too simple ("it encrypts your traffic") or too complex (cryptography papers).

Here's the practical explanation for DevOps engineers.

What SSL and TLS Are

SSL (Secure Sockets Layer) is the old name. SSL 3.0 was deprecated in 2015. Nobody uses SSL anymore — but the name stuck.

TLS (Transport Layer Security) is what we actually use today. TLS 1.2 and TLS 1.3 are current. When someone says "SSL certificate" or "SSL/TLS," they mean TLS.

TLS does two things:

1. Encryption — encrypts data in transit so nobody can read it
2. Authentication — proves the server is who it claims to be

Why TLS Exists — The Problem It Solves

Without TLS:

Your browser ──── "password=secret123" ────→ myapp.com

Any router, ISP, or attacker between you and the server can read this.

With TLS:

Your browser ──── [🔒 encrypted garbage] ──→ myapp.com
                  only myapp.com can decrypt this

And TLS also proves the server is really myapp.com, not an attacker pretending to be myapp.com.

How the TLS Handshake Works (Simply)

When your browser connects to https://myapp.com:

1. Client Hello
   Browser → Server: "I want TLS 1.3. Here are the cipher suites I support."

2. Server Hello + Certificate
   Server → Browser: "Let's use TLS 1.3 + AES-256-GCM.
                       Here's my certificate (signed by Let's Encrypt)."

3. Certificate Verification
   Browser checks: Is this certificate signed by a CA I trust?
                   Does the certificate match the domain I'm connecting to?
                   Is it expired?

4. Key Exchange
   Browser + Server: generate a shared secret key using asymmetric cryptography
                     (the server's public key is in the certificate)

5. Encrypted Communication
   All further data encrypted with the shared secret key

After the handshake (~1 round trip in TLS 1.3), everything is encrypted.

What a Certificate Contains

A TLS certificate is a file (usually .crt or .pem) that contains:

Certificate:
    Subject: CN=myapp.com           ← This cert is for this domain
    Issuer: Let's Encrypt           ← Signed by this Certificate Authority
    Valid from: 2026-01-01          ← Start date
    Valid until: 2026-04-01         ← Expiry (Let's Encrypt = 90 days)
    Public Key: [RSA 2048-bit key]  ← Used in key exchange
    Subject Alt Names: myapp.com, www.myapp.com, api.myapp.com
    Signature: [Let's Encrypt's digital signature]

The Certificate Authority (CA) signature is what makes the certificate trustworthy. Your browser has a built-in list of trusted CAs (Apple, Google, Mozilla all maintain these lists). Let's Encrypt, DigiCert, Comodo are all trusted CAs.

When the browser sees Let's Encrypt's signature on your certificate, it trusts the certificate — because it trusts Let's Encrypt.

Certificate Types

DV (Domain Validation) — Most common. CA verifies you control the domain. Free with Let's Encrypt.

OV (Organization Validation) — CA verifies your organization's identity. Shows company name in certificate details.

EV (Extended Validation) — Thorough company verification. Used to show a green bar in browsers (no longer does in modern browsers). Mainly for banking.

Wildcard — *.myapp.com covers any subdomain: api.myapp.com, www.myapp.com, etc.

SAN (Subject Alternative Names) — One certificate for multiple domains: myapp.com, api.myapp.com, myapp.io.

For DevOps: DV certificates from Let's Encrypt cover 99% of use cases. Free, automated, trusted everywhere.

Key Files You'll Work With

Certificate chain:
├── certificate.crt     ← Your domain's certificate
├── ca-bundle.crt       ← Intermediate CA certificates (chain)
└── private.key         ← Private key (KEEP THIS SECRET)

Combined formats:
├── fullchain.pem       ← certificate.crt + ca-bundle.crt combined
└── privkey.pem         ← private key

Where these appear in configs:

# Nginx
server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;
}

# Kubernetes Secret
apiVersion: v1
kind: Secret
metadata:
  name: myapp-tls
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded fullchain.pem>
  tls.key: <base64-encoded privkey.pem>

Let's Encrypt and cert-manager on Kubernetes

In Kubernetes, cert-manager automates certificate provisioning and renewal.

# Install cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

# ClusterIssuer — tells cert-manager to use Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: you@yourdomain.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

# Ingress — cert-manager automatically requests and renews the cert
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-tls   # cert-manager creates this Secret automatically
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

cert-manager renews the certificate automatically before expiry. You never manually handle certificates again.

Common TLS Issues DevOps Engineers See

Certificate expired:

# Check certificate expiry
openssl s_client -connect myapp.com:443 -servername myapp.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates
# notAfter=Apr 26 00:00:00 2026 GMT  ← expired!

Certificate doesn't match domain:

SSL: CERTIFICATE_VERIFY_FAILED: hostname 'myapp.com' doesn't match 'api.myapp.com'

The certificate was issued for a different domain. Either get a wildcard cert or add the domain to SAN.

Self-signed certificate warnings:

NET::ERR_CERT_AUTHORITY_INVALID

The certificate isn't signed by a trusted CA. Common in internal services / development. Add the CA to your system trust store or use Let's Encrypt.

Certificate chain incomplete: Some servers send only the leaf certificate, not the full chain. The intermediate CA certificates need to be included in fullchain.pem.

# Verify full chain
openssl s_client -connect myapp.com:443 -showcerts
# Should show 2-3 certificates

TLS 1.3 vs TLS 1.2

TLS 1.3 (released 2018) is significantly better:

• Faster handshake (1 round trip vs 2)
• Removed outdated cipher suites
• Better privacy (forward secrecy built in)

Enable TLS 1.3 in Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers off;

Check what TLS version a server supports:

nmap --script ssl-enum-ciphers -p 443 myapp.com

mTLS — When Both Sides Authenticate

Regular TLS: server proves its identity to the client. mTLS (mutual TLS): both server AND client prove their identities.

Service A → [presents client certificate] → Service B
Service B → [presents server certificate] → Service A
Both verify each other before communicating

Used in:

• Service meshes (Istio, Linkerd) — automatically mutual authentication between microservices
• Internal APIs — only authorized services can connect
• Zero-trust architectures

# Nginx — require client certificate
server {
    listen 443 ssl;
    ssl_certificate     server.crt;
    ssl_certificate_key server.key;
    
    ssl_client_certificate /etc/nginx/ca.crt;  # CA that signed client certs
    ssl_verify_client on;                       # Require client cert
}

SSL/TLS is one of those fundamentals that touches everything in DevOps — Ingress, service meshes, internal APIs, AWS load balancers, S3 endpoints. Understanding the basics (certificates, CAs, the handshake) makes you much faster at debugging connection issues.

For cert-manager deep dive, the cert-manager documentation is excellent and well-maintained.