Can an RSA certificate work with dh none in OpenVPN?

Here is a server config that says dh none next to a certificate that says RSA, plus a nagging suspicion that one of them must be wrong. Nothing is wrong. The certificate signs and authenticates; the key exchange establishes a shared secret. Those are two different jobs in the same handshake, and TLS lets an RSA certificate authenticate a handshake that uses ephemeral elliptic-curve agreement.

The confusion usually arrives with a migration guide. It says to replace the DH parameter file with dh none, the reader notices that the certificate is not an elliptic-curve certificate, and the two facts get treated as a contradiction.

Why the two settings look related

OpenVPN's older configuration asked for a DH parameter file because finite-field Diffie-Hellman needs domain parameters that both sides agree on. The dh directive pointed at that file. When a deployment moves to ECDH, the parameters come from a named curve instead, and the file is no longer needed, which is what dh none expresses.

Certificates are a separate axis. They carry a public key and a signature that prove the server's identity, and that key can be RSA or elliptic-curve regardless of how the session key is agreed. A handshake that uses ECDHE for key agreement and RSA for authentication is ordinary and widely deployed.

The naming makes the overlap worse. Elliptic curve appears in both ECDHE and ECDSA suite names, so it is easy to assume that any connection mentioning a curve must involve a curve certificate. It does not.

Reading a TLS 1.2 suite name correctly

Take ECDHE-RSA-AES256-GCM-SHA384. The first token is the key-exchange family: ephemeral elliptic-curve Diffie-Hellman. The second is the authentication family: RSA. The rest describes record protection and the hash used in the handshake.

An ECDHE-ECDSA suite uses the same key-exchange family with a different authentication method, so it needs an elliptic-curve certificate. A DHE-RSA suite uses finite-field ephemeral Diffie-Hellman with RSA authentication, and that one does need DH parameters.

Read a suite name left to right and assign each part to its job. Once the tokens are separated, the question changes from "does my certificate match dh none" to "does my server permit a suite whose key exchange does not need a DH file".

What dh none actually disables

dh none tells the server not to load a finite-field DH parameter file. It does not disable authentication, certificate validation, or TLS itself. What it does require is that the negotiated key exchange be one that does not need those parameters, which in practice means an ECDHE suite or a TLS 1.3 handshake.

That requirement is where breakage comes from. If the server's TLS cipher policy is restricted to DHE suites, or if a client only offers them, removing the parameter file leaves no usable key-exchange method and the handshake fails. The error generally appears during the control-channel handshake, before any user authentication. Read the cipher list before blaming the file that is missing.

On the elliptic-curve side, the curve is selected by the server's TLS configuration, and OpenVPN exposes an option to choose it on older branches. TLS 1.3 handles the group negotiation inside the protocol and does not consult the DH file at all.

dh none is not a security downgrade by itself. The strength of the exchange then depends on the curve and suite that are actually negotiated, which is why the next step is to look at what the peers chose rather than at the file that is absent.

Confirming the negotiation before editing

Raise the server and client verbosity and read the control-channel line that OpenVPN prints after a connection. It names the TLS version and the negotiated cipher, and it reports the peer certificate's key type. That single line answers the question the configuration file only implies.

If it shows TLS 1.2 with an ECDHE-RSA suite and an RSA certificate, the combination is exactly what dh none expects, and there is nothing to repair. If it shows a DHE suite or a handshake failure with no common cipher, the fix is in the cipher policy or the client capability, not in the certificate.

Test the oldest client you intend to support, because a current client may negotiate TLS 1.3 while an older one is limited to TLS 1.2 suites. If the oldest client has no overlap, either widen the permitted suites or upgrade that endpoint.

Do not turn off certificate verification to get past a handshake failure. The failure is telling you that the peers could not agree on a key exchange, and disabling the check removes the identity guarantee without addressing the agreement.

Checklist: is the certificate RSA, is an ECDHE suite permitted, does the log show that suite, and does the oldest supported client negotiate it too? If all four are yes, dh none is doing its job.