Opened 2 years ago

Closed 13 months ago

#1370 closed Bug / Defect (fixed)

Return common_name of cert not username when trigger Renegotiate process

Reported by: cahome Owned by:
Priority: major Milestone: release 2.5.5
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, tct

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 (4)

comment:1 Changed 22 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.

comment:2 Changed 13 months ago by Gert Döring

Cc: tct added

@tct this sounds like a duplicate of "your" ticket, no?

comment:3 Changed 13 months ago by tct

This sounds very similar to #1434 (#160)

comment:4 Changed 13 months ago by Gert Döring

Milestone: release 2.5.5
Resolution: fixed
Status: newclosed

So, anyway, this has been fixed in "master", "release/2.5" and "release/2.4", and the fix will be in 2.5.5 -> setting milestone accordingly, and closing.

If we ever do another 2.4.x release, it will also be in that one (2.4.12).

commit fa5ab2438ad2d8a12eaf43e2cdd8b4294299c175
Author: Selva Nair <selva.nair@…>
Date: Fri Oct 22 20:07:05 2021 -0400

Ensure the current common_name is in the environment for scripts

Note: See TracTickets for help on using tickets.