As the question already states, I'd like to know if the dh1024.pem file, generated by ./build-dh in openvpn, is dependent on the ca.(crt|key) file.

The reason was that I needed to ./clear-all the keys, but kept the dh1024.pem file open in an editor, and re-saved it after clearing the keys. Then I went on with creating the ./build-ca, ./build-key-server and ./build-client.

For that matter, could the dh*.pem file be dependent on the server key, or on anything else? Or is it just a file with a chunk of well-computed data with no dependencies?

Kind regards.

  • dh1024.pem is used on the server side. It is what negotiates authentication as per RFC2631 (ietf.org/rfc/rfc2631.txt). You can get rid of it, but you'd need to regenerate it, otherwise connections will fail
    – munkeyoto
    Commented Nov 4, 2014 at 15:07
  • @munkeyoto thanks, so it doesn't depend on any of the files generated by any of the ./build-*.sh scripts? Do any of those generated files depend on the dh*.pem file?
    – Daniel F
    Commented Nov 4, 2014 at 15:12
  • The file is only generated to negotiate authentication. If you deleted the other files, and are recreating everything from scratch, it only makes sense to regenerate that file as well
    – munkeyoto
    Commented Nov 4, 2014 at 15:32

1 Answer 1


That file has no dependency on any certificate or private key. It is not secret either. It can even be shared between various servers that don't necessarily trust or even know each other.

The dh1024.pem file contains Diffie-Hellman parameters. The DH key exchange is an algorithm played in a given finite group; namely, integers modulo a prime p. For a successful DH:

  • There are known parameters p (a big prime) and g (a conventional integer in the 2 to p-2 range, known as the generator).
  • Party A generates a random secret value a, computes ga mod p, and sends that to party B.
  • Party B generates a random secret value b, computes gb mod p, and sends that to party A.
  • Party A computes (gb)a mod p (raising the value received from B to its secret exponent a).
  • Party B computes (ga)b mod p (raising the value received from A to its secret exponent b).

The magic of DH is that both A and B end up with the same value, that eavesdropper cannot recompute from the two values that were sent across the wires.

In all of this, the p and g values are the "parameters" and must be known to both parties; but they are not secret. Security is ensured as long as:

  • p is large enough (at least 1024 bits; arguably, 2048 bits would be better).
  • p was not generated with a "special structure" that makes discrete logarithm easier.
  • g generates a subgroup of integers modulo p whose size is a multiple of a big enough prime (the order of g modulo p is the smallest integer r ≥ 1 such that gr mod p = 1; it is required that the greatest prime divisor of r has length at least 160 bits, preferably 256 bits or more).

The whole World could use the same parameters; but many people prefer to generate their own parameters, just to be sure that their parameters were not "cooked". This is what build-dh does. The resulting file (dh1024.pem) contains p and g, but nothing else. These values are not secret. They do not depend upon any external element, neither certificate, private key, or anything else.

  • Thanks, and none of the ./build-key(-server) scripts depend on it? This means that I could replace the dh*.pem file with a new one at any time?
    – Daniel F
    Commented Nov 4, 2014 at 16:00
  • 2
    You should be able to replace it at any time, although you must probably restart the server software to make it take the new file into account. OpenVPN uses a TLS handshake for each new client, and the DH parameters are used by the server (and sent to the client) during that handshake. However, there is little point in changing the file; you can, but there is no known security issue that such a change would solve.
    – Tom Leek
    Commented Nov 4, 2014 at 16:25

You must log in to answer this question.

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