SSL/TLS Certificates: HTTPS Setup, Let's Encrypt, TLS 1.3

Why HTTPS Is Not an Option, But a Necessity

A site without HTTPS in 2026 is like a store without a lock on the door. Browsers mark such sites as unsafe, Google lowers them in search rankings, and users simply go to competitors.

An SSL/TLS certificate isn't just about encryption. It's about trust. The green padlock in the address bar tells visitors: "it's safe to enter your password and card number here." Without it, conversion drops, especially on eCommerce sites — people are afraid to enter payment data.

Chrome, Firefox, and other browsers show "Not Secure" warnings for HTTP sites. Some corporate networks block access to unprotected resources entirely. And since 2018, Google officially uses HTTPS as a ranking factor.

Good news: setting up SSL/TLS today is easier than ever. Let's Encrypt issues free certificates, Certbot automates the process, and modern web servers have built-in TLS 1.3 support.

In this guide, we'll cover: how TLS 1.3 works, how to get a free certificate through Let's Encrypt, how to properly configure Nginx and Apache, and what HSTS and OCSP Stapling are — things that separate basic configuration from professional.

SSL vs TLS: What's the Difference

SSL (Secure Sockets Layer) is an old protocol that's no longer used. The last version SSL 3.0 was declared insecure back in 2015 due to the POODLE vulnerability. TLS (Transport Layer Security) is its modern successor, which is actively developed.

The term "SSL" stuck and is used as a general name. When people say "SSL certificate," they actually mean a certificate for TLS connection. This is fine — the important thing is understanding that TLS is actually used.

Version history:

• SSL 2.0, 3.0 — outdated, insecure, do not use
• TLS 1.0, 1.1 — deprecated since 2020, browsers don't support them
• TLS 1.2 — acceptable for compatibility with older clients
• TLS 1.3 — recommended standard since 2018, faster and more secure

How Connection Happens (Handshake)

When a user visits an HTTPS site, a "handshake" occurs:

1. Client Hello — browser sends a list of supported ciphers and TLS versions
2. Server Hello — server responds with certificate, chosen cipher, and its public key
3. Verification — browser verifies the certificate through the Certificate Authority (CA)
4. Key Exchange — both parties generate a shared session key
5. Encrypted Connection — all subsequent traffic is encrypted with the session key

TLS 1.3 reduced this process from two "rounds" to one (1-RTT handshake), which reduces latency by 50-100ms on each new connection. For repeat connections, even 0-RTT mode is possible.

Why TLS 1.3 Matters

TLS 1.3 isn't just a "new version." It's a significant improvement in security and speed:

Security:

• Removed outdated ciphers (RC4, DES, MD5)
• All connections use Perfect Forward Secrecy
• Fewer opportunities for downgrade attacks

Speed:

• Handshake in 1 RTT instead of 2 (faster connection establishment)
• 0-RTT resumption for repeat connections
• Less data transmitted during handshake

Which Certificate to Choose

Certificates differ not in encryption level (it's the same), but in the level of owner verification:

DV (Domain Validation)

The simplest type. The Certificate Authority only verifies that you control the domain — via email, DNS record, or HTTP file. Issued automatically in minutes. Let's Encrypt issues exactly these certificates.

OV (Organization Validation)

Additionally verifies the organization's existence: registration documents, address, phone. The process takes 1-3 days. The certificate includes the company name — visible if you click the padlock in the browser.

EV (Extended Validation)

The strictest verification: company's legal status, physical address, signature rights from an authorized person. Previously browsers showed a green address bar with the company name, but since 2019 this visual distinction was removed.

Wildcard Certificates

If you have many subdomains (shop.example.com, blog.example.com, api.example.com, staging.example.com), instead of separate certificates you can get one Wildcard certificate for *.example.com. Let's Encrypt issues them for free, but DNS verification is required.

Important: Wildcard covers only one level of subdomains. *.example.com works for shop.example.com, but not for dev.shop.example.com.

What to Choose?

For 90% of projects, a free DV certificate from Let's Encrypt is sufficient. It provides the same encryption as paid options. The difference is only in the level of organization verification — if you're not a bank and don't process particularly sensitive data, it's not critical.

OV makes sense for companies that want to show their official name in the certificate. EV — for financial organizations and payment systems where maximum trust is critical.

Getting a Certificate via Certbot

Let's Encrypt is a free Certificate Authority created in 2015 to popularize HTTPS. As of 2026, they've issued over a billion certificates and serve more than 300 million sites.

Certbot is the official client for working with Let's Encrypt. It automates obtaining, installing, and renewing certificates.

Installing Certbot

# Ubuntu/Debian
sudo apt update
sudo apt install certbot
# For Nginx
sudo apt install python3-certbot-nginx
# For Apache
sudo apt install python3-certbot-apache
# CentOS/RHEL
sudo dnf install certbot python3-certbot-nginx

Getting a Certificate for Nginx

# Automatic configuration (recommended)
# Certbot will modify Nginx configuration itself
sudo certbot --nginx -d example.com -d www.example.com
# Only get certificate (without changing configuration)
# Useful if you want to configure manually
sudo certbot certonly --nginx -d example.com
# For server without web server (standalone mode)
# Certbot will temporarily run its own server on port 80
sudo certbot certonly --standalone -d example.com

Getting a Certificate for Apache

sudo certbot --apache -d example.com -d www.example.com

Wildcard Certificate

For Wildcard, DNS verification is required (HTTP verification is not supported):

sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d "*.example.com"

Certbot will show a TXT record that needs to be added to your domain's DNS. After adding, press Enter to continue. The certificate will be saved in /etc/letsencrypt/live/example.com/.

Where Certificates Are Stored

/etc/letsencrypt/live/example.com/
├── cert.pem       # Domain certificate
├── chain.pem      # Intermediate certificates
├── fullchain.pem  # cert.pem + chain.pem (use this one!)
└── privkey.pem    # Private key

Configuring Nginx with TLS 1.3

Basic configuration after Certbot works, but it can be improved for maximum security and speed:

server {
    listen 80;
    server_name example.com www.example.com;
    
    # Redirect HTTP → HTTPS
    return 301 https://$server_name$request_uri;
}
server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    
    # Let's Encrypt certificates
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    # Modern protocols
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # Secure ciphers (TLS 1.3 uses its own automatically)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    
    # OCSP Stapling (speeds up certificate verification)
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    
    # SSL sessions (reduces load on repeat connections)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    
    # HSTS (forced HTTPS)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    
    # Rest of configuration...
    root /var/www/example.com;
    index index.html index.php;
}

After changing configuration, verify and reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

Configuring Apache with TLS 1.3

# /etc/apache2/sites-available/example.com.conf
# Redirect HTTP → HTTPS
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>
<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    
    # SSL settings
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    
    # Modern protocols
    SSLProtocol -all +TLSv1.2 +TLSv1.3
    
    # Secure ciphers
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder off
    
    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
    
    # HSTS
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</VirtualHost>

Enable required modules and restart Apache:

sudo a2enmod ssl headers
sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

HSTS: Forced HTTPS

HSTS (HTTP Strict Transport Security) is an HTTP header that tells the browser: "always use HTTPS for this site." Even if a user types http://example.com or clicks an old HTTP link, the browser will automatically switch to HTTPS without requesting the server.

Why this matters:

• Protection from SSL stripping attacks — attacker cannot intercept the first HTTP request and substitute it
• Faster connection — no redirect through server, browser goes directly to HTTPS
• User physically cannot access via HTTP — even if they really want to
• Additional protection — in combination with DDoS protection creates a reliable security perimeter

Configuration:

# Nginx
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
# Apache
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

Parameters:

• max-age=63072000 — 2 years in seconds. Browser will remember this setting for 2 years
• includeSubDomains — apply HSTS to all subdomains
• preload — allows adding domain to browsers' built-in list (see hstspreload.org)

HSTS Preload

There's one problem: on first visit the browser doesn't know about HSTS and makes a regular HTTP request. To close this hole, you can add the domain to the HSTS Preload List — a built-in list in Chrome, Firefox, Safari browsers.

Requirements for preload:

• Valid HTTPS on main domain
• Redirect from HTTP to HTTPS
• HSTS header with max-age at least 1 year, includeSubDomains and preload
• All subdomains must also work via HTTPS

Automatic Certificate Renewal

Let's Encrypt certificates are valid for 90 days. Certbot automatically creates a systemd timer or cron job for renewal, but it's better to verify:

# Check systemd timer
sudo systemctl status certbot.timer
# Or check cron
cat /etc/cron.d/certbot

Manual Renewal Check

# Test run (without actual renewal)
sudo certbot renew --dry-run
# Force renewal of all certificates
sudo certbot renew

If Auto-Renewal Isn't Set Up

Add to crontab:

# Open crontab
sudo crontab -e
# Add line (renewal twice daily)
0 0,12 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

--post-hook reloads Nginx after successful certificate renewal.

Configuration Verification

After setup, be sure to verify everything works correctly. Errors in SSL configuration can lead to site unavailability or reduced security.

Online Tools

SSL Labs Server Test — the most popular and detailed service. Analyzes:

• Protocol versions (TLS 1.2, 1.3)
• Supported ciphers and their security
• Certificate chain
• Known vulnerabilities (Heartbleed, POODLE, BEAST)
• HSTS, OCSP Stapling settings

Goal — get grade A or A+. Configurations from this article give A+.

Other useful services:

• Hardenize — comprehensive security check (SSL, DNS, email)
• Security Headers — HTTP security headers check
• HSTS Preload — HSTS preload readiness check

Terminal Verification

# Basic certificate and chain check
openssl s_client -connect example.com:443 -servername example.com
# Check certificate expiration date
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates
# Check TLS 1.3 support
openssl s_client -connect example.com:443 -tls1_3
# Check TLS 1.2 support
openssl s_client -connect example.com:443 -tls1_2
# Detailed certificate information
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -text

HSTS Verification

curl -I https://example.com 2>/dev/null | grep -i strict

Should return: Strict-Transport-Security: max-age=63072000; includeSubDomains

HTTP → HTTPS Redirect Verification

curl -I http://example.com

Should return 301 Moved Permanently with Location: https://example.com/

Common Mistakes

Frequently Asked Questions