Hardening TLS Configurations: OCSP Stapling, Forward Secrecy, and Cipher Priorities
Achieve an SSL Labs A+ rating by enforcing modern TLS 1.3 cipher suites, preloading HSTS headers, and configuring reliable OCSP stapling.
Netbay Cloud Team
Netbay Engineering
On this page
Achieving an SSL Labs A+ rating is not merely a badge of honor; it demonstrates that your transport layer encryption is properly shielded against downgrade attacks, cryptographic eavesdropping, and certificate revocation delays. Two vital elements of modern TLS security are Perfect Forward Secrecy (PFS)—ensuring past communications cannot be decrypted even if server private keys are later compromised—and OCSP (Online Certificate Status Protocol) Stapling.
Without OCSP stapling, web browsers must make a separate, unencrypted HTTP request to the issuing Certificate Authority to verify whether a certificate has been revoked. This introduces significant connection latency and leaks client browsing habits to third parties.
In a standard TLS handshake without stapling, when a client browser connects to https://example.com, it parses the Authority Information Access (AIA) extension inside the server's certificate. The client halts connection establishment and sends a lookup request to the CA's OCSP responder URI. If the CA's OCSP responder is sluggish or suffers a DDoS attack, the user experiences a multi-second browser freeze. With OCSP Stapling (RFC 6066), the web server queries the CA periodically in the background, obtains a cryptographically signed OCSP response valid for several days, and "staples" this signed token directly into the initial TLS ServerHello handshake.
Hardened Nginx TLS 1.3 and OCSP Stapling Configuration
Configure your Nginx virtual host with modern cipher suites and robust OCSP validation:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name secure.example.com;
# Certificate bundle and private key
ssl_certificate /etc/letsencrypt/live/secure.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/secure.example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/secure.example.com/chain.pem;
# Enforce modern TLS protocols only
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
# Forward Secrecy Ciphers
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
# Session caching parameters
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
# HTTP Strict Transport Security (HSTS) - 2 years
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
}Let's review the critical security directives in this configuration:
- **ssl_trusted_certificate:** Points to the intermediate CA certificate bundle. Nginx requires this file to verify the validity of the CA's OCSP response before stapling it.
- **ssl_session_tickets off:** Disables stateful TLS session tickets. In distributed systems or long-running single instances without regular ticket key rotation, compromised session ticket encryption keys can compromise Perfect Forward Secrecy across historical sessions.
- **resolver 1.1.1.1 8.8.8.8:** Explicitly configures fast, reliable recursive DNS servers for Nginx to resolve the CA's OCSP responder domain asynchronously.
Verifying OCSP Stapling with OpenSSL
Verify that Nginx is successfully stapling the CA verification signature to client handshakes:
# Connect using OpenSSL s_client and inspect OCSP response
openssl s_client -connect secure.example.com:443 -status -tlsextdebug < /dev/null 2>&1 | grep -A 17 "OCSP response:"You should observe OCSP Response Status: successful along with the certificate validity timestamps signed by the CA.
Enforcing HSTS and Preloading
The HTTP Strict Transport Security (HSTS) header instructs browsers to never attempt unencrypted HTTP connections to your domain for the next two years (max-age=63072000). The preload token allows your domain to be submitted to the Chromium HSTS Preload list, ensuring browsers connect over HTTPS even on the very first initial visit before any response headers are parsed.
Hardening your TLS configuration protects data in transit with zero latency penalty.
You can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds with Intel Xeon Platinum compute and high-speed SSD storage in Lucknow — netbayhosts.in.
Keep reading
Follow along on a real VPS
Deploy Linux in under 60 seconds
These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.
Deploy an instance