SSL/TLS Certificates — The DevOps Engineer's Complete Guide

SSL/TLS Explained — What Every DevOps Engineer Actually Needs to Know

You've probably typed https:// a thousand times without thinking about it. That little "s" is doing a lot of heavy lifting behind the scenes. And as a DevOps engineer, understanding what's happening there isn't optional — because at some point, a cert will expire on your watch, a service will throw a handshake error at 2am, or someone will ask you why traffic isn't encrypted between two microservices.

This post covers SSL/TLS from the ground up — what it is, how it works, where it shows up in real DevOps setups, and what you genuinely need to know to handle it confidently.

---

First Things First — SSL Is Dead (Sort Of)

Technically, we don't use SSL anymore. SSL (Secure Sockets Layer) had multiple versions and all of them are now deprecated because of known security vulnerabilities. What we actually use today is TLS — Transport Layer Security.

But the name SSL stuck around. When someone says "SSL certificate" or "set up SSL for your server," they almost always mean TLS. Don't let that confuse you. When you see SSL, read TLS.

Current versions that matter:

• TLS 1.2 — still widely used, acceptable

• TLS 1.3 — latest, fastest, most secure. Prefer this wherever possible

• TLS 1.0 and 1.1 — deprecated, disabled in most modern browsers. Never use these

---

What SSL/TLS Actually Does

At its core, TLS does three things:

1. Encryption — scrambles the data so nobody intercepting the connection can read it

2. Authentication — proves the server is actually who it claims to be

3. Integrity — ensures the data wasn't tampered with in transit

Without TLS, any data sent between a browser and a server travels in plain text. Passwords, credit card numbers, session tokens — all readable by anyone watching the network. That's obviously a problem.

---

The TLS Handshake — What Happens Before Any Data Moves

Every time you open a site over HTTPS, a handshake happens in milliseconds before any actual content loads. Here's the short version:

1. Your browser says: "Hey, I want to connect securely. Here's what encryption methods I support."

2. The server replies: "Here's my SSL certificate. Here are the encryption methods I support."

3. Your browser checks: "Is this certificate valid? Is it issued by someone I trust? Does it match this domain?"

4. If everything checks out, both sides agree on an encryption key

5. From this point, all data is encrypted

That certificate the server sends in step 2 is the "SSL certificate" everyone talks about. Think of it as the server's ID card — it proves the server is legitimate and contains the public key needed to start the encrypted session.

---

Types of Certificates

By Validation Level:

• DV (Domain Validated) — the CA just checks that you control the domain. Cheapest and fastest to get. This is what Let's Encrypt issues, and it's perfectly fine for most websites and DevOps infrastructure

• OV (Organization Validated) — the CA verifies your organization details too. Used by companies that want to display more trust signals

• EV (Extended Validation) — strictest check. Historically showed a green company name in the browser bar. Banks and financial institutions typically use these

For most DevOps use cases — your apps, your pipelines, your internal services — DV certificates work fine.

By Coverage:

• Single Domain — covers only yourdomain.com

• Wildcard — covers *.yourdomain.com, so app.yourdomain.com, api.yourdomain.com, staging.yourdomain.com — all covered with one cert

• SAN / Multi-Domain — one cert covers multiple completely different domains

---

Where SSL Shows Up in DevOps

This isn't just a "website thing." SSL/TLS is everywhere in modern infrastructure:

Web Servers — Nginx, Apache, IIS all need SSL config to serve HTTPS traffic. This is the most common scenario you'll deal with.

Load Balancers — SSL termination usually happens here. The load balancer handles the encryption/decryption, then forwards plain HTTP to your backend services. This is called SSL termination.

Kubernetes Ingress — In a K8s cluster, your Ingress controller (usually Nginx Ingress) handles SSL. You pair it with cert-manager to automatically issue and renew Let's Encrypt certificates for your services.

CI/CD Pipelines — Your pipeline connects to GitHub, DockerHub, AWS, and other services over HTTPS. If there's a certificate issue in any of these connections, your pipeline breaks.

Microservice-to-Microservice Communication — Services talking to each other internally may or may not use encryption. In zero-trust architectures, they do — using mTLS (more on this below).

APIs — Every API endpoint exposed to the internet should run over HTTPS. Non-negotiable.

---

5 -Things Every DevOps Engineer Must Know

1. Cert Expiry Will Break Production — Automate Renewal

SSL certificates expire. Let's Encrypt certs expire every 90 days. Paid certs typically last 1 year. When a cert expires, browsers show a scary warning and users can't access your site. Services stop trusting each other.

