Assertion failed at socket.c: 2719 (buf_defined(&sb->next)) caused by duplicate CN

[tct]

Ref: ​ https://forums.openvpn.net/viewtopic.php?f=4&t=31444

Using duplicate CNs on a server which does not define --duplicate-cn causes ASSERT on the client.

[Gert Döring]

The log is not verbose enough to see what is going on (this seems to be "default verb", not "verb 4").

From what I could see, this is the *client* crashing, if someone else connects to the same *server* with a duplicate CN. Which does not make any sense at all, as the client wouldn't even see "the other" client.

Now, if the server sends a client exit message, *and* this is sort of being misparsed, or triggering something that is new on 2.5.0, this would start to make sense - but lots of guesswork.

It would be really really good to have a) the full client and server config (without secret material, of course) and b) a client log with verb 4 .

I *guess* this is related to TCP, and the server cuts the TCP connection in an unfriendly way, so when the client tries to get the next message out of the stream buffer, there is none. But the code really should handle that, otherwise we'd have many more reports about "my TCP session was broken, and then openvpn died".

Since I do not have much time, I'm not going to chase this unless I have more logs.

[tct]

I'll see if I can replicate this.

[tct]

Corrected Forum URL

[tct]

Trying to replicate this I ran into:

2020-12-16 01:13:16 us=659448 OpenVPN 2.6_git [git:master/a4eeef17b20541a7] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 13 2020
2020-12-16 01:13:16 us=659476 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
2020-12-16 01:13:16 us=661118 OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
2020-12-16 01:13:16 us=661155 Cannot load private key file [[INLINE]]
2020-12-16 01:13:16 us=661199 Error: private key password verification failed
2020-12-16 01:13:16 us=661218 Exiting due to fatal error

I used Easy-RSA renew to recreate this Client certificate and it is inlined in the config.

The reason to renew was to replicate this circumstance from the OP:

I have issued individual certificate/key pairs for each of clients but all have the same common name (CN).

I believe it does not have a password, this is the renewal log from EasyRSA:

root@arch-hyv-live-64 ec_secp384r1 # EASYRSA_CERT_RENEW=10000 ./easyrsa renew v303.tct.secp384r1.c01 nopass

Note: using Easy-RSA configuration from: /root/easyrsa3/test/ec_secp384r1/vars
Using SSL: openssl OpenSSL 1.1.1h  22 Sep 2020


Please confirm you wish to renew the certificate with the following subject:

subject=
    countryName               = 00
    stateOrProvinceName       = tct
    localityName              = home
    organizationName          = tctnet
    organizationalUnitName    = tctnet-secp384r1
    commonName                = v303.tct.secp384r1.c01
    emailAddress              = me@home.org


Type the word 'yes' to continue, or any other input to abort.
  Continue with renew: yes
rm: cannot remove '/root/easyrsa3/test/ec_secp384r1/pki/certs_by_serial/02.pem': No such file or directory
Generating an EC private key
writing new private key to '/root/easyrsa3/test/ec_secp384r1/pki/easy-rsa-87119.ySajil/tmp.nX9T5M'
-----
Using configuration from /root/easyrsa3/test/ec_secp384r1/pki/easy-rsa-87119.ySajil/tmp.FiOhG7
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'00'
stateOrProvinceName   :ASN.1 12:'tct'
localityName          :ASN.1 12:'home'
organizationName      :ASN.1 12:'tctnet'
organizationalUnitName:ASN.1 12:'tctnet-secp384r1'
commonName            :ASN.1 12:'v303.tct.secp384r1.c01'
emailAddress          :IA5STRING:'me@home.org'
Certificate is to be certified until Mar 21 00:39:49 2023 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

root@arch-hyv-live-64 ec_secp384r1 #

This error:

rm: cannot remove '/root/easyrsa3/test/ec_secp384r1/pki/certs_by_serial/02.pem': No such file or directory

Is not a fatal error, the PEM file never existed in the first place.

There is something fishy here but IDKW ..

Hunch: The duplicate CN check out ranks the serial number check ?

[tct]

Never mind ..

From the EasyRSA log above:

Generating an EC private key
writing new private key to '/root/easyrsa3/test/ec_secp384r1/pki/easy-rsa-87119.ySajil/tmp.nX9T5M'

Key not accounted for this time.

[tct]

I managed to get two clients with the same CN and unique keys and certs (as described by the OP) bouncing all over the place with various time-outs and other insignificant errors. The server was not using --duplicate-cn .

I was unable to trigger the ASSERT failure.

I did not test --dev tap or --tls-cipher "DEFAULT:@SECLEVEL=0" ..

[Gert Döring]

Thanks for trying to pinpoint this.

Have you used UDP or TCP mode? This is definitely impossible to trigger in UDP mode, as the function raising the ASSERT() is only used to extract "OpenVPN messages" out of a TCP stream.

--tls-cipher *should* not play a role, but it might influence message size, so, who knows.

[tct]

Now tested with TCP also .. no ASSERT triggered.

In TCP, the clients simply bounce each other, as you would expect.

Until the Forum OP responds with finite details, I am going to drop this.

[Gert Döring]

So can we close this?