Hi list, I updated freeradius on an Devuan machine from 3.0.17 to 3.2.1. Formerly I checked the client certificate in the virtual server check-eap-tls with the following unlang construct to extract the real User-Name from the certificate: ... if ((&TLS-Client-Cert-Subject-Alt-Name-Email) && (&TLS-Client-Cert-Subject-Alt-Name-Email =~ /@/)) { update request { &User-Name := &TLS-Client-Cert-Subject-Alt-Name-Email } } elsif (&TLS-Client-Cert-Common-Name) { update request { &User-Name := &TLS-Client-Cert-Common-Name } } else { reject } ... In the client certificate file there is also the root ca certificate, and in the former version the second certificate was the client certificate and the code evaluates correct without thoroughly thinking about. Now, the attributes like TLS-Client-Cert-Serial evaluate to the first certificate ie the root ca certificate and the above unlang code return the false User-Name. I want to improve the code and need some hints. I want to iterate over eg &TLS-Client-Cert-Serial[*], search the cert with &TLS-Client-Cert-X509v3-Basic-Constraints[i] =~ /CA:FALSE/, and then extract the User-Name from &TLS-Client-Cert-Subject-Alt-Name-Email[i] or &TLS-Client-Cert-Common-Name[i] How can I get the correct index i from eg foreach &TLS-Client-Cert-Serial to reference to the &TLS-Client-Cert-Subject-Alt-Name-Email[i], for example. A quick fix was to use [n] and choose the last certificate in the file, but this is not clean. -- stefan hartmann
On Jan 9, 2023, at 2:57 PM, Stefan Hartmann <stefanh@hafenthal.de> wrote:
I updated freeradius on an Devuan machine from 3.0.17 to 3.2.1.
Formerly I checked the client certificate in the virtual server check-eap-tls with the following unlang construct to extract the real User-Name from the certificate:
You'll have to use the v3.2.x branch from github, some unrelated changes broke the mapping between certificate fields and attributes. We're trying to get 3.2.2 out soon to address this issue, and to add some features. Alan DeKok.
On Jan 17, 2023, at 12:37 PM, Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:
Dnia Mon, Jan 09, 2023 at 02:58:46PM -0500, Alan DeKok napisał(a):
We're trying to get 3.2.2 out soon to address this issue, and to add some features.
That's great news. Should we expect it in next days, weeks or months?
We're trying to get some TLS / TCP blocking issues fixed. Hopefully by March 1. In the mean time, it's relatively simple to build your own packages and use those. Alan DeKok.
participants (3)
-
Alan DeKok -
Marek Zarychta -
Stefan Hartmann