Bug #11054
open
Check Client Certificate CN not working as described
0%
Description
Page: Services / FreeRADIUS
Tab: EAP
Section: EAP-TLS
Option: Check Client Certificate CN
Actual result when enabled:
A user attempting TLS authentication with a certificate signed by the configured CA, and with a common name matching the user-provided identity, passes authentication even if that common name/identity is not a valid user configured under FreeRADIUS / Users. This option only seems to ensure the common name of the client certificate matches the user-provided identity.
Expected result when enabled:
A user attempting TLS authentication does not pass authentication unless the client certificate's common name is equal to the user-provided identity AND is a configured user under FreeRADIUS / Users, as alluded to by the description.
Updated by Viktor Gurov about 3 years ago
see http://freeradius.1045715.n5.nabble.com/user-name-and-EAP-TLS-td5714550.html:
> On Sat, Aug 04, 2012 at 11:10:38AM +0200, Klaus Klein wrote:
>> Therefore I'm a bit puzzled that if no matching entry in users
>> is found that the authentication still takes place.
>
authorize {
files
if (notfound || noop) {
reject
}
}
Updated by Viktor Gurov about 3 years ago
Updated by Renato Botelho about 3 years ago
- Status changed from New to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Updated by Viktor Gurov about 3 years ago
more fixes:
- Fixes SQL backend user existing check;
- Fixes counters issue (`$varsqlconfauthcounters` lines)
https://forum.netgate.com/topic/160323/freeradius-latest-package-upgrade/2:
(6) exec: Executing: /bin/sh /usr/local/etc/raddb/scripts/datacounter_auth.sh raduser1 daily: (6) exec: ERROR: Program returned code (99) and output '' (6) exec: ERROR: Program returned invalid code (greater than max rcode) (99 > 9)
https://gitlab.netgate.com/pfSense/FreeBSD-ports/-/merge_requests/38
Updated by Jim Pingle about 3 years ago
- Status changed from Feedback to Pull Request Review
Updated by Renato Botelho about 3 years ago
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
Updated by Azamat Khakimyanov over 2 years ago
- Status changed from Feedback to Assigned
Tested on 21.05_2 and on 22.01-DEVELOPMENT (built on Tue Dec 14 06:23:27 UTC 2021)
I can't make EAP-TLS working for EAP-RADIUS Mobile IPsec with Ubuntu as a Client.
1. I created Mobile IPsec with local FreeRadius as an Authentication Server,
2. I create CA and Server and Client Certificates (used https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-eap-tls.html)
- Server Certificate had Server IP as a CN
- Client Certificate had client username as a CN
3. remote IPsec client was Ubuntu 21.10 with IKE2 module installed
4. whatever I was changing on client I always got
(5) eap: Peer sent packet with method EAP TLS (13)
(5) eap: Calling submodule eap_tls to process data
(5) eap_tls: (TLS) EAP Peer says that the final record size will be 157 bytes
(5) eap_tls: (TLS) EAP Got all data (157 bytes)
(5) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write server done
(5) eap_tls: (TLS) recv TLS 1.2 Handshake, Certificate
(5) eap_tls: (TLS) send TLS 1.2 Alert, fatal handshake_failure
(5) eap_tls: ERROR: (TLS) Alert write:fatal:handshake failure
(5) eap_tls: ERROR: (TLS) Server : Error in error
(5) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate
(5) eap_tls: ERROR: (TLS) System call (I/O) error (-1)
(5) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation
(5) eap_tls: ERROR: [eaptls process] = fail
(5) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed
(5) eap: Sending EAP Failure (code 4) ID 5 length 4
(5) eap: Failed in EAP select
(5) [eap] = invalid
(5) } # authenticate = invalid
(5) Failed to authenticate the user
in log on FreeRadius Server.
and on Ubuntu
Dec 14 14:17:06 Ubuntu charon-nm: 09[TLS] received TLS cert request for 'CN=NewCA, C=RU, ST=Leningradskaya, L=Saint-Petersburg, O=Netgate, OU=Support TAC
Dec 14 12:22:21 Ubuntu charon-nm: 14[TLS] no TLS peer certificate found for 'newuser', skipping client authentication
Dec 14 12:22:22 Ubuntu charon-nm: 12[ENC] parsed IKE_AUTH response 7 [ EAP/FAIL ]
Dec 14 12:22:22 Ubuntu charon-nm: 12[IKE] received EAP_FAILURE, EAP authentication failed
I was able to initiate IPsec tunnel from Windows 10 by following this guide again: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-mobile-ikev2-eap-tls.html
but there were no difference if I checked on unchecked 'Validate the Client Certificate Common Name' - I was able to connect with any CN. For example there was no vpnuser1 in FreeRadius but I was able to authenticate successfully
(7) Login OK: [vpnuser1/<via Auth-Type = eap>] (from client radius port 12 cli 192.168.122.1814500)
(7) Sent Access-Accept Id 137 from 127.0.0.1:1812 to 127.0.0.1:6969 length 176
(7) MS-MPPE-Recv-Key = 0x9faff18c5724fe06f84022b8b4238c14a2c8ddeacbff90d03c143d0109c61f26
(7) MS-MPPE-Send-Key = 0xcb63c265dfdb820fb559667f71d3034fa3204f2694cf557ec2bf7ac2cb305494
(7) EAP-Message = 0x03070004
(7) Message-Authenticator = 0x00000000000000000000000000000000
(7) User-Name = "vpnuser1"
(7) Framed-MTU += 994
(7) Finished request
but yes, there were user certificate with CN: vpnuser1
Updated by Greg Maub about 1 year ago
pfSense CE 2.6.0
FreeRADIUS package version 0.15.7_33
As of April 2023, I was able to recreate this issue on accident.
Original description applies perfectly:
"Actual result when enabled:
A user attempting TLS authentication with a certificate signed by the configured CA, and with a common name matching the user-provided identity, passes authentication even if that common name/identity is not a valid user configured under FreeRADIUS / Users. This option only seems to ensure the common name of the client certificate matches the user-provided identity.
Expected result when enabled:
A user attempting TLS authentication does not pass authentication unless the client certificate's common name is equal to the user-provided identity AND is a configured user under FreeRADIUS / Users, as alluded to by the description."
I re-created this issue by using EAP-TLS and the client certificate CN and the user-provided identity match, but there is literally not a corresponding user listed in FreeRADIUS > Users. I could delete all users there and my devices will still connect.
Edited to add:
Confirmed still an issue as of February 2024 with pfSense CE 2.7.2 and FreeRADIUS package version 0.15.10_1
Forum post with screenshot: https://forum.netgate.com/topic/184157/longstanding-freeradius-eap-tls-security-bug-on-validating-client-certificate-common-name