- Freeradius-Users - lists.freeradius.org

EAP-TLS 1.3 support (RFC 9190)
by Stephan P. 08 Nov '24

08 Nov '24

Hello together, I only have a general technical question. Does FreeRADIUS server support EAP-TLS 1.3 (as described in RFC9190)? And if yes, beginning with which version of FreeRADIUS? I looked in the changelogs, TLS 1.3 support is mentioned for EAP-TTLS and EAP-PEAP (but not for EAP-TLS) (-> version 3.0.26 (2022.09.20) and version 3.2.2 (2023.02.16)). I haven't found anything explicit about it in the documents, only the "TLS 1.3 Configuration" mailing list thread from Boby Tharappel implicating feature support. Thanks in advance. Greetings, Stephan

2 1

Re:
by Alan DeKok 07 Nov '24

07 Nov '24

On Nov 7, 2024, at 1:49 PM, Дмитрий Ахлестин <akhlestin.dmitry(a)yandex.ru> wrote: > Hello, Freeradius users, There is no need to email me directly. I read the list. > I'm engineer who is developing support of 802.1x at network operation system(NOS) based at zebos/ocnos. > At the moment my current task is to add support of CoA(change of authorization) requests from freeradius: disable exact port(make it notauthorize), restart exact port, re- authorization of user. > But I have several problems and questions: > 1. Do you know exact RFC which I can use for making my own(my vendor) CoA-Request message? I mean exact set up of TLV fields as u can see at attached example for cisco traffic. We're not going to look at zip files, they are not helpful. If you need to know what goes in a CoA-Request packet which is sent to a Cisco device, then read the Cisco documentation. If you want to invent your own attributes to go into a CoA-Request packet, then that won't work. The reasons are too complex to explain in a short message. > 2. How and what should I change at freeradius settings and configuration files that I could send such CoA request from freeradius to Authenticator? See sites-available/originate-coa. This is documented. We are not going to give a step-by-step guide for configuring your exact system. The Cisco documentation explains what the Cisco devices need in a CoA packet. The FreeRADIUS documentation explains how to configure FreeRADIUS to send attributes. It's up to you to put those together. > 3. Possible you have some examples of traffic which contains some CoA requests? Can you share it with me? Google. Or, read the Cisco documentation. Alan DeKok.

1 0

Status-Server Segfault in 3.0.27
by Adam Bishop 06 Nov '24

06 Nov '24

