Hi FR Users, I've gotten to the point where both our *.acme.com server cert and CA cert are working correctly. Since we are using public CA-signed e-mail certificates, I am looking to do some further checks before sending the Access-Accept from EAP. /etc/raddb/sites-available/check-eap-tls appears to be the correct virtual server to do the check. The information I am looking to check against is in the value-pair: TLS-Client-Cert-Subject. When checking the debug, I found the information I'm looking for at chain-depth=0 in the chain (the first two certs are the primary CA and intermediate CA). Will check-eap-tls use the information at chain-depth=0? The information I get from TLS-Client-Cert-Subject has a lot of information, and I only want to check the domain of the emailAddress portion of what is sent to the server: (18) eap_tls : <<< TLS 1.0 Handshake [length 11fa], Certificate (18) eap_tls : chain-depth=2, (18) eap_tls : error=0 (18) eap_tls : --> User-Name = Matthew West (18) eap_tls : --> BUF-Name = VeriSign Class 2 Public Primary Certification Authority - G3 (18) eap_tls : --> subject = /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 2 Public Primary Certification Authority - G3 (18) eap_tls : --> issuer = /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 2 Public Primary Certification Authority - G3 (18) eap_tls : --> verify return:1 (18) eap_tls : chain-depth=1, (18) eap_tls : error=0 (18) eap_tls : --> User-Name = Matthew West (18) eap_tls : --> BUF-Name = Symantec Class 2 Shared Intermediate Certificate Authority (18) eap_tls : --> subject = /C=US/O=Symantec Corporation/OU=Symantec Trust Network/OU=Class 2 Managed PKI Individual Subscriber CA/CN=Symantec Class 2 Shared Intermediate Certificate Authority (18) eap_tls : --> issuer = /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 2 Public Primary Certification Authority - G3 (18) eap_tls : --> verify return:1 (18) eap_tls : chain-depth=0, (18) eap_tls : error=0 (18) eap_tls : --> User-Name = Matthew West (18) eap_tls : --> BUF-Name = Matthew West (18) eap_tls : --> subject = /CN=Matthew West/OU=S/MIME/O=ACME, LLC/emailAddress=matthew.west@acme.com (18) eap_tls : --> issuer = /C=US/O=Symantec Corporation/OU=Symantec Trust Network/OU=Class 2 Managed PKI Individual Subscriber CA/CN=Symantec Class 2 Shared Intermediate Certificate Authority I would like to check the subject only for the inclusion of our domain, acmetech.com, but am new to string manipulation using unlang. I would like the function to work as following, but don't have the syntax correct. if ("%{TLS-Client-Cert-Subject}" == (* + "acme.com") { update config { Auth-Type := Accept } } else { update config { Auth-Type := Reject } update reply { Reply-Message := "Your certificate is not valid." } } Your input is appreciated. Thank You, Matthew West On Fri, Sep 9, 2016 at 3:53 PM, Matthew West <matthew.t.west@gmail.com> wrote:
Would that remediate any security concerns, or would that still leave room for abuse?
You can start with a known good secure situation where you have control over all the variables, and do a little bit more work to really tighten it down. Or you could start from a know less secure situation where other people have control over your infrastructure, and try and patch it up to stop people getting in who shouldn't.
Your choice... but I know which one I'd go for to make sure access to my network was secure.
Thanks for your input everyone. I was assured the CA certificate we are using is not a globally known CA and our e-mail/auth certificates were issued with it.
The only issue I'm dealing with now is the space being present in the User-Name . I'm hoping with the right regular expression I can grab only what we are to be expecting in the User-Name field (i.e 'User Name'), although I see a few e-mail certificates that break this rule.
On FreeRADIUS, look at OCSP in mods-available/eap, and sites-available/check-eap-tls (also in mods-available/eap).
OK, great. That has everything I'm looking for. Our PKI manager will either issue me a CRL or I'll set up with OCSP. Thank you all for your help. I'll let you know how everything turns out.
Enjoy your weekend!
Matthew West
On Fri, Sep 9, 2016 at 12:36 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Fri, Sep 09, 2016 at 09:41:17AM -0700, Matthew West wrote:
To this, my technical lead on the project said: ] Need to look at two things here – ] * CRL checks – so that revoked certs do not authenticate ] * Certificate Whitelist of sorts – So only our bunch of certs authenticate
It is apparent that he understands the implication of using the VeriSign chain as our CA. Is it possible to achieve a cert whitelist, say, filter on the e-mail address presented in the certificate?
On FreeRADIUS, look at OCSP in mods-available/eap, and sites-available/check-eap-tls (also in mods-available/eap).
Would that remediate any security concerns, or would that still leave room for abuse?
You can start with a known good secure situation where you have control over all the variables, and do a little bit more work to really tighten it down. Or you could start from a know less secure situation where other people have control over your infrastructure, and try and patch it up to stop people getting in who shouldn't.
Your choice... but I know which one I'd go for to make sure access to my network was secure.
Matthew
-- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html