Opened 3 years ago
Closed 2 years 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 3 years ago by
| Cc: | plaisthos added |
|---|---|
| Milestone: | release 2.4.9 |
comment:2 Changed 3 years ago by
| Cc: | tct added |
|---|
@tct this sounds like a duplicate of "your" ticket, no?
comment:4 Changed 2 years ago by
| Milestone: | → release 2.5.5 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
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
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.