Replace weak Diffie-Hellman parameters with 2048-bit or larger

What's happening

Diffie-Hellman key exchange establishes the shared TLS session key. The strength of the exchange depends on the size of the DH group: 1024-bit groups are factorable by nation-state-level adversaries (Logjam, 2015) and should never be used. 2048-bit is the minimum modern recommendation; 3072 or 4096 are stronger; ECDHE (elliptic-curve) at the standard curves provides equivalent security with much smaller keys.

Many older OpenSSL configurations default to 1024-bit DH parameters, and pre-2015 nginx and Apache deployments shipped with them. The fix is to generate fresh 2048-bit (or larger) DH parameters and point the server config at them — or to drop DHE-based cipher suites entirely in favor of ECDHE.

ECDHE is preferable on practically every count: smaller handshake messages, lower CPU cost, equivalent or stronger security, and broader client support. Unless you have a specific reason to retain DHE, the cleanest fix is to remove DHE-based suites and enforce ECDHE.

Why it matters

Logjam-class attacks let a nation-state-level adversary precompute the discrete logs for common 1024-bit groups and decrypt or MITM connections that negotiated those groups. Public groups (Oakley) are especially exposed.

PCI-DSS scans flag DH groups under 2048 bits. SSL Labs grades drop to B or below. Mozilla Observatory warns explicitly about weak DH.

Beyond the cryptographic issue, weak DH groups also slow down the handshake noticeably on mobile clients because of the larger key sizes needed to compensate.

Common causes

• Server uses OpenSSL's default DH parameters, which were 1024-bit on older versions.
• ssl_dhparam (nginx) or SSLOpenSSLConfCmd DHParameters (Apache) was never set.
• DHE cipher suites are still in the cipher list and the server falls back to weak DH for clients that can't do ECDHE.
• A pre-generated dhparam.pem file is 1024 bits because someone copied an old tutorial.
• Hardware load balancer firmware ships fixed DH groups and was never patched.

Detect this on your site

Run a quick scan with the SSL Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Detect weak DH

   Run nmap --script ssl-dh-params -p 443 example.com or use testssl.sh. Output flags any DH groups under 2048 bits explicitly. SSL Labs also reports DH parameter strength in its report.

2. 2

   Decide DHE-or-ECDHE

   If your client base is modern, drop DHE entirely and serve only ECDHE-based suites. Edit ssl_ciphers to remove DHE-* entries. ECDHE-AES-GCM and ECDHE-CHACHA20 cover everything modern browsers, mobile devices, and SDKs support.

3. 3

   If keeping DHE, generate strong parameters

   Run openssl dhparam -out /etc/ssl/dhparam.pem 2048. This takes a few seconds and produces a 2048-bit group that is unique to your server. For higher assurance use 4096; the handshake cost is slightly higher.

4. 4

   Configure nginx to use the new dhparam

   Add ssl_dhparam /etc/ssl/dhparam.pem; to the http or server block. Reload nginx with sudo nginx -t && sudo systemctl reload nginx. The new group is used for any DHE handshake.

5. 5

   Configure Apache

   Use SSLOpenSSLConfCmd DHParameters "/etc/ssl/dhparam.pem" in the VirtualHost. Apache 2.4.7+ supports this directive. Reload Apache after applying.

6. 6

   Re-scan and verify

   Re-run nmap or testssl.sh and confirm all DH groups are 2048 bits or larger. SSL Labs grade should rise. PCI scans need a fresh run.

Example

# Generate 2048-bit DH parameters (takes a few seconds)
openssl dhparam -out /etc/ssl/dhparam.pem 2048

# Verify length
openssl dhparam -in /etc/ssl/dhparam.pem -text -noout | head -1
# DH Parameters: (2048 bit)

Generate and inspect fresh DH parameters

Related fixes