I was working on adding new Linux devices to my existing OpenVPN instance and no matter what I do, I get this error (note, PII swapped with <Value> brackets, but they are correct values). It seems that opnSense is generating incorrect ovpn files that miss the CN portion of the Subject.
2026-09-06T03:42:25.164197-07:00 user-precision nm-openvpn[14463]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2026-09-06T03:42:25.164761-07:00 user-precision nm-openvpn[14463]: TCP/UDP: Preserving recently used remote address: [AF_INET]<public_ipv4>:1194
2026-09-06T03:42:25.164985-07:00 user-precision nm-openvpn[14463]: UDPv4 link local: (not bound)
2026-09-06T03:42:25.165140-07:00 user-precision nm-openvpn[14463]: UDPv4 link remote: [AF_INET]<public_ipv4>:1194
2026-09-06T03:42:25.180286-07:00 user-precision nm-openvpn[14463]: VERIFY ERROR: could not extract CN from X509 subject string ('C=<Country>, ST=<State>, L=<City>, O=Personal, emailAddress=<email@email.com>') -- note that the field length is limited to 64 characters
2026-09-06T03:42:25.180367-07:00 user-precision nm-openvpn[14463]: OpenSSL: error:0A000086:SSL routines::certificate verify failed:
2026-09-06T03:42:25.180394-07:00 user-precision nm-openvpn[14463]: TLS_ERROR: BIO read tls_read_plaintext error
2026-09-06T03:42:25.180424-07:00 user-precision nm-openvpn[14463]: TLS Error: TLS object -> incoming plaintext read error
2026-09-06T03:42:25.180450-07:00 user-precision nm-openvpn[14463]: TLS Error: TLS handshake failed
2026-09-06T03:42:25.180476-07:00 user-precision nm-openvpn[14463]: SIGUSR1[soft,tls-error] received, process restarting
Strangely enough, when using the official OpenVPN App on an iOS device everything works as expected. I export the client certificate, I open the ovpn file, I change no values, I connect. This bug seems specific to my Linux devices.
Current Server Stats:
OPNsense 26.7.3_11-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8
Current Client Stats:
Linux Mint 22.3
openssl/noble-updates,noble-security,now 3.0.13-0ubuntu3.15 amd64
Notably, the file that comes from opnSense Client Export has this at the top, missing the CN.
verify-x509-name "C=<Country>, ST=<State>, L=<City>, O=Personal, emailAddress=<email@email.com>" subject
I tried manually modifying the file prior to import to include the CN, which did not work. I also tried disabling TLS Validation:
verify-x509-name "C=<Country>, ST=<State>, L=<City>, O=Personal, emailAddress=<email@email.com>, CN=<username>"
Looking at the contents of the <cert> section of the ovpn file, we get this from "openssl x509 -in ~/Downloads/user-laptop-x509.txt -noout -text":
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11 (0xb)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = <Country>, ST = <State>, L = <City>, O = Personal, emailAddress = <email@email.com>, CN = intermediate-ca
Validity
Not Before: Mar 2 08:24:50 2026 GMT
Not After : Apr 3 08:24:50 2027 GMT
Subject: C = <Country>, ST = <State>, L = <City>, O = Personal, emailAddress = <email@email.com>, CN = <username>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<MODULUS>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Netscape Comment:
OPNsense Generated Client Certificate
X509v3 Subject Key Identifier:
<X509v3 Subject Key Identifier>
X509v3 Authority Key Identifier:
keyid:<X509v3 Authority Key Identifier>
DirName:/C=<Country>/ST=<State>/L=<City>/O=Personal/emailAddress=<email@email.com>/CN=intermediate-ca
serial:00
X509v3 Extended Key Usage:
TLS Web Client Authentication
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
Anyone got any idea what's going on here?
This can be marked as solved. I was of course following the docs for the new Instance Based "Road Warrior" setup, which can be found here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html
In there, the tiniest comment "Leaf Certificate - Type Server: Set the Common Name to the FQDN of this machine." bears all the weight here. You must set a CN value, no matter what it is, for things to work. I don't use a FQDN on my router yet, so I had omitted it. I put one that is a subdomain of my actual domain, but is not an actual DNS entry anywhere on my network. The other "Self-Signed Certificate Chains" doc also points to this, saying to put "leaf-certificate.example.com". See: https://docs.opnsense.org/manual/how-tos/self-signed-chain.html
Once I had reissued the certificate the OpenVPN instance was using, I restarted the instance from the Dashboard. I exported the ovpn client file again and imported.
RANT: Can we please get better warnings in OpnSense??!! I've been using it for 7+ years now and every single problem I have pulled my hair on can be chalked down to "UI does not clearly tell you what is a required field or warn you of obvious issues."
If modern OpenVPN/openssl implementations demand a CN, then it should either:
1) Be a required field when creating a new leaf certificate.
2) Flagged as a health status issue up top that says "Your OpenVPN instance certificate chain is missing a Common Name."
I'm tired boss. This took 5+ hours out of a good weekend. A tiny sentence, not in bold, not italicized, with no warnings from the router itself. That took 5 hours.