remote-cert-tls server: what it checks in an OpenVPN profile
The directive checks the role encoded in the peer certificate, not its name. Compare role, trust anchor and hostname check before disabling anything.
Three different questions get answered by three different parts of an OpenVPN profile, and merging them is how people end up switching off a check that was working. Is the peer certificate signed by the authority I trust? Does that certificate declare the TLS server role? Is it the particular server I meant to reach? remote-cert-tls server answers only the middle one, and it does so by reading extensions inside the certificate.
Three checks that are easy to merge in your head
The trust anchor lives in the ca directive. The role check belongs to remote-cert-tls. The identity check belongs to verify-x509-name, when a profile uses it, or to whatever name checking the deployment adds.
They cover different failures:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
A profile can have all three and still be weak if the CA is shared too widely, which is a key-management question rather than a directive question.
What the role check reads
The directive is a macro. It expands into a key-usage requirement and an extended-key-usage requirement naming the TLS Web Server role, so the peer certificate must actually declare that purpose. A certificate issued for client authentication does not satisfy it, even when the same authority signed both.
That matters because a shared CA is common in small deployments. One authority signs every client and the server, and without a role check any of those certificates could complete the server side of the handshake. The check does not make that scenario impossible, but it removes the trivial version of it.
The directive is asymmetric by design: clients carry remote-cert-tls server, and servers carry remote-cert-tls client. Swap them and every connection fails with a role error that looks like a broken certificate.
Older profiles sometimes use ns-cert-type for the same purpose. Current manual pages treat that option as superseded, so a profile that still relies on it is worth migrating rather than debugging.
Why disabling it feels like a fix
When the role check fails, the connection stops with a verification error and the obvious move is to delete the line. The connection then comes up, which feels like progress and is actually the failure mode the directive exists to prevent. You now accept a peer whose certificate was never intended for that role.
Read the error instead. It names the check that failed, and the certificate on the other side can be inspected to see which extensions it really carries. Two minutes of reading settles whether the fault is issuance or configuration. Guessing costs an afternoon and usually ends with a weakened profile. A renewed server certificate that lost its extended key usage is a real fault in the renewal, not a reason to relax the client.
The name check is a separate directive
Satisfying the role check says the peer is some server signed by your authority. It says nothing about which one, which matters when the same CA issues certificates for several gateways and one of them is compromised or repurposed.
verify-x509-name compares the certificate subject against a value you configure, with matching modes for an exact subject, a prefix or a single field. Use the field that actually identifies the gateway, and expect to update it deliberately when the name changes.
Neither directive replaces good key handling. If the client key file is copied around with the profile, the peer identity is only as strong as the distribution list.
Inspect the certificate before you edit the profile
Read the peer certificate and the client log, in that order. The certificate tells you what roles it declares; the log tells you which check rejected it.
These commands print the usage extensions and the verification lines from a verbose connection:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyIf the extensions show the server role and the log still reports a role failure, the profile is probably pointing at the wrong certificate file rather than at a bad certificate. If the extensions show only client authentication, stop looking at the client and fix the issuance. Either way, restore the check before you call the connection healthy, because a successful handshake after removing verification proves less than the error it replaced.