The fix isn't to manually renew — it's to automate. Use Certbot for Let's Encrypt on your servers. It handles renewal automatically. On AWS, use ACM (AWS Certificate Manager) which auto-renews and integrates directly with ALBs and CloudFront. In Kubernetes, cert-manager handles everything.

Set a calendar reminder anyway. Automation can fail. You don't want to find out from a user.

2. Always Force HTTP → HTTPS Redirect

Getting an SSL certificate is step one. Step two is making sure nobody can still access your site over plain HTTP. If you don't redirect, users who type http:// or click an old link get an unencrypted connection.

In Nginx:

nginx

server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://\(host\)request_uri;
}

This one block redirects all HTTP traffic to HTTPS permanently. Simple, but people skip it.

3. HSTS — Lock In HTTPS at the Browser LevelHSTS (HTTP Strict Transport Security) is a response header that tells browsers: "For the next X days, only ever connect to this site over HTTPS. Don't even try HTTP."

nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Once a browser sees this header, it refuses to make plain HTTP requests to your site — even if someone types http://. It's an extra layer on top of your redirect.

4. SSL Termination vs End-to-End Encryption

In most setups, SSL terminates at the load balancer or reverse proxy. Traffic from the load balancer to your backend travels unencrypted inside your private network. For most use cases, that's fine.

But in sensitive environments — healthcare, finance, or high-security systems — you want encryption all the way through. This is where mTLS (Mutual TLS) comes in.

Regular TLS: client verifies the server's identity. mTLS: both sides verify each other. The client also presents a certificate.

mTLS is used heavily in microservice architectures through service meshes like Istio or Linkerd. If you're working with Kubernetes at any serious scale, you'll encounter this.

5. Know How to Debug SSL Issues

Things will break. When they do, this one command tells you almost everything:

bash

openssl s_client -connect yourdomain.com:443

Run it and you'll see:

• Which certificate the server is presenting

• The full certificate chain

• Expiry date

• Any chain trust issues

A few other useful checks:

bash

# Check cert expiry date
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

# Check what TLS versions a server supports
nmap --script ssl-enum-ciphers -p 443 yourdomain.com

Get comfortable with these. They'll save you in incidents.

---

Understanding the CSR Flow

Before any Certificate Authority (CA) issues you a cert, you generate a CSR — Certificate Signing Request. It contains your domain information and your public key. You send the CSR to the CA, they verify you own the domain, and they issue the certificate back.

bash

# Generate a private key and CSR
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

Let's Encrypt automates this whole flow through Certbot, so you rarely do it manually anymore. But in enterprise environments with paid certs, you'll still go through this process. Knowing what a CSR is and why it exists matters when you're troubleshooting or working with a manual cert issuance process.

---

Key Tools You'll Actually Use

Tool	What it does
Certbot	Issues and auto-renews Let's Encrypt certs on Linux servers
AWS ACM	Managed certificates on AWS. Free, auto-renews, integrates with ALB/CloudFront
cert-manager	Kubernetes-native cert automation. Works with Let's Encrypt and other CAs
OpenSSL	The Swiss army knife for generating, inspecting, and debugging certificates
Nginx	Where SSL termination and HTTPS config usually lives

---

Self-Signed Certificates — Use Them Right

A self-signed cert is one you generate yourself without involving any CA. No verification, no trust chain. Browsers will throw a warning because they don't recognize who signed it.

Use them for:

• Local development

• Internal tools where you control every client

• Testing SSL config before getting a real cert

Never use them for:

• Anything exposed to real users

• Production environments

• APIs consumed by third parties

---

Port Numbers — Don't Overlook This

Sounds basic, but misconfigured security groups and firewalls around these ports are a common source of real issues:

• Port 80 — HTTP

• Port 443 — HTTPS

If port 443 is blocked on your security group or firewall, your HTTPS setup won't work even if the cert is perfect. Always verify port access when troubleshooting SSL connectivity issues.

---

Bringing It Together

SSL/TLS is one of those topics that looks straightforward until you're dealing with expired certs in production, mismatched certificate chains, or microservices refusing to talk to each other. Understanding it properly — not just knowing that HTTPS is "secure" — separates engineers who can debug real infrastructure issues from those who can't.

The practical checklist:

• Always use HTTPS, always redirect HTTP

• Automate certificate renewal — don't rely on memory

• Know the difference between SSL termination and end-to-end encryption

• Understand where certs live in your stack — load balancer, Ingress, app server

• Keep OpenSSL commands handy for debugging

That's SSL/TLS. Not as mysterious as it looks, but deep enough that there's always something new to learn when you go further into service meshes and zero-trust networking.