I have to ensure that the server when communicating on the Internet needs to have DH prime value of 2048 bits or greater.

I can find out the cipher suites that are used but cannot derive the DH prime value from that. If there is an online portal or a hack which lets you understand the strength of the DH prime value being exchanged then please let me know.

  • Using a DH prime value would only make sense in the context of running a service protected by a Diffie–Hellman based cipher-suite. A shared DH prime is one of the parameters used in a DH based cryptography implementation. What service are you trying to protect or what are you trying to achieve in general? It may be worth seeking professional security consultancy assistance is this is for a production / public facing service.
    – Stu W
    Commented Mar 28, 2019 at 11:16
  • We have a finding from Bitsight report that a server has DH prime value less than 2048 bit. We need to configure the server for DH prime 2048 bit or more. Now I need to check from Internet if the DH prime for these servers is actually 2048 bit or not after the changes in the configuration. (Can't say anymore) Commented Mar 28, 2019 at 12:06

3 Answers 3


If the server is available on the intenet, you can just use Qualys ssllabs scanner to verify that DHE (not ECDHE) cipher suites use 2048 bit group.

You can also use wireshark to capture the recording of a handshake between a client and your server. Make sure the client is configured to use DHE, not ECDHE, and look at the size of "p" in the ServerKeyExchange message sent by the server. It should be 256 bytes (2048 bits) long.

You can use the script from this answer to capture and extract the DH group value (p and g) and format it as "dhparam" value suitable for configuring TLS servers like nginx and postfix smptd and use openssl dhparam -check to verify the value is "safe".


I assume you are trying to check the length of the DH parameter for a TLS-secured service.

If you have access to the server, you can check its configuration. It is usually configured together with the other TLS parameters of your (web?)server.

If you don't have access, you could use sslscan <host>:<port>.


> sslscan 192.168.X.X:443
Version: 1.11.12-static
OpenSSL 1.0.2-chacha (1.0.2g-dev)

Connected to 192.168.X.X


  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-384 DHE 384
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 1024 bits
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-384 DHE 384

If you are not looking for the length, but the actual content of the parameter, you will need access to the server.

  • Where can I get this tool? I'm running a windows currently. And how safe is it? Edit: I don't have access to this server. I just need to check if configuration works correctly and that DH prime is 2048 bits or more. Commented Mar 28, 2019 at 12:07
  • sslscan - github.com/rbsec/sslscan or alternatively testssl.sh(my favourite) - testssl.sh
    – Stu W
    Commented Mar 28, 2019 at 13:11
  • Thank you man! You made my life so much simpler! Commented Mar 29, 2019 at 5:04

Check out this answer: How to verify Diffie Hellman uses a "Safe" prime


openssl s_client -cipher 'DHE' -tls1_2 -msg -connect {server:port}

(maybe check other ciphers as well) It will return: Server Key Exchange or Server Temp Key with the length of p (in bytes, not in bits)

256 bytes = 2048 bits

 ServerKeyExchange, Length=1034
        dh_p (len=256): AD107E1E9123A9D0....
  • 1
    Server public key is the size of the key in the certificate, used for signing or encryption not xxDHE. Server Temp Key gives xxDHE type and size in 1.0.2 up. Per your link -msg shows ServerKX data including length and value of p (in all versions), and -trace decodes it in 1.0.2 up. Commented Jun 10, 2023 at 0:24
  • @dave_thompson_085 thanks for the clear answer, will update the answer! The p is then always smaller? update: p is expressed in bytes, not bits... 2048 = 256 bytes Commented Jun 11, 2023 at 18:39
  • Yes, all field lengths in SSL/TLS are in bytes. DHE params+key and cert (static) key are configured or otherwise determined independently by the server -- although the CA may constrain pubkey sizes for which it will issue a cert -- and can be different, although there is usually no good reason to make them different. One case I have encountered was Java 6 which only implemented DHE 768(!) in years when RSA certs were using 1024 and then 2048. Commented Jun 11, 2023 at 22:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .