DEV Community

Ramer Labs
Ramer Labs

Posted on

7 Mistakes to Avoid in Nginx TLS Configuration for Production

#nginx #security #linux #devops

Introduction

Transport Layer Security (TLS) is the backbone of any modern web service. As an SRE, you know that a mis‑configured TLS layer can expose sensitive data, degrade performance, and even break compliance audits. This guide walks you through the seven most common pitfalls when hardening Nginx for TLS in a production environment, and shows you how to fix them with concrete configuration snippets.

1. Using the Default Cipher Suite

Nginx ships with a generic set of ciphers that prioritize compatibility over security. This often leaves you vulnerable to attacks like Logjam or BEAST.

What to do:

  • Prefer modern, AEAD ciphers (AES‑GCM, ChaCha20‑Poly1305).
  • Disable weak algorithms such as RC4, DES, 3DES, and MD5. 
# /etc/nginx/conf.d/ssl.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers \
    'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256' \
    'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384' \
    'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305' \
    'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
Enter fullscreen mode Exit fullscreen mode

2. Forgetting HTTP/2 and ALPN

HTTP/2 brings multiplexing, header compression, and server push – all of which are only available over TLS with ALPN negotiation. Without it, clients fall back to HTTP/1.1, increasing latency.

Fix: Enable HTTP/2 in the listen directive and ensure ssl_alpn is on.

server {
    listen 443 ssl http2;
    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    # ALPN is automatically handled by modern Nginx builds
}
Enter fullscreen mode Exit fullscreen mode

3. Skipping OCSP Stapling

OCSP stapling reduces the round‑trip to the Certificate Authority (CA) during the TLS handshake, speeding up connection times and preventing privacy‑leaking status checks.

Enable it:

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
Enter fullscreen mode Exit fullscreen mode

4. Not Enforcing HSTS (HTTP Strict Transport Security)

Without HSTS, browsers may still attempt insecure HTTP connections after a user’s first visit, opening a window for downgrade attacks.

Add the header:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
Enter fullscreen mode Exit fullscreen mode

Tip: Submit your domain to the HSTS preload list if you control all sub‑domains.

5. Using Self‑Signed Certificates in Production

Self‑signed certs break the trust model, trigger browser warnings, and can cause API clients to reject your service. Always obtain certificates from a reputable CA (Let’s Encrypt, ZeroSSL, or a commercial provider).

Automation: Use Certbot or acme.sh to automate renewal.

# Example with Certbot for Nginx
sudo certbot --nginx -d example.com -d www.example.com --agree-tos --redirect
Enter fullscreen mode Exit fullscreen mode

6. Ignoring Perfect Forward Secrecy (PFS)

PFS ensures that a compromised private key does not decrypt past sessions. Modern ciphers already provide it, but you must avoid static RSA key exchange.

Check your cipher list: The snippet in section 1 already excludes ECDHE-RSA‑only suites; keep at least one ECDHE suite.

7. Weak Diffie‑Hellman Parameters

If you fall back to DHE, you need a strong DH group (>= 2048‑bit). Generating a 1024‑bit group is insecure and can be cracked.

Generate a safe group:

openssl dhparam -out /etc/nginx/dhparam.pem 4096
Enter fullscreen mode Exit fullscreen mode

Then reference it in Nginx:

ssl_dhparam /etc/nginx/dhparam.pem;
Enter fullscreen mode Exit fullscreen mode

Putting It All Together

Below is a minimal yet production‑ready TLS block you can drop into your server configuration:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparam.pem;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 1.0.0.1 valid=300s;
    resolver_timeout 5s;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
    add_header X-XSS-Protection "1; mode=block";

    # Your usual location blocks go here
}
Enter fullscreen mode Exit fullscreen mode

Monitoring and Validation

After deployment, verify your TLS posture with tools like Qualys SSL Labs, testssl.sh, or openssl s_client. Automate these checks in your CI/CD pipeline to catch regressions early.

openssl s_client -connect example.com:443 -servername example.com -tls1_3
Enter fullscreen mode Exit fullscreen mode

Conclusion

Hardening Nginx TLS isn’t a one‑time checklist; it’s an ongoing process that blends cryptographic hygiene with performance tuning. By avoiding the seven mistakes outlined above, you’ll deliver a faster, safer experience for your users while staying compliant with modern security standards. For deeper dives into server hardening and automated certificate management, consider checking out resources like https://lacidaweb.com for practical guides and community support.

Top comments (0)