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

2013-08-29 Thread Axel Thimm
Dear all, 1-2 years ago this topic was discussed and there was a patch by Matthew Newton that was approved for the master branch. I'm now facing the difficulty of accepting/rejecting requests based on the contents of the TLS-Client-Cert for 2.1.12 which does not contain this patch. This is done

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

2013-08-29 Thread Phil Mayers
On 29/08/13 13:21, Axel Thimm wrote: The reason I'm not simply applying the patch is that this system is covered by support by Red Hat and replacing the vendor shipped freeradius (2.1.12) with a self-compiled one voids the support. So any other solution that would allow me to keep the system

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

2013-08-29 Thread Axel Thimm
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote: Otherwise, you could look at the verify { } stanza of the tls { } block in eap.conf; this allows you to run an external script once you've got the client cert, and there you can write any code you want to access the various

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

2013-08-29 Thread Phil Mayers
On 29/08/13 14:25, Axel Thimm wrote: On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote: Otherwise, you could look at the verify { } stanza of the tls { } block in eap.conf; this allows you to run an external script once you've got the client cert, and there you can write any code you

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

2013-08-29 Thread Matthew Newton
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote: Or you could abandon the prejudice against upgrading because it's supported (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in. I don't think it's

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

2013-08-29 Thread stefan.paetow
Agreed on the support contract thing. If something is apparently unsupported when it's broken, just run the supported version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you

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

2013-08-29 Thread Phil Mayers
On 29/08/13 15:09, Matthew Newton wrote: On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote: Or you could abandon the prejudice against upgrading because it's supported (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has

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

2013-08-29 Thread Axel Thimm
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote: On 29/08/13 14:25, Axel Thimm wrote: On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote: Otherwise, you could look at the verify { } stanza of the tls { } block in eap.conf; this allows you to run an external script once

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

2013-08-29 Thread Phil Mayers
On 29/08/13 15:49, stefan.pae...@diamond.ac.uk wrote: That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do. Failing to direct these queries towards your paid support option

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

2013-08-29 Thread Axel Thimm
On Thu, Aug 29, 2013 at 02:49:17PM +, stefan.pae...@diamond.ac.uk wrote: Agreed on the support contract thing. If something is apparently unsupported when it's broken, just run the supported version on a test system, reproduce the problem, and go from there. If you know the problem is