Checking TLS-Cert-* and and accept/reject based on them

Matthew Newton mcn4 at
Wed Feb 8 11:35:44 CET 2012


On Fri, Feb 03, 2012 at 12:52:20PM +0000, Matthew Newton wrote:
> On Fri, Feb 03, 2012 at 11:25:30AM +0100, Alan DeKok wrote:
> > Matthew Newton wrote:
> > > However, I looked at and implemented a different solution, which
> > > seems to work really well. Taking ideas from inner-tunnels and the
> > > SoH check method, I added a virtual_server option to the tls

I've just built a service with this, and there are couple of nice
things that I didn't expect (I was just hoping to do some unlang
on the certificate data!)

First is that you can call the detail module, to get a record of
the certificate details easily in a log. Putting detail in
post-auth before didn't work as, in post-auth, detail logs the
response not the request.

I've now got a detail instance in both the tls virtual-server and
the post-auth / post-auth reject. This gets me a single log file
with two (only) entries for each connection request - both the
request AVPs, the certificate data, and the response.

Second is that I can call LDAP from the TLS virtual server and
check group membership of the connecting device. Without this, you
have to call LDAP in the inner tunnel (or outer, if you're doing
plain EAP-TLS), and it gets called each time around the
challenge-response loop, which hits the LDAP server more than
necessary. Here, it just gets called once (see [0] for similar
with PEAP/MS-CHAPv2). It's similar to the eap { ok = return } you
can do for PEAP, but for EAP-TLS.




Matthew Newton, Ph.D. <mcn4 at>

Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at>

More information about the Freeradius-Devel mailing list