I'm sure I read about this issue on the list around the release of 3.0.27/3.0.5 and had thought it was fixed but searching for it in the list archive isn't coming up with anything recent. This one is running 3.0.27 - the server is segfaulting when it tries to probe a remote radius server that is unreachable: No response to status check 5 ID 75 for home server 193.63.195.50 port 1812 bt full follows at the end of the email. I do have plans to upgrade to 3.2 but not before I'd like this particular system in production. Is this a known/previously seen issue, or am I inventing a memory? Many Thanks, Adam --- #0 0x0000555555587244 in request_stats_final (request=0x555555a69bb0) at src/main/stats.c:99 listener = <optimized out> client = <optimized out> auth_stats = <optimized out> coa_stats = <optimized out> #1 0x000055555558f811 in request_stats_final (request=0x555555a69bb0) at src/main/stats.c:91 listener = <optimized out> client = <optimized out> auth_stats = <optimized out> coa_stats = <optimized out> dsc_stats = <optimized out> done = <optimized out> proxy_stats = <optimized out> #2 request_done (request=0x555555a69bb0, original=<optimized out>) at src/main/process.c:921 now = {tv_sec = 93824996240744, tv_usec = -7131984328893351168} when = {tv_sec = 140737488347520, tv_usec = 1} action = <optimized out> #3 0x0000555555591b73 in request_ping (request=0x555555a69bb0, action=<optimized out>) at src/main/process.c:3788 home = <optimized out> buffer = "193.63.195.50\000\000\000 x\246UUU\000\000\000\000\000\000\000\000\000\000x\330\363\367\377\177\000\000\024\206\345\367\377\177\000\000\020\020\246UUU\000\000\060\000\000\000\000\000\000\000\310n\222UUU\000\000X\234\246UUU\000\000Pm\222UUU\000\000\001\000\000\000\000\000\000\000\020\020\246UUU\000\000\t\244\345\367\377\177\000\000Y4[UUU\000\000B4[UUU\000" __FUNCTION__ = "request_ping" #4 0x00007ffff7f33abb in fr_event_run (when=0x7fffffffe180, el=0x555555926d50) at src/lib/event.c:321 callback = 0x555555587a80 <request_timer> ctx = 0x555555a69bb0 ev = <optimized out> callback = <optimized out> ctx = <optimized out> ev = <optimized out> #5 fr_event_run (el=el@entry=0x555555926d50, when=when@entry=0x7fffffffe180) at src/lib/event.c:278 callback = <optimized out> ctx = <optimized out> ev = <optimized out> #6 0x00007ffff7f36c3f in fr_event_loop (el=0x555555926d50) at src/lib/event.c:691 i = <optimized out> rcode = 0 when = {tv_sec = 1730907338, tv_usec = 458268} wake = <optimized out> read_fds = {fds_bits = {0 <repeats 16 times>}} write_fds = {fds_bits = {0 <repeats 16 times>}} #7 0x000055555556c3cc in main (argc=<optimized out>, argv=<optimized out>) at src/main/radiusd.c:641 rcode = 0 status = <optimized out> argval = <optimized out> spawn_flag = true display_version = false flag = 0 from_child = {-1, -1} p = <optimized out> state = <optimized out> autofree = 0x5555555d8620 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Commercial Limited is a wholly owned Jisc subsidiary and a company limited by shares which is registered in England under company number 09316933, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice

2 1

Plans for adding PQC support
by Mike Luken (mluken) 06 Nov '24

06 Nov '24

What are the plans for adding post-quantum crypto (PQC) support into FreeRADIUS?

2 1

Problem verifying EAP-TLS certificates (untrusted warning)
by Alexey D. Filimonov 06 Nov '24

06 Nov '24

I have a problem with warning about "untrusted certificate" and rejecting if set "reject_unknown_intermediate_ca = yes". Could you help me solving this issue? In short, this is the problem: > Tue Nov 5 22:37:37 2024 : Warning: Certificate chain - 1 cert(s) untrusted > Tue Nov 5 22:37:37 2024 : Warning: (TLS) untrusted certificate with depth [1] subject name /O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority > Tue Nov 5 22:37:37 2024 : Warning: (TLS) untrusted certificate with depth [0] subject name /O=OD.FREEIPA.XYZ/CN=rpi4b.od.freeipa.xyz I have One-Tier PKI. On FreeRADIUS server I copied client certificate and CA to /tmp/certs: 802_1x.crt and 802_1x.ca.crt . On FreeRADIUS server I have server certificate issued by the same CA. To check certificates I run commands under same user FreeRADIUS runs: `su freerad -s /bin/bash`. Check if both CAs same ``` freerad@radius2:/root$ md5sum /tmp/certs/802_1x.ca.crt /etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt e65a3b9362b313ed3a10a3ce4a3588e5 /tmp/certs/802_1x.ca.crt e65a3b9362b313ed3a10a3ce4a3588e5 /etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt ``` Check if both CAs are self-signed and same: ``` freerad@radius2:/root$ openssl x509 -noout -text -in /etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt | grep -A1 'Key Identifier' X509v3 Subject Key Identifier: CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79 X509v3 Authority Key Identifier: CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79 freerad@radius2:/root$ openssl x509 -noout -text -in /tmp/certs/802_1x.ca.crt | grep -A1 'Key Identifier' X509v3 Subject Key Identifier: CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79 X509v3 Authority Key Identifier: CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79 ``` Check if client and server certificate is issued by this CA: ``` freerad@radius2:/root$ openssl x509 -noout -text -in /tmp/certs/802_1x.crt | grep -A1 'Authority Key Identifier' X509v3 Authority Key Identifier: CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79 freerad@radius2:/root$ openssl x509 -noout -text -in /etc/freeradius/3.0/tls/certs/wifi.crt | grep -A1 'Authority Key Identifier' X509v3 Authority Key Identifier: CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79 ``` Check if client both client and server certificates are issued by same CA (here I see "untrusted"): ``` freerad@radius2:/root$ openssl verify -verbose -crl_download -crl_check -show_chain -verify_depth 10 -issuer_checks -no_alt_chains -check_ss_sig -CAfile /etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt -CApath /etc/freeradius/3.0/tls/certs/ca/wifi /tmp/certs/802_1x.crt /tmp/certs/802_1x.crt: OK Chain: depth=0: O = OD.FREEIPA.XYZ, CN = rpi4b.od.freeipa.xyz (untrusted) depth=1: O = OD.FREEIPA.XYZ, CN = OD.FREEIPA.XYZ Certificate Authority freerad@radius2:/root$ openssl verify -verbose -crl_download -crl_check -show_chain -verify_depth 10 -issuer_checks -no_alt_chains -check_ss_sig -CAfile /etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt -CApath /etc/freeradius/3.0/tls/certs/ca/wifi /etc/freeradius/3.0/tls/certs/wifi.crt /etc/freeradius/3.0/tls/certs/wifi.crt: OK Chain: depth=0: O = OD.FREEIPA.XYZ, CN = radius2.od.freeipa.xyz (untrusted) depth=1: O = OD.FREEIPA.XYZ, CN = OD.FREEIPA.XYZ Certificate Authority ``` Copied (under root) to ca store and run `c_rehash /etc/ssl/certs`. Found that my CA cert is already here. ``` root@radius2:~# mkdir /usr/share/ca-certificates/wifi root@radius2:~# cp /etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt /usr/share/ca-certificates/wifi root@radius2:~# chmod -R 755 /usr/share/ca-certificates/wifi root@radius2:~# ls -laR /usr/share/ca-certificates/wifi /usr/share/ca-certificates/wifi: total 12 drwxr-xr-x 2 root root 4096 Nov 5 21:44 . drwxr-xr-x 4 root root 4096 Nov 5 21:43 .. -rwxr-xr-x 1 root root 1598 Nov 5 21:44 wifi.ca.crt root@radius2:~# ln -s /usr/share/ca-certificates/wifi/wifi.ca.crt /etc/ssl/certs/wifi.ca.crt root@radius2:~# ls -la /etc/ssl/certs/wifi.ca.crt lrwxrwxrwx 1 root root 43 Nov 5 21:46 /etc/ssl/certs/wifi.ca.crt -> /usr/share/ca-certificates/wifi/wifi.ca.crt root@radius2:~# c_rehash /etc/ssl/certs Doing /etc/ssl/certs WARNING: Skipping duplicate certificate ca-certificates.crt WARNING: Skipping duplicate certificate ca-certificates.crt WARNING: Skipping duplicate certificate wifi.ca.crt WARNING: Skipping duplicate certificate wifi.ca.crt ``` Still no luck. Run `c_rehash /etc/freeradius/3.0/tls/certs/ca/wifi` (this is where wifi.ca.crt is also added) and added `ca_path = "/etc/freeradius/3.0/tls/certs/ca/wifi"` ``` root@radius2:~# ls -laR /etc/freeradius/3.0/tls/certs/ca/wifi/ /etc/freeradius/3.0/tls/certs/ca/wifi/: total 12 drwxr-xr-x 2 freerad freerad 4096 Nov 5 21:48 . drwxr-xr-x 3 freerad freerad 4096 Nov 5 20:32 .. lrwxrwxrwx 1 root root 11 Nov 5 21:48 577f4bb3.0 -> wifi.ca.crt lrwxrwxrwx 1 root root 11 Nov 5 21:48 ed3eb11a.0 -> wifi.ca.crt -rwxr-xr-x 1 freerad freerad 1598 Nov 5 20:34 wifi.ca.crt ``` Still no luck. This is my EAP config: ``` # /etc/freeradius/3.0/mods-available/eap_wifi eap eap_wifi { default_eap_type = tls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests} tls-config tls_eap_wifi { private_key_file = "/etc/freeradius/3.0/tls/private/wifi.key" certificate_file = "/etc/freeradius/3.0/tls/certs/wifi.crt" ca_file = "/etc/freeradius/3.0/tls/certs/ca/wifi/wifi.ca.crt" ca_path = "/etc/freeradius/3.0/tls/certs/ca/wifi" auto_chain = yes cipher_list = "HIGH" check_crl = no check_all_crl = no cipher_server_preference = no tls_min_version = "1.2" tls_max_version = "1.2" ecdh_curve = "prime256v1" reject_unknown_intermediate_ca = yes } tls { tls = tls_eap_wifi configurable_client_cert = no } } ``` This is part of `freeradius -X` log: ``` > (7) # Executing group from file /etc/freeradius/3.0/sites-enabled/wifi > (7) Auth-Type eap_wifi { > (7) eap_wifi: Expiring EAP session with state 0xe7b966f3e1e06b16 > (7) eap_wifi: Finished EAP session with state 0xe7b966f3e1e06b16 > (7) eap_wifi: Previous EAP request found for state 0xe7b966f3e1e06b16, released from the list > (7) eap_wifi: Peer sent packet with method EAP TLS (13) > (7) eap_wifi: Calling submodule eap_tls to process data > (7) eap_tls: (TLS) EAP Got final fragment (321 bytes) > (7) eap_tls: (TLS) EAP Done initial handshake > (7) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write server done > (7) eap_tls: (TLS) recv TLS 1.2 Handshake, Certificate > (7) eap_tls: (TLS) Creating attributes from server certificate > (7) eap_tls: TLS-Cert-Serial := "01" > (7) eap_tls: TLS-Cert-Expiration := "441018201402Z" > (7) eap_tls: TLS-Cert-Valid-Since := "241018201402Z" > (7) eap_tls: TLS-Cert-Subject := "/O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority" > (7) eap_tls: TLS-Cert-Issuer := "/O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority" > (7) eap_tls: TLS-Cert-Common-Name := "OD.FREEIPA.XYZ Certificate Authority" > (7) eap_tls: (TLS) Creating attributes from client certificate > (7) eap_tls: TLS-Client-Cert-Serial := "22" > (7) eap_tls: TLS-Client-Cert-Expiration := "250104182310Z" > (7) eap_tls: TLS-Client-Cert-Valid-Since := "241105182310Z" > (7) eap_tls: TLS-Client-Cert-Subject := "/O=OD.FREEIPA.XYZ/CN=rpi4b.od.freeipa.xyz" > (7) eap_tls: TLS-Client-Cert-Issuer := "/O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority" > (7) eap_tls: TLS-Client-Cert-Common-Name := "rpi4b.od.freeipa.xyz" > (7) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Dns := "rpi4b.od.freeipa.xyz" > (7) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Upn := "host/rpi4b.od.freeipa.xyz(a)OD.FREEIPA.XYZ" > (7) eap_tls: TLS-Client-Cert-X509v3-Authority-Key-Identifier += "CD:4B:3C:31:60:D9:81:22:75:1B:47:4E:50:AB:3B:FB:5A:68:85:79" > (7) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication, 1.3.6.1.5.5.7.3.14" > (7) eap_tls: TLS-Client-Cert-X509v3-Subject-Key-Identifier += "F1:BC:FD:76:AC:E4:92:AD:A1:82:81:79:25:CC:1D:09:63:15:C9:00" > (7) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2" > (7) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.14" > Certificate chain - 1 cert(s) untrusted > (TLS) untrusted certificate with depth [1] subject name /O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority > (TLS) untrusted certificate with depth [0] subject name /O=OD.FREEIPA.XYZ/CN=rpi4b.od.freeipa.xyz > tls: There are untrusted certificates in the certificate chain. Rejecting. > (7) eap_tls: (TLS) send TLS 1.2 Alert, fatal internal_error > (7) eap_tls: ERROR: (TLS) Alert write:fatal:internal error > (7) eap_tls: ERROR: (TLS) Server : Error in error > (7) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:0A000086:SSL routines::certificate verify failed > (7) eap_tls: ERROR: (TLS) System call (I/O) error (-1) > (7) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation > (7) eap_tls: ERROR: [eaptls process] = fail > (7) eap_wifi: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed > (7) eap_wifi: Sending EAP Failure (code 4) ID 89 length 4 > (7) eap_wifi: Failed in EAP select > (7) [eap_wifi] = invalid ``` The piece around warning when `freeradius -X -xx` is used: ``` ... Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.14" Tue Nov 5 22:37:37 2024 : Warning: Certificate chain - 1 cert(s) untrusted Tue Nov 5 22:37:37 2024 : Warning: (TLS) untrusted certificate with depth [1] subject name /O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority Tue Nov 5 22:37:37 2024 : Warning: (TLS) untrusted certificate with depth [0] subject name /O=OD.FREEIPA.XYZ/CN=rpi4b.od.freeipa.xyz Tue Nov 5 22:37:37 2024 : Auth: tls: There are untrusted certificates in the certificate chain. Rejecting. Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) chain-depth : 0 Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) error : 0 Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: identity : anonymous-od-type-a Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) common name : rpi4b.od.freeipa.xyz Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) subject : /O=OD.FREEIPA.XYZ/CN=rpi4b.od.freeipa.xyz Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) issuer : /O=OD.FREEIPA.XYZ/CN=OD.FREEIPA.XYZ Certificate Authority Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) verify return : 0 Tue Nov 5 22:37:37 2024 : Debug: (TLS) Ignoring cbtls_msg call with pseudo content type 256, version 771 Tue Nov 5 22:37:37 2024 : Debug: (TLS) Received 2 bytes of TLS data Tue Nov 5 22:37:37 2024 : Debug: (TLS) 02 50 Tue Nov 5 22:37:37 2024 : Debug: (15) eap_tls: (TLS) send TLS 1.2 Alert, fatal internal_error Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_tls: (TLS) Alert write:fatal:internal error Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_tls: (TLS) Server : Error in error Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_tls: (TLS) Failed reading from OpenSSL: ../ssl/statem/statem_srvr.c[3522]:error: :SSL routines::certificate verify failed Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_tls: (TLS) System call (I/O) error (-1) Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_tls: (TLS) EAP Receive handshake failed during operation Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_tls: [eaptls process] = fail Tue Nov 5 22:37:37 2024 : ERROR: (15) eap_wifi: Failed continuing EAP TLS (13) session. EAP sub-module failed Tue Nov 5 22:37:37 2024 : Debug: (15) eap_wifi: Sending EAP Failure (code 4) ID 98 length 4 Tue Nov 5 22:37:37 2024 : Debug: (15) eap_wifi: Failed in EAP select Tue Nov 5 22:37:37 2024 : Debug: (15) modsingle[authenticate]: returned from eap_wifi (rlm_eap) Tue Nov 5 22:37:37 2024 : Debug: (15) [eap_wifi] = invalid ... ```

