OpenVPN: self-signed certificate in certificate chain

I normally rotate between two identical Linksys EA7300 v2 routers, and so I did to upgrade from 23.05.4 to 24.10.0.

This at first look seemed to work without a hitch. On second look my two OpenVPN tunnels did not work. I was able to fix one of them, but the other refused with this error:

VERIFY ERROR: depth=1, error=self-signed certificate in certificate chain: C=DE, ST=Bavaria, L=Munich, O=B-5 Colocation Administration, CN=B-5 Colocation Administration CA, emailAddress=admin@ns.b-5.de, serial=12118597303198206453

I did quite a bit of searching around but most people who got the same error did not notice it. Just like @ mgazzin in his thread.

I found one (hopefully) solution: Small OpenVPN setup with peer-fingerprint. I have not tried this yet because I ran out of steam. I'll try tomorrow when my boiler has enough pressure

Strangely only one of the tunnels works without this problem. I had to generate new certs on the other machine because the certificates were too old. They all had this: Signature Algorithm: sha1WithRSAEncryption`. Well, they are about seven years old... So I assume that the certs on the other host (generated in August 2024) are OK because they were generated by an older version of easy-rsa. The two hosts run parallel on Debian 12 aka bookworm.

I'm posting this now in the hope that somebody ran into the same and found a solution and to report when (hopefully) I find one.

Plan B is currently to generate the certs on the machine that has working certs. But IIRC we upgraded to bookworm after August 2024, so the certs may not work either.

So you are asking for help with easyrsa on debian? Wrong forum bro.

I fear it's you who is frequenting the wrong forum. Or who is not reading what people post.

Please try again. I have a tip for you: start with the title.

You are trying to use a CA certificate as the client certificate. This will not work. Certificates with the CA flag set can only be used as the CA. The top level CA is always self-signed.

As OpenVPN is upgraded to higher versions, they like to deprecate encryption methods that are deemed insecure, and refuse to connect when old algorithms are involved. SHA1 is likely to suffer that fate soon if it hasn't already.

OK, let's have a look at my server, here are the files it uses:

dh /etc/openvpn/tls-buexe.files/dh4096.pem
ca /etc/openvpn/tls-buexe.files/ca.crt
cert /etc/openvpn/tls-buexe.files/buexe.crt
key /etc/openvpn/tls-buexe.files/buexe.key

Checking the ca.crt and the buexe.crt:

# openssl x509 -noout -text -in /etc/openvpn/tls-buexe.files/ca.crt | grep CA:
                CA:TRUE
# openssl x509 -noout -text -in /etc/openvpn/tls-buexe.files/buexe.crt | grep CA:
                CA:FALSE

Looks OK to me. Now for the client:

ca /etc/openvpn/buexe_client_udp.files/ca.crt
dh /etc/openvpn/buexe_client_udp.files/dh.pem
cert /etc/openvpn/buexe_client_udp.files/feldafing.crt
key /etc/openvpn/buexe_client_udp.files/feldafing.key

$ openssl x509 -noout -text -in buexe_client_udp.files/ca.crt | grep CA:
                CA:TRUE
                serial:5C:58:8F:CA:44:F8:42:7D:C6:93:FF:C3:7F:39:49:10:08:5D:3F:7A

$ openssl x509 -noout -text -in buexe_client_udp.files/feldafing.crt | grep CA:
                CA:FALSE
                serial:5C:58:8F:CA:44:F8:42:7D:C6:93:FF:C3:7F:39:49:10:08:5D:3F:7A

You are referring to the CN, the Common Name. That is just a name and yes, I forgot to remove the CA. But that's just two characters and a space. The CA flag is found here:

        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE

That is the flag I extracted above with grep CA:.

That happened to me once, only solution was to make new keys/certs, see:

The CA having the same CN as the user certificate is a problem. Within the certificate it says "name" signed by "name" i.e. self-signed. The file names do not matter. All certificates in the system (that aren't an exact copy being reused on multiple clients, which is allowed but not recommended) need unique CN.

OK, I'll try with new certificates.

@egc: I generated those certificates yesterday, so there are from the most recent copy of easy-rsa Debian stable has.

# openssl x509 -noout -dates -in /etc/openvpn/easy-rsa/pki/issued/buexe.crt
notBefore=Apr  3 17:43:22 2025 GMT
notAfter=Jul  7 17:43:22 2027 GMT

Thank you.

If you use the standard settings for key length etc. as minimum then you should be good.

From the vars file:

set_var EASYRSA_REQ_COUNTRY     "DE"
set_var EASYRSA_REQ_PROVINCE    "Bavaria"
set_var EASYRSA_REQ_CITY        "Munich"
set_var EASYRSA_REQ_ORG         "B-5 Colocation Administration"
set_var EASYRSA_REQ_OU          ""
set_var EASYRSA_REQ_EMAIL       "admin@ns.b-5.de"
set_var EASYRSA_NS_SUPPORT      "yes"

Everything else is at default. I haven't touched this at least since 2021.

Having a look at three certificates:
ca.crt:

Subject: CN = B-5 Colocation Administration CA
            X509v3 Basic Constraints: 
                CA:TRUE

server.crt:

Issuer: CN = B-5 Colocation Administration CA
Subject: CN = server
X509v3 Basic Constraints: 
                CA:FALSE
X509v3 Subject Alternative Name: 
                DNS:server

client.crt:

Issuer: CN = B-5 Colocation Administration CA
X509v3 Basic Constraints: 
                CA:FALSE

Note that the client cert has no X509v3 Subject Alternative Name. Neither does the CA certificate.

It is some time ago I used EasyRSA to make my keys, nowadays OpenVPN is only a backup server, I mostly implement WireGuard.

If you are interested here are my notes with a chapter about using EasyRSA (it is for windows but for linux it should work the same): https://forum.dd-wrt.com/phpBB2/download.php?id=44043

it is from a website of an alternative third party firmware but the key setup is of course the same

P.S. DH.PEM is not necessary any more just add --dh none in the server config and it will use ECDH

Interesting. I was't aware of that, when my config is running again I will try it. Right now I'm about to try this: OpenVPN/fingerprint-authentication examples here: Small OpenVPN setup with peer-fingerprint.