SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam) means a TLS service offers ephemeral Diffie-Hellman (DHE) key exchange with a prime of 1024 bits or less, which a well-resourced attacker could eventually break. Fix it by giving the service 2048-bit DH parameters, or by dropping DHE suites in favor of ECDHE, then reload and rescan.

What the scanner is actually detecting

The scanner completes TLS handshakes offering only DHE cipher suites and reads the size of the prime (the modulus) the server sends. The certificate and protocol version are not part of this check.

Scanner	ID	Finding title
Nessus	Plugin 83875	SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam)
Nessus	Plugin 106459	Weak DH Key Exchange Supported (PCI DSS)
Greenbone (OpenVAS)	See report	Diffie-Hellman Key Exchange Insufficient DH Group Strength

Both Nessus plugins reference CVE-2015-4000 and carry a CVSS v3 base score of 3.7 (Low). The thresholds differ. Plugin 83875 fires on a modulus of 1024 bits or less. Plugin 106459 fires on anything smaller than 2048 bits and only runs when the scan policy has PCI DSS checks enabled, so a 1536-bit group clears 83875 but still fails 106459. If this came out of your quarterly compliance scans, our guide to PCI DSS Requirement 11.3 scanning covers how those results are handled.

Each port is judged separately, so HTTPS, mail ports (25, 465, 587, 993, 995), RDP and management consoles can each produce a result.

Real-world risk

Logjam, published in 2015, has two parts. The headline attack lets a man-in-the-middle downgrade connections to 512-bit export-grade DH on servers that still accept DHE_EXPORT suites. The second part is what these plugins measure: the researchers showed that the most expensive step in breaking DH depends only on the prime, so an attacker who precomputes against a widely shared 1024-bit prime can then break individual connections quickly. They estimated that a nation-state could afford that precomputation.

Honestly, exploiting a 1024-bit group requires intercepting traffic plus very large computing resources, and Tenable rates both plugins Low. The real pressure is compliance: Tenable’s 106459 description notes that PCI’s definition of strong cryptography, based on NIST SP 800-57 Part 1, excludes DH moduli below 2048 bits. The fix is usually one configuration line.

How to confirm it on the host

From any machine with Nmap, the ssl-dh-params script tests DHE suites and reports weak groups:

nmap --script ssl-dh-params -p 443,465,993,995 host.example.com

A vulnerable service shows a block titled Diffie-Hellman Key Exchange Insufficient Diffie-Hellman Group Strength with the cipher suite and modulus length. With OpenSSL, force a DHE handshake and read the temporary key size:

openssl s_client -connect host.example.com:443 -tls1_2 -cipher 'DHE:@SECLEVEL=0' </dev/null 2>&1 | grep -i 'temp key'

Output such as Peer Temp Key: DH, 1024 bits (older builds print Server Temp Key) confirms the finding. @SECLEVEL=0 matters: at the default level on many current systems the client aborts with dh key too small, which is itself a sign of a weak group. For mail ports, add -starttls smtp (port 25 or 587) or -starttls imap (port 143). testssl.sh --logjam host.example.com:443 gives a second opinion and flags DH keys of 1024 bits or less.

On Linux servers, find where the parameters come from:

openssl dhparam -in /etc/ssl/dhparams.pem -text -noout | head -1
grep -rn ssl_dhparam /etc/nginx/
grep -rl "BEGIN DH PARAMETERS" /etc/httpd /etc/apache2 /etc/ssl 2>/dev/null
postconf smtpd_tls_dh1024_param_file
doveconf -n | grep -i dh

The first command prints a line such as DH Parameters: (1024 bit). On Windows, check the Schannel value and, on Windows Server 2016 and later, the enabled DHE suites:

Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman' -ErrorAction SilentlyContinue
Get-TlsCipherSuite | Where-Object { $_.Name -like 'TLS_DHE_*' } | Select-Object Name

How to fix it

For any OpenSSL-based service, generate a fresh parameter file once:

openssl dhparam -out /etc/ssl/dhparams.pem 2048

2048 bits clears both Nessus plugins. The Postfix documentation calls a 2048-bit prime the best-practice choice and warns that much larger values hurt performance and interoperability.

nginx

Since nginx 1.11.0, no DH parameters are set by default, so DHE suites are not used at all unless ssl_dhparam is configured (older versions used built-in parameters). A flagged nginx 1.11.0 or later therefore has ssl_dhparam pointing at a weak file. Either point it at the new file or delete the directive to run ECDHE only:

ssl_dhparam /etc/ssl/dhparams.pem;

Check every server block, then run nginx -t && nginx -s reload.

Apache httpd

From version 2.4.7, mod_ssl uses standardized DH primes of 2048 bits and up, chosen by the length of the certificate’s RSA or DSA key. On current Apache, a 1024-bit result usually means a custom BEGIN DH PARAMETERS block appended to the first SSLCertificateFile (the Apache FAQ once suggested a 1024-bit block to keep Java 7 clients working), or a certificate with a small key. A TLS certificate inventory makes weak certificate keys easy to find. Remove or replace the appended block, or on httpd 2.4.8 and later with OpenSSL 1.0.2 or later set the file explicitly:

SSLOpenSSLConfCmd DHParameters "/etc/ssl/dhparams.pem"

To drop DHE instead, append :!DHE to your existing SSLCipherSuite string and confirm that openssl ciphers -v 'your-string' | grep 'Kx=DH ' returns nothing. Then run apachectl -t and apachectl -k graceful.