2 2

Windows Machines not Validating Cert
by FreeRAD 06 Nov '24

06 Nov '24

I'm using EAP-TTLS. When generating the production certs I know it says in the readme file that all client machines need to have the root CA installed for it to work, but that doesn't seem to be the case in my setup. If I connect from a windows 11 machine I get a notification asking if I am happy with the certificate information for the server that I am connecting to, but I haven't got the root CA cert installed on my machine. I then just accept the notification and it allows me to connect. Even after installing it nothing really changed. Would this indicate that something is set up wrong with the RADIUS server? The debug logs confirm that a TLS handshake is complete. Many thanks!

3 10

Hashing of Debug Log Passwords
by FreeRAD 06 Nov '24

06 Nov '24

Hi All, I've hashed the passwords in my DB and made it so that the RADIUS server, a) uses the hashed passwords b) doesn't store the cleartext passwords in the 'radpostauth' table. Think I know the answer to this already but is it possible to hash/hide the passwords being seen in the debug logs (e.g. freeradius -X)? Pretty sure this is a no since the server needs to see the password at some point but thought I would ask. Thanks!

2 2

debugging SSL self-signed cert issues
by Malcolm Herbert 05 Nov '24

05 Nov '24

Hi - I've had a long-running setup with freeradius 3.0.16 which I acknowledge is likely quite ancient now, but I've barely had to touch it since I set it up about 4y ago ... I've been using self-signed certificate-based auth for our mobile label printers for some time without problems but after a CA certificate expiry extension (retaining the original CA key, pushing the notAfter date out) and creation of a new server-side certificate on my radius server, the clients will now generate a bad certificate alert whenever I try using it. I can replace the original server-side cert and things are ok again, so - something clearly is wrong with the new cert, but I haven't been able to pinpoint what. The old and new server cert have the same information, barring minor differences between their SANs and relevant dates. I've confirmed that openssl can verify both the old and new server certs against both the old and new CA certs and it seems to think everything is fine. For testing purposes, half the printers have been given the updated CA cert and the others are on the same original CA cert but this side of the equation doesn't appear to change the result - printers configured with either will start having issues if I start using the new server cert. I don't want to spam the list with long radiusd debug traces unless requested as I definitely think this is a cert issue of my own making, but I'm stumped as to how to get more information to isolate the underlying cause. Has anyone else encountered this problem before? Here's just the SSL negotiation in the working (original server cert) case: : : (1) Found Auth-Type = eap (1) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (1) authenticate { (1) eap: Expiring EAP session with state 0x8abbb4538a68ad3a (1) eap: Finished EAP session with state 0x8abbb4538a68ad3a (1) eap: Previous EAP request found for state 0x8abbb4538a68ad3a, released from the list (1) eap: Peer sent packet with method EAP PEAP (25) (1) eap: Calling submodule eap_peap to process data (1) eap_peap: Continuing EAP-TLS (1) eap_peap: Peer indicated complete TLS record size will be 296 bytes (1) eap_peap: Got complete TLS record (296 bytes) (1) eap_peap: [eaptls verify] = length included (1) eap_peap: (other): before SSL initialization (1) eap_peap: TLS_accept: before SSL initialization (1) eap_peap: TLS_accept: before SSL initialization (1) eap_peap: <<< recv UNKNOWN TLS VERSION ?0304? [length 0123] (1) eap_peap: TLS_accept: SSLv3/TLS read client hello (1) eap_peap: >>> send TLS 1.2 [length 0039] (1) eap_peap: TLS_accept: SSLv3/TLS write server hello (1) eap_peap: >>> send TLS 1.2 [length 0d2c] (1) eap_peap: TLS_accept: SSLv3/TLS write certificate (1) eap_peap: >>> send TLS 1.2 [length 01cd] (1) eap_peap: TLS_accept: SSLv3/TLS write key exchange (1) eap_peap: >>> send TLS 1.2 [length 0004] (1) eap_peap: TLS_accept: SSLv3/TLS write server done (1) eap_peap: TLS_accept: Need to read more data: SSLv3/TLS write server done (1) eap_peap: In SSL Handshake Phase (1) eap_peap: In SSL Accept mode (1) eap_peap: [eaptls process] = handled (1) eap: Sending EAP Request (code 1) ID 212 length 1004 (1) eap: EAP session adding &reply:State = 0x8abbb4538b6fad3a (1) [eap] = handled (1) } # authenticate = handled (1) Using Post-Auth-Type Challenge (1) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (1) Challenge { ... } # empty sub-section is ignored : : Here is the same again in the failed (new server cert) case: : : (5) Found Auth-Type = eap (5) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (5) authenticate { (5) eap: Expiring EAP session with state 0x5f15dbf65b3fc265 (5) eap: Finished EAP session with state 0x5f15dbf65b3fc265 (5) eap: Previous EAP request found for state 0x5f15dbf65b3fc265, released from the list (5) eap: Peer sent packet with method EAP PEAP (25) (5) eap: Calling submodule eap_peap to process data (5) eap_peap: Continuing EAP-TLS (5) eap_peap: Peer indicated complete TLS record size will be 7 bytes (5) eap_peap: Got complete TLS record (7 bytes) (5) eap_peap: [eaptls verify] = length included (5) eap_peap: <<< recv TLS 1.2 [length 0002] (5) eap_peap: ERROR: TLS Alert read:fatal:bad certificate (5) eap_peap: TLS_accept: Need to read more data: error (5) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate (5) eap_peap: In SSL Handshake Phase (5) eap_peap: In SSL Accept mode (5) eap_peap: SSL Application Data (5) eap_peap: ERROR: TLS failed during operation (5) eap_peap: ERROR: [eaptls process] = fail (5) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (5) eap: Sending EAP Failure (code 4) ID 42 length 4 (5) eap: Failed in EAP select (5) [eap] = invalid (5) } # authenticate = invalid (5) Failed to authenticate the user (5) Using Post-Auth-Type Reject (5) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (5) Post-Auth-Type REJECT { : : Regards, Malcolm -- Malcolm Herbert mjch(a)mjch.net

