Transport Layer Security is the cryptographic foundation of secure internet communication. Every HTTPS connection, every email sent between servers via STARTTLS, every VPN tunnel relying on TLS — all depend on a correctly configured TLS deployment. Yet misconfigurations remain extremely common: outdated protocol versions, weak cipher suites, missing HSTS headers, certificates left to expire, and improper CA authorization records. This guide covers the essential TLS configuration practices for 2025, from protocol version selection to certificate lifecycle automation.

TLS 1.3, standardized in RFC 8446 in 2018, represents the most significant redesign of the protocol in two decades. The differences from TLS 1.2 are not merely incremental:

Reduced handshake latency: TLS 1.3 completes the handshake in one round-trip (1-RTT) instead of two, and supports zero-RTT resumption for returning connections (with caveats around replay attack risk).

Mandatory Perfect Forward Secrecy: TLS 1.3 removes all non-PFS key exchange methods. Every TLS 1.3 connection uses ephemeral Diffie-Hellman (ECDHE or DHE), ensuring that compromise of the server's private key does not retroactively decrypt captured traffic.

Simplified cipher suite list: TLS 1.3 supports only five cipher suites, all using AEAD (Authenticated Encryption with Associated Data) modes. No negotiation of weak algorithms is possible.

Encrypted handshake: More of the TLS handshake is encrypted in TLS 1.3, reducing the metadata visible to network observers.

Removed legacy features: RSA key exchange, static DH, weak block cipher modes (CBC), MD5/SHA-1 in signatures, and compression are all eliminated.

TLS 1.3 should be enabled on all servers. TLS 1.2 remains acceptable but should be configured to support only PFS cipher suites with AEAD modes.

Protocol support for deprecated TLS versions must be explicitly disabled in server configuration:

SSL 2.0 — Broken by design. Published vulnerabilities since 1995. Must never be enabled.
SSL 3.0 — Vulnerable to POODLE attack (CBC padding oracle). Completely broken. Must never be enabled.
TLS 1.0 — Vulnerable to BEAST and POODLE-TLS attacks. Deprecated by RFC 8996 in 2021. Must be disabled. PCI DSS has required TLS 1.0 to be disabled since June 2018.
TLS 1.1 — No longer considered secure. Also deprecated by RFC 8996. Must be disabled.

Nginx configuration to enforce TLS 1.2 and 1.3 only:

ssl_protocols TLSv1.2 TLSv1.3;

Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3

For TLS 1.2, cipher suite selection is critical. Only AEAD cipher suites with PFS key exchange should be used:

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;

Algorithms to explicitly avoid in TLS 1.2:

RC4 — Stream cipher with multiple known biases. Prohibited by RFC 7465.
3DES — Sweet32 birthday attack. 64-bit block cipher should not be used for large data volumes.
CBC mode ciphers — Vulnerable to BEAST, Lucky13, POODLE-TLS. Use GCM or CHACHA20-POLY1305 instead.
NULL ciphers — No encryption. Should obviously never be used.
EXPORT cipher suites — Deliberately weakened for historical US export controls. Exploited by FREAK and Logjam attacks.
Anonymous DH/ECDH — No server authentication. Susceptible to man-in-the-middle attacks.

TLS certificates differ in the level of identity validation performed by the Certificate Authority:

Domain Validation (DV) — The CA verifies only that the applicant controls the domain. Issued in minutes or seconds via automated challenges (ACME). No identity information about the organization is included in the certificate. Appropriate for most websites.

Organization Validation (OV) — The CA verifies domain control and performs limited vetting of the organization's legal existence. Organization name appears in the certificate. Provides slightly more assurance than DV for users who inspect certificate details.

Extended Validation (EV) — Rigorous organizational vetting with standardized requirements. Previously triggered a green address bar in browsers; modern browsers have removed this visual distinction, reducing the practical user-facing benefit of EV certificates. Still used by financial institutions and high-profile organizations.

For most deployments, DV certificates via Let's Encrypt (ACME) provide equivalent cryptographic security to OV or EV certificates at zero cost with full automation.

