When dealing with OpenVPN certificate verification, even the smallest discrepancy can cause major headaches. In this case, we see a classic example where the certificate authority (CA) uses state abbreviation "VA" while the server certificate shows "Virginia". OpenSSL may accept this during manual verification, but OpenVPN's stricter TLS implementation will reject it.

// Example of problematic certificate subject
subject= /C=US/ST=VA/L=Arlington/O=ExampleOrg/CN=Example CA
// VS server certificate showing:
subject= /C=US/ST=Virginia/L=Arlington/O=ExampleOrg/CN=vpn.example.com

OpenVPN performs certificate verification in multiple stages:

1. Validates the entire chain from your client cert back to the root CA
2. Checks for proper signatures at each level
3. Verifies all subject fields match exactly between issuing and issued certificates

To properly fix this, we need to regenerate certificates with consistent naming. Here's the complete process:

# First, recreate your CA with consistent naming
openssl req -new -x509 -days 3650 -newkey rsa:2048 \
-keyout ca.key -out ca.crt \
-subj "/C=US/ST=Virginia/L=Arlington/O=ExampleOrg/CN=Example CA"

# Then generate server cert using the same format
openssl req -new -newkey rsa:2048 \
-keyout server.key -out server.csr \
-subj "/C=US/ST=Virginia/L=Arlington/O=ExampleOrg/CN=vpn.example.com"

# Sign the server cert
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 365

Ensure your OpenVPN client config includes these critical directives:

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-version-min 1.2
cipher AES-256-CBC
auth SHA256
verb 3

Always test your certificates before deployment:

# Verify certificate chain
openssl verify -CAfile ca.crt server.crt

# Check subject/issuer consistency
openssl x509 -in server.crt -noout -subject -issuer

# Examine the full certificate
openssl x509 -in server.crt -noout -text

If issues persist, enable deeper OpenVPN logging:

verb 4
tls-export-cert /tmp/vpn-certs

This will dump the actual certificates being used during negotiation for comparison.

When OpenVPN throws a "self-signed certificate in chain" error despite proper CA verification, the devil is often in the subject field mismatches. The case you're seeing - where ST=VA in the CA certificate doesn't match ST=Virginia in the error - reveals a critical PKI principle:

// What OpenSSL sees (correct):
subject= /C=US/ST=VA/L=**/O=**/CN=** CA/emailAddress=**

// What OpenVPN complains about (incorrect):
/C=US/ST=Virginia/L=**/O=**/CN=**/emailAddress=**

OpenVPN performs stricter validation than openssl verify. While the latter checks cryptographic validity, OpenVPN additionally enforces:

• Exact subject field matching across the chain
• RFC 5280 compliant distinguished name formatting
• State/province fields must use official abbreviations

To diagnose such issues systematically:

# 1. Inspect all certificates in the chain
openssl x509 -in ca.crt -text -noout | grep -E 'Subject:|Issuer:'
openssl x509 -in intermediate.crt -text -noout | grep -E 'Subject:|Issuer:'
openssl x509 -in client.crt -text -noout | grep -E 'Subject:|Issuer:'

# 2. Verify subject field consistency
openssl verify -CAfile ca.crt -show_chain -policy_check client.crt

# 3. Check OpenVPN's perspective
openvpn --config client.ovpn --verb 4

For this specific case where state abbreviations don't match:

1. Regenerate the CA certificate using proper state abbreviations:

openssl req -x509 -newkey rsa:2048 -keyout ca.key -out ca.crt \
-subj "/C=US/ST=VA/L=Arlington/O=Example Corp/CN=Example CA"

2. Reissue all certificates in the chain using consistent naming:

openssl req -new -key client.key -out client.csr \
-subj "/C=US/ST=VA/L=Arlington/O=Example Corp/CN=client1"

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -out client.crt

If you cannot modify the certificates, these OpenVPN config directives may help (use with caution):

# Relax certificate validation
remote-cert-tls server
ns-cert-type server

# Or for testing only (INSECURE)
tls-version-min 1.2
verify-x509-name server name-prefix

Remember that proper PKI hygiene is always better than workarounds. The 5 minutes spent regenerating certificates correctly saves hours of debugging later.