Every website has that little padlock in the browser bar. But did you know that padlock can mean wildly different things? Some TLS configurations are bulletproof. Others are technically encrypted but so poorly configured that an attacker with the right tools could still break your users’ sessions, intercept their data, or silently downgrade their connection to something weaker.
SSL Labs (ssllabs.com) gives your TLS configuration a letter grade from A to F. Getting an A+ means your setup is genuinely secure. This guide shows you exactly how to get there with NGINX or Angie, explains what each setting does and why it matters, and gives you a config you can copy-paste today.
Why TLS Configuration Actually Matters
TLS is the protocol that encrypts your HTTPS connections. But TLS is not one thing — it’s a negotiation. Your browser says “here’s what I support”, your server says “here’s what I support”, and they agree on the strongest option both sides understand.
A badly configured server might support TLS 1.0 (broken since 2018), RC4 ciphers (broken since 2013), or export-grade encryption (literally designed to be breakable by 1990s US government export restrictions). Attackers can force a “downgrade” to these weaker options and then break the connection. SSL Labs tests for all of this and grades your TLS configuration accordingly.
The Complete A+ NGINX/Angie TLS Config
server {
listen 443 ssl;
http2 on;
server_name yourdomain.com;
# Certificate and key
ssl_certificate /etc/ssl/certs/yourdomain.com.pem;
ssl_certificate_key /etc/ssl/private/yourdomain.com.key;
# TLS versions: 1.2 for compatibility, 1.3 for modern clients
ssl_protocols TLSv1.2 TLSv1.3;
# TLS 1.2 cipher suites (strong only)
ssl_ciphers 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;
# Elliptic curves for key exchange (includes post-quantum hybrid)
ssl_ecdh_curve X25519MLKEM768:x25519:secp256r1:secp384r1;
# Session resumption (speed without sacrificing security)
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# OCSP stapling (proves cert is still valid, faster for clients)
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
# HSTS: tell browsers to ALWAYS use HTTPS for 1 year
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# Security headers
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}That’s your A+ TLS config for NGINX and Angie. Now let me explain what each part does, because copy-pasting config without understanding it is how you end up with security theatre instead of security.
Breaking It Down: What Each Setting Does
ssl_protocols — Which TLS Versions to Allow
TLS has had several versions. Some are broken:
- SSLv2/SSLv3 — completely broken, ancient history
- TLS 1.0 — broken by BEAST and POODLE attacks, officially deprecated
- TLS 1.1 — also deprecated in 2021
- TLS 1.2 — still secure with the right cipher suites. Most devices support it.
- TLS 1.3 — the modern standard. Faster, simpler, stronger. No legacy cipher baggage.
Enabling only TLS 1.3 gets you the cleanest setup but excludes a small percentage of older devices. TLSv1.2 TLSv1.3 is the practical sweet spot for 2026: modern and secure, but compatible with devices from the last decade.
ssl_ciphers — The Encryption Algorithms
For TLS 1.2, you specify which encryption algorithms are allowed. The ones above all start with ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) which provides Perfect Forward Secrecy: even if someone steals your private key tomorrow, they can’t decrypt traffic captured today. Each session gets its own ephemeral key.
For TLS 1.3, you don’t need to specify ciphers — TLS 1.3 only allows strong ones by design. The old cipher mess is gone.
ssl_ecdh_curve — Post-Quantum Key Exchange
The first entry X25519MLKEM768 is the post-quantum hybrid curve: X25519 (fast, modern) combined with ML-KEM-768 (quantum-resistant). Chrome uses it by default since 2024. Your server supports it automatically with our openssl-nginx 4.0 package. The others are fallbacks for clients that don’t yet support the hybrid mode.
HSTS — The Big One
HSTS (HTTP Strict Transport Security) tells browsers: “Only ever connect to this site over HTTPS, for the next 31536000 seconds (1 year).” Once a browser has seen this header, it will refuse to make plain HTTP connections to your domain — even if the user types http://. No more insecure first requests. No more SSL stripping attacks.
The preload directive means you can register your domain in the browser’s built-in HSTS preload list, so the protection applies even on the very first visit before the browser has ever seen your HSTS header.
OCSP Stapling — Certificate Validity Without Privacy Leaks
Your TLS certificate can be revoked (if it’s compromised). Browsers need to check whether your cert is still valid. The old way: browser contacts the CA’s OCSP server, which leaks which sites users are visiting to the CA. The better way: your server fetches the OCSP response and “staples” it to the TLS handshake. Browsers get proof the cert is valid, without making a separate request. Faster and more private.
HTTP to HTTPS Redirect
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}Always redirect HTTP to HTTPS. If you use Angie, the native ACME module handles certificates automatically without Certbot.
Test Your TLS Configuration
# Test NGINX/Angie config
nginx -t
systemctl reload nginx # or: systemctl reload angie
# Quick local TLS test
openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep -E "Protocol|Cipher|Server Temp Key"
# Full SSL Labs test:
# https://www.ssllabs.com/ssltest/analyze.html?d=yourdomain.com
Frequently Asked Questions
You can, and it gives the cleanest setup. But about 1–2% of devices (older Androids, some enterprise software) only support TLS 1.2. For most public websites, keeping both is the right call. For internal tools where you control the clients, TLS 1.3 only is fine.
ECDSA (Elliptic Curve) certificates are smaller and faster than RSA while providing the same security level. Use ECDSA P-256 if your CA supports it. Let’s Encrypt issues ECDSA certs. If you need maximum compatibility with ancient software, keep RSA-2048 as a fallback.
TLS session tickets allow connection resumption, which is good for performance. But the ticket encryption key has to be stored somewhere, and if it leaks it can compromise past sessions — breaking forward secrecy. Disabling tickets and using session cache instead is more secure for most setups.
A built-in list in Chrome, Firefox, Safari and Edge of domains that must always use HTTPS. To join, submit at hstspreload.org after enabling the preload directive. Note: it is very hard to remove yourself, so only use it for domains you are committed to keeping HTTPS forever.
Yes. Replace the ssl_certificate paths with your Let’s Encrypt paths (/etc/letsencrypt/live/yourdomain.com/fullchain.pem etc). Or switch to Angie which handles Let’s Encrypt natively with no Certbot needed.
With a properly issued certificate and this TLS configuration, you will get A+. The specific score depends slightly on your certificate type (ECDSA is slightly better-rated than RSA), but the configuration itself is A+ level.
Related Posts
- openssl-nginx: A Dedicated OpenSSL Build for NGINX and Angie — the OpenSSL that powers these cipher suites
- Angie ACME: Free TLS Certificates Without Certbot — automated certificate management built into Angie
- Angie vs NGINX: Complete 2026 Comparison — features, performance, and migration guide
- NGINX and Angie: The Expert Guide to Maximum Performance and Security — full hardening guide