Opened 7 months ago

Last modified 5 months ago

#1370 new Bug / Defect

Return common_name of cert not username when trigger Renegotiate process

Reported by: cahome Owned by:
Priority: major Milestone:
Component: Certificates Version: OpenVPN 2.4.9 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: Renegotiate common_name
Cc: plaisthos

Description

Platform:
Centos 7

Version:
OpenVPN 2.4.9 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2020
library versions: OpenSSL 1.0.2k-fips 26 Jan 2017, LZO 2.06
Originally developed by James Yonan

Description
In my configuration file, "auth-user-pass-verify", "username-as-common-name", "client-connect" and "client-disconnect" are enabled. All clients use one same client cert.
Due to "username-as-common-name", the connect and disconnect scripts can get the variable "common_name" of username from client.
However, if either server or client triggers "Renegotiate" prosess, in "Reference manual for OpenVPN 2.4" it says "Renegotiate data channel key after n seconds (default=3600)", and "auth-user-pass-verify" scripts return 1 indicating auth failure, the "client-disconnect" scripts will be triggered with "common_name" of client cert not username anymore.
This bug causes the disconnect script cannot update status of specific user to database.

Change History (1)

comment:1 Changed 5 months ago by Gert Döring

Cc: plaisthos added
Milestone: release 2.4.9

Can you please re-try with 2.5.0 and, if possible, with git master?

The whole renegotiate thing, especially renegotiation *failure*, has been a very fragile code path with lots of corner cases (like username-as-common-name) that could go wrong.

We have worked on it quite a bit before 2.5.0, and more on git master after 2.5 release, so it's possible that it is already working there... or maybe not.

Note: See TracTickets for help on using tickets.