2 2

Duplicate "object" definition
by Alex Zetaeffesse 04 Nov '24

04 Nov '24

Hi all, I apologize if I don't use the right terminology. I'm playing/testing with 3.2.6 to better understand how freeradius behaves when finding duplicate definitions. I created a copy of the filter policy, calling it policy.d/filter2 and I defined the object/policy filter_username in this way: filter_username { if (&User-Name) { reject } } Now, when in the directory policy.d I only have the file filter2, I always get the expected Access-Reject, if I just have the default file filter I get Access-Accept (the user is correctly configured in the file users). If I have both files (filter and filter 2), when I launch radiusd -X I get, the file filter is loaded first and then the file filter2 ... *including configuration file /etc/freeradius/policy.d/filter <<<*including configuration file /etc/freeradius/policy.d/operator-name including configuration file /etc/freeradius/policy.d/eap including configuration file /etc/freeradius/policy.d/debug including configuration file /etc/freeradius/policy.d/accounting *including configuration file /etc/freeradius/policy.d/filter2 <<<* ... and I always get Access-Accept. How are duplicate objects treated? Is the first definition that's retained or the last? From my experiment it seems the first is retained. May you please confirm? Regards, Alex

3 3

Check LDAP if object exist with filter based on user's certificate attributest after EAP-TLS auth succeeds?
by Alexey D. Filimonov 04 Nov '24

04 Nov '24

In short, I have EAP-TLS auth, and I need to check if there is an LDAP object that has value of `TLS-Client-Cert-Subject-Alt-Name-Upn` in `krbCanonicalName` attribute and it's `createTimestamp` is less or equal than `TLS-Client-Cert-Valid-Since` value. 1. I found that `TLS-Client-Cert-Subject-Alt-Name-Upn` attribute is created only inside `authenticate { Auth-Type eap { ... }}` section. Is it correct that I have no access to certificate properties inside `authorize` section? 2. Next, I found that according to [rlm_ldap guide from networkradius](https://www.networkradius.com/doc/current/raddb/mods-availab…, ldap module can `look for user` only inside `authorize` section, but not inside `authenticate`. Is it correct I can not make a check for existence of an object in LDAP from `authenticate` section using `rlm_ldap` module, and only xlat-ing can be used? 3. I found that there are some xlat functions exposed by `rlm_ldap` module, but they are only mentioned in my `mods-available/ldap`, and not documented in `3.2.x` branch on github. I vave FreeRADIUS version from debian-stable and it is `3.2.1`. Is raddb/mods-available/ldap from master branch is useful as documentation for 3.2.1 ldap?

2 3