What openssl dhparam -check Verifies, and What It Misses

Passing dhparam -check feels like a verdict on your VPN's Diffie-Hellman setup. It is not. The command compares one parameter file against the arithmetic it claims to satisfy, and it says nothing about whether the group size matches your policy or whether the tunnel even loads that file. Reading it as a security review is the assumption worth correcting first.

A parameter file holds a prime and a generator. Validity is a property of those numbers, while strength is a judgement about your threat model and your peers, and the two are not interchangeable.

What the validity check actually confirms

Run the check against the file you have and read the reply. openssl dhparam -in dh.pem -check -noout performs the parameter checks and suppresses the encoded output. A message that the parameters appear to be ok means the values are structurally consistent; it does not mean that a short group is acceptable in your environment.

Generation without -dsaparam produces safe primes, where (p-1)/2 is also prime, which is why it takes so long. The DSA-style path builds parameters faster and converts them to DH form, and the OpenSSL manual attaches extra fresh-key requirements to using those. Neither construction is a session secret: the file is public configuration material, not the certificate's private key and not the control-channel shared secret.

Read size and generator before you judge the file

A validity result means more when you know what was validated. Print the parameters with openssl dhparam -in dh.pem -text -noout, then note the prime length and the generator value.

Compare that length against a written policy rather than against habit. If your requirement is an approved named group from a modern TLS stack, a hand-generated file may be the wrong artefact entirely. Record both numbers in the change record so the next reviewer does not have to derive them again.

Do not turn an inspection into a regeneration

The failure mode here is a command that looks like a check and behaves like a generator. Adding a bit length, as in openssl dhparam -check 2048, asks for new parameters and the input file is ignored. A generator option can do the same. If you only meant to inspect, pass -in and -check and nothing that describes a size.

Writing output over the original path deserves the same suspicion, because the manual warns that file output is not atomic. A crash mid-write leaves a truncated parameter file and a service that will not start.

Match the group to the protocol, not to a trend

Size policy is a decision the tool cannot read for you. A 2048-bit finite-field group is a common floor and larger groups cost handshake time, so pick the figure your own baseline names and write it down. Widely used groups are not weak because they are public; obscurity adds nothing here.

Where the stack supports approved named groups, follow that documented arrangement instead of generating unusual parameters to make them look unique. A named group is something a peer can recognise and a reviewer can look up, which is worth more than a bespoke file nobody can classify.

Confirm the VPN loads the file at all

A correct parameter file that no process reads changes nothing. In OpenVPN the server directive is dh with a path, and deployments that rely on ECDH or TLS 1.3 key exchange can set dh none instead. Check the running configuration rather than a template, then confirm that clients and peers negotiate the same construction.

Close the loop with the evidence you actually need: the group the tunnel negotiated, the parameter length in the file, and the policy line that length satisfies. A passing check belongs in that list as a single item. Treating it as the whole answer is how a short group survives an audit that was supposed to catch it.