Postfix and Dovecot

Postfix reads DH parameters from smtpd_tls_dh1024_param_file. The name is historical and a 2048-bit file is fine:

openssl dhparam -out /etc/postfix/dh2048.pem 2048
postconf -e 'smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem'
postfix reload

Postfix 3.1 and later compile in a 2048-bit default, and on Postfix 3.7 or later built with OpenSSL 3.0 or later, an empty value or auto hands the choice to OpenSSL, which the Postfix documentation now recommends. On those versions the fix is often just removing an old override. Also check /etc/postfix/master.cf for -o smtpd_tls_dh1024_param_file= overrides on the submission and smtps services.

Dovecot uses a different setting in each major version: ssl_server_dh_file = /etc/dovecot/dh.pem in 2.4, ssl_dh = </etc/dovecot/dh.pem in 2.3, and ssl_dh_parameters_length = 2048 in 2.2. Since 2.3.3 the parameters are optional and the Dovecot documentation encourages disabling non-ECC DH entirely. Restart Dovecot afterwards.

Windows (IIS, RDP and other Schannel services)

Microsoft Security Advisory 3174644 documents the ServerMinKeyBitLength value. If it is absent, the modulus stays at 1024 bits; Microsoft states that all versions of Windows 10 already default to 2048, so a flagged Schannel host is typically an older release such as Windows Server 2012 R2, or has the value explicitly set to 1024. Set it to 2048 (0x800, the value in Microsoft’s example):

reg add "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman" /v ServerMinKeyBitLength /t REG_DWORD /d 2048 /f

Microsoft’s TLS registry reference prefers controlling key exchange through the cipher suite order, so removing DHE suites is the alternative. On Windows Server 2016 and later:

Get-TlsCipherSuite | Where-Object { $_.Name -like 'TLS_DHE_*' } | ForEach-Object { Disable-TlsCipherSuite -Name $_.Name }

Where Group Policy manages the list, edit Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order instead and leave out every TLS_DHE_ entry; the policy overrides local changes. Reboot so every Schannel service picks up the change.

Java and Tomcat

The JSSE provider sizes DHE keys with the jdk.tls.ephemeralDHKeySize system property. In current JDK releases, leaving it undefined means 2048 bits for non-export suites. legacy restores JDK 7 era behavior, and matched follows the certificate key size, so a 1024-bit certificate yields a 1024-bit group. Remove those values or pin the size, for Tomcat in $CATALINA_BASE/bin/setenv.sh (or the Java Options of the Windows service):

CATALINA_OPTS="$CATALINA_OPTS -Djdk.tls.ephemeralDHKeySize=2048"

Update old bundled runtimes too, then restart the service.

Appliances and load balancers

If TLS terminates on a load balancer, reverse proxy or appliance, change the DH or DHE setting in its SSL profile per the vendor’s documentation. The backend server’s settings never reach the client.

How to verify the fix and rescan

Repeat the openssl s_client test. You should see DH, 2048 bits, or a handshake failure if you removed DHE.
Rerun nmap --script ssl-dh-params on every affected port and confirm the insufficient group strength block is gone.
Rescan with the same policy and credentials. To confirm 106459 is cleared, the policy must still have PCI DSS checks enabled.

What can break and how to roll back

Java 7 and older clients. Per the Apache FAQ, they cannot handle DH primes above 1024 bits and fail with Could not generate DH keypair. If they also lack ECDHE, update the client rather than weakening the server.
Clients without ECDHE. If you remove DHE, very old clients that support DHE but not ECDHE fail unless another common suite remains.
CPU cost. Groups much larger than 2048 bits slow handshakes.
Rollback: restore the previous config file and reload; on Windows run reg delete "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman" /v ServerMinKeyBitLength /f, re-add suites with Enable-TlsCipherSuite -Name <suite> or revert the GPO, then reboot; for Java, remove the JVM option and restart.

Common false positive reasons

Something in front of the host. The scanner reached a load balancer or TLS proxy, not the server you changed.
No reload or reboot. The file is correct, but the running service still holds the old parameters.
A different port. Port 443 is clean while 587 or 993 still uses the old file. The plugin output names the port.
Hidden overrides. An appended block in an Apache certificate file, or a master.cf override in Postfix, wins over the setting you edited.
Only 106459 remains. The group is now above 1024 but below 2048 bits, which satisfies 83875 and still fails the PCI check.

FAQ

Is a 2048-bit DH group enough?

Yes. Tenable’s solution for both plugins asks for 2048 bits or more, and larger groups mainly add handshake cost.

Should I disable DHE entirely?

If all your clients support ECDHE, yes. Tenable lists ECDH-only as an accepted fix for 106459, and nginx 1.11.0 and later already skip DHE unless you configure parameters.

Does TLS 1.3 have this problem?

No. TLS 1.3 only uses named groups, and the smallest finite-field group it defines is 2048 bits. The finding comes from TLS 1.2 and older handshakes.

Tracking this finding across many hosts

Weak DH groups tend to surface on web, mail and Windows hosts at once. SITEY is a self-hosted vulnerability management platform that imports findings from 16 scanners; it merges duplicates per scanner, not across scanners, so a Nessus and a Greenbone result for the same host stay separate. Its AI can write host-specific remediation scripts that its agents deploy on Windows and Linux endpoints after human approval, and per-finding retest is available for Nessus, Acunetix and Burp findings.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

How to Fix SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam)