Understanding SSL/TLS Certificates

Source: Dev.to

The Name Game: SSL vs TLS

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are often used interchangeably, but SSL is effectively dead. It hasn’t been updated since 1996 and is riddled with security vulnerabilities. Everything we use today is actually TLS.

Why do we still hear “SSL” everywhere? It was the first name people learned, so the industry stuck with it for marketing. When you purchase an “SSL Certificate” today, you’re actually getting a certificate that enables TLS.

Think of TLS as a secure tunnel between two computers. When you click Proceed to Payment on a website, TLS creates an encrypted tunnel to transmit your payment information to the payment processor (e.g., Visa or Stripe). Without TLS, anyone could intercept and read that data.

Certificate Authorities (CAs)

In the TLS world, the “immigration officers” that verify a certificate’s legitimacy are called Certificate Authorities. Popular CAs include:

• Let’s Encrypt
• Google Trust Services
• Cloudflare
• DigiCert
• GoDaddy

Generating a Private Key and CSR

# Generate a private key
openssl genrsa -out private.key 2048

# Generate a CSR using the private key
openssl req -new -key private.key -out certificate.csr

• private.key – Keep this SECRET on your server; never share it.
• certificate.csr – Send this to the CA.

Submitting the CSR and Validation

You submit your CSR to a Certificate Authority. They’ll verify:

• Is this a legitimate company?
• Do you actually own/control this domain?
• Is the information accurate?

For domain validation, the CA might ask you to:

• Add a DNS record
• Upload a specific file to your website
• Respond to an email sent to your domain

Received Signed Certificate

After verification, the CA returns a signed certificate with their cryptographic signature—your “stamped passport.”

certificate.crt   # Your signed certificate
ca-bundle.crt     # The CA's chain of trust

Server Configuration

Nginx

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;

    # Modern TLS configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

Apache

ServerName yourdomain.com

SSLEngine on
SSLCertificateFile /path/to/certificate.crt
SSLCertificateKeyFile /path/to/private.key
SSLCertificateChainFile /path/to/ca-bundle.crt

TLS Handshake Overview

1. Client Hello – Browser says “I want to connect securely.”
2. Server Hello – Server responds with its certificate (signed by the CA).
3. Certificate Verification – Browser checks if the certificate is signed by a trusted CA.
4. Key Exchange – Both parties agree on encryption keys for the session.
5. Encrypted Communication – All data flows through the secure tunnel.

Example HTTPS Request (JavaScript)

fetch('https://api.example.com/payment', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    cardNumber: '4242424242424242',
    amount: 99.99
  })
});

TLS encrypts everything in that request body automatically. Without TLS, anyone on the network could read your card number.

TLS vs. No TLS

• ❌ Passwords sent in plain text

• ❌ Credit cards visible to attackers

• ❌ Session tokens can be stolen

• ❌ Data can be modified in transit

• ✅ Everything encrypted end‑to‑end

• ✅ Authenticity verified by CAs

• ✅ Protection from man‑in‑the‑middle attacks

• ✅ The reassuring padlock in the browser

Installing Certbot

# Install Certbot
sudo apt install certbot python3-certbot-nginx

# Get a certificate and auto‑configure Nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Auto‑renewal is set up automatically (certificates are valid for 90 days)

That’s it. You now have TLS up and running, and your users can browse safely through that secure tunnel.