Certificate Transparency (CT), defined in RFC 6962, requires CAs to log all issued certificates to publicly auditable append-only logs. Browsers require that TLS certificates include Signed Certificate Timestamps (SCTs) — proofs that the certificate has been submitted to a CT log — before trusting them. This mechanism enables domain owners to detect unauthorized certificate issuance.

Monitor CT logs for certificates issued for your domains using services like crt.sh or Facebook's Certificate Transparency Monitoring tool. Configure email alerts for any new certificate issued for your domains — an unexpected certificate issuance can indicate a compromised registrar account or a CA misissue. The CAA DNS record (discussed below) is a preventive control; CT monitoring is a detective control.

Configure HSTS to prevent protocol downgrade attacks and cookie hijacking:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Submit to the HSTS preload list at hstspreload.org once you are confident every subdomain supports HTTPS. The preload list is compiled into Chrome, Firefox, Safari, and Edge, ensuring HTTPS is enforced even on a user's first visit — before they have received the HSTS header.

Certificate revocation allows CAs to invalidate a certificate before its expiry — for example, if the private key is compromised. OCSP (Online Certificate Status Protocol) allows clients to query the CA's OCSP responder to check whether a certificate has been revoked. Without OCSP stapling, clients make direct OCSP requests on every TLS handshake, introducing latency and a privacy leak to the CA.

With OCSP stapling, the server queries the OCSP responder itself and includes the signed response in the TLS handshake. Clients receive the revocation status without contacting the CA directly. Nginx:

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1 valid=300s;

Certificate expiration is one of the most common causes of service outages. A certificate that expires causes browsers to display prominent security warnings and blocks users from accessing your service. Automation eliminates expiration risk entirely:

Let's Encrypt and ACME — Free certificates with 90-day validity. The short validity period encourages automation. Use Certbot, acme.sh, or Caddy (which automates ACME out of the box) to automatically renew certificates.

Certificate expiry monitoring — Even with automation, monitor certificate expiry as a safety net. Tools like Nagios, Zabbix, Prometheus, and purpose-built services (e.g., Cert Spotter) alert you when a certificate approaches expiry.

Inventory all certificates — Maintain a registry of all certificates in your environment, including expiry dates, renewal procedures, and responsible parties. Shadow IT certificates on test servers are a common source of outages.

CAA (Certification Authority Authorization) DNS records specify which CAs are permitted to issue certificates for your domain. A CA that receives a certificate request must check for CAA records and refuse to issue if the record does not authorize them. This prevents an attacker who compromises one CA from issuing certificates for your domain if that CA is not authorized by your CAA record.

example.com CAA 0 issue "letsencrypt.org"
example.com CAA 0 issue "digicert.com"
example.com CAA 0 issuewild "letsencrypt.org"
example.com CAA 0 iodef "mailto:[email protected]"

The iodef tag provides a contact address for CAs to report policy violations. CAA records are checked at issuance time, not during the TLS handshake — they are a preventive control rather than a runtime enforcement mechanism.

A common issue on HTTPS sites is mixed content: HTTP resources (images, scripts, stylesheets, iframes) loaded on an HTTPS page. Browsers block active mixed content (scripts and iframes) and warn about passive mixed content (images). Audit for mixed content using browser DevTools (Console and Network tabs filter for mixed content warnings), or automated tools like the Mixed Content Scanner. Fix by either serving all resources over HTTPS or using protocol-relative or absolute HTTPS URLs.

A secure TLS deployment in 2025 means TLS 1.3 with TLS 1.2 as a fallback, AEAD cipher suites only, PFS enforced, HSTS with preloading, OCSP stapling enabled, CAA records restricting certificate issuance, certificate expiry monitored and automated, and CT logs monitored for unauthorized issuance. This configuration protects against passive eavesdropping, man-in-the-middle attacks, downgrade attacks, and certificate misissue. Test your configuration regularly with tools like SSL Labs (ssllabs.com/ssltest) to catch regressions and ensure you maintain an A+ rating as the threat landscape and browser requirements evolve.

SSL/TLS Certificate Best Practices for 2025