SSL/TLS Configuration — Secure Your Connections Without Breaking Compatibility

We see the same TLS problems across most of the infrastructure we audit. Outdated protocols: TLS 1.0 and 1.1 are still enabled, allowing downgrade attacks. Only TLS 1.2 and 1.3 should be enabled. Weak cipher suites: RC4, 3DES, and CBC-mode ciphers are present, allowing known attacks. Modern configurations use only AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Missing HSTS: Without the Strict-Transport-Security header, browsers allow HTTP connections on the first visit, enabling SSL stripping attacks.

Certificate management: Certificates expire because nobody set up automatic renewal. The team scrambles to generate a new certificate at 2 AM when monitoring alerts fire. This is completely avoidable with ACM (free, auto-renewing certificates on AWS) or cert-manager with Let's Encrypt (free, auto-renewing certificates on Kubernetes).

Incomplete certificate chains: The server sends the leaf certificate but not the intermediate certificates. Most browsers handle this by fetching intermediates from the CA, but some clients (API consumers, mobile apps, older systems) fail with certificate validation errors. This intermittent failure is notoriously hard to debug because it works on some clients and not others.

Certificate Provisioning: On AWS, we use ACM for all public-facing endpoints. Certificates are provisioned via Terraform, automatically validated via DNS (Route 53), and auto-renewed. On Kubernetes, we deploy cert-manager with Let's Encrypt issuer (or your corporate CA) for automatic certificate provisioning and renewal. Certificate readiness is verified before deployment, preventing expired-cert incidents.

Protocol and Cipher Configuration: We configure TLS 1.2 minimum (TLS 1.3 preferred) with the following cipher suite priority: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 for TLS 1.3, and ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256 for TLS 1.2. We disable all CBC-mode, RC4, 3DES, and export ciphers. ECDHE key exchange ensures perfect forward secrecy.

HSTS and Security Headers: We configure Strict-Transport-Security: max-age=63072000; includeSubDomains; preload after verifying all subdomains support HTTPS (misconfiguring HSTS with includeSubDomains breaks HTTP-only subdomains). We submit your domain to the HSTS preload list so browsers enforce HTTPS before the first connection.

OCSP Stapling: We enable OCSP stapling so the server provides certificate revocation status directly, eliminating the client's need to contact the CA for revocation checks. This improves TLS handshake speed and reliability, especially on slow networks. We verify stapling works correctly with openssl s_client -status.

Internal TLS: For service-to-service communication, we configure mTLS (mutual TLS) where both client and server present certificates. On Kubernetes, this is handled by a service mesh (Istio, Linkerd) transparently. On ECS, we configure it at the application level with certificates from ACM Private CA or an internal CA managed via Terraform.

A hardened TLS configuration across your infrastructure:

• Certificate automation — ACM or cert-manager with auto-provisioning and renewal
• Modern protocols — TLS 1.2/1.3 only with AEAD cipher suites and PFS
• HSTS — Strict Transport Security with preload list submission
• OCSP stapling — server-side revocation status for faster handshakes
• Certificate chain validation — complete chains served from all endpoints
• Internal TLS — mTLS for service-to-service communication
• Monitoring — certificate expiry alerts and TLS configuration compliance checks
• SSL Labs A+ rating — verified via Qualys SSL Labs test with documented report