Hello, all. I'm setting up freeradius-2.1.12-6.el6.x86_64 on CentOS 6, and I'm close to having an acceptable solution, but I've got a couple obnoxious issues I'm not cracking despite diligent searching. A broad outline: My FreeRADIUS is being used by some AeroHive wireless access points to authenticate against AD, and I've got that happening over Centrify using their winbindd stand-in. That all works fine. There are two problems. First, MacOS clients are asked to accept the certificate. It's described as valid, and I'm presenting an intermediate and my cert, and they're hooking that up to a trusted DigiCert certificate and everything is happy... Except, why is it asking the user to accept a cert, and especially one based on a root that's shipped out with every Mac? A twist is that it's a wildcard cert. Does that matter? I can't see anywhere in example configs, cert Makefile, or online searches that folks set any sort of coherent common name that must match. I'm not seeing where FreeRADIUS would even keep this config. The second issue is that Windows clients must turn off cert validation. I suspect that this is because the cert wasn't built with the xpextensions OIDs. We can get a cert that *is* built with them, but coming back to the Mac issue, I wonder what else I'd want to do to make an acceptable certificate. To potentially tie the two issues together, it's conceivable that Macs also want that xpextensions OID stuff, but that seems like a stretch. The Mac clients don't present anything on screen to match against the common name / subject name in the wildcard cert. We can get a cert that's not a wildcard and bake in the Windows-happy OIDs, but I'd really deeply like to craft a cert that's accepted without prompting by our Macs and that's also acceptable to Windows hosts. I suspect that whatever issue is making the Macs prompt us would also be a problem for the Windows clients, above and beyond the Windows clients wanting the xpextensions stuff. This all works if the Macs hand-approve the cert and the Windows users add a network that doesn't validate the cert, but it's a big environment and we want the stuff to work out of the box. (I've heard that best practises are to hand-sign certs with a local CA and make everything trust the local CA, but we really want to use a public CA for this.) Thanks in advance for help. -- Mason Loring Bliss mason@blisses.org http://blisses.org/ "I am a brother of jackals, and a companion of ostriches." (Job 30 : 29)
Hi,
Hello, all. I'm setting up freeradius-2.1.12-6.el6.x86_64 on CentOS 6, and I'm close to having an acceptable solution, but I've got a couple obnoxious issues I'm not cracking despite diligent searching.
my first advice to you is to upgrade - 2.1.12 is *old*. seriously old. it came out in sept 2011 and is no longer maintained. If you go to CentOS 7 you'll get 2.2.x (but once again, you really should be using version 3 now)
First, MacOS clients are asked to accept the certificate. It's described as valid, and I'm presenting an intermediate and my cert, and they're hooking that up to a trusted DigiCert certificate and everything is happy... Except, why is it asking the user to accept a cert, and especially one based on a root that's shipped out with every Mac? A twist is that it's a wildcard cert. Does that matter? I can't see anywhere in example configs, cert Makefile, or online searches that folks set any sort of coherent common name that must match. I'm not seeing where FreeRADIUS would even keep this config.
Mac clients can no longer have 802.1X config done manually in the network config section - they need to be configured using a .mobileconfig file - thats since Lion was released (10.7.x) - most provisioning tools will do this or you can build you own .mobileconfig file using the Apple iPhone enterprise tool (free) the commonname of the cert is its CN as per the output of openssl x509 -in server.pem -text -noout
The second issue is that Windows clients must turn off cert validation. I suspect that this is because the cert wasn't built with the xpextensions OIDs. We can get a cert that *is* built with them, but coming back to the Mac issue, I wonder what else I'd want to do to make an acceptable certificate.
well, you need the xpextensions for sure.... but you also need the root CA to be known and trusted by the device... it doesnt matter if the RADIUS server is handing out the root and the intermediate...the client still has to have a preconfigured trust anchor...ie know the root CA. feeding the intermediates from the RADIUS server help in cases where the client doesnt have the intermediates but only the root. once again, a provisioning tool is the way to go you also need to check a few other things....and since you are using 2.1.x these are probbaly your issues: the DH key should be at least 1024 (yours is probably 512), the certificate method should be at least SHA1, but please consider SHA256
want the stuff to work out of the box. (I've heard that best practises are to hand-sign certs with a local CA and make everything trust the local CA, but we really want to use a public CA for this.)
there are two camps for this....the secure camp is local CA, the easy of use camp is the public CA.... *however* if you are doing things with a configuration tool, then local CA issue for ease of use goes...its configured for the user AND secure. also, if you use a public CA, then ANYONE can get a certificate from that CA for some cash..and trivially do a MITM attack by pretending to be one of your APs and then harvest the logins from all those people whose clients just did a 'click on the SSID' or are configured not to trust the correct commonname..... (forget the CA check because the attacker HAS that CA) - that whole scenario is completely wiped out with a local CA (unless your hacker/attacker works for you and can get a cert signed by that CA ;-) ) alan
my first advice to you is to upgrade - 2.1.12 is *old*. seriously old. it came out in sept 2011 and is no longer maintained. If you go to CentOS 7 you'll get 2.2.x (but once again, you really should be using version 3 now)
Well, on CentOS 7 you should be getting 3.0.x, actually... That was John's last gift before he moved on as FR maintainer ;-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
Well, on CentOS 7 you should be getting 3.0.x, actually... That was John's last gift before he moved on as FR maintainer ;-)
Yup, and amusingly (to me), you now get TLS 1.2 support for EAP in CentOS 6 with 6.7 as they rebased to 2.2.6 (patched to work now), but not in CentOS 7. Nick
Well, on CentOS 7 you should be getting 3.0.x, actually... That was John's last gift before he moved on as FR maintainer ;-)
Yup, and amusingly (to me), you now get TLS 1.2 support for EAP in CentOS 6 with 6.7 as they rebased to 2.2.6 (patched to work now), but not in CentOS 7.
I saw you raising the TLS support for 2.x... Is there a similar ticket for v3 in Bugtraq? ;-) There's a *lot* of change between 3.0.4 (I think that's the latest in CentOS 7) and 3.0.9 (soon 3.0.10), so it's difficult for RH to just pull those changes across without breaking configs (although I suspect it's probably things like correct_escapes that would cause more drama than the bug fixes). :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
I saw you raising the TLS support for 2.x... Is there a similar ticket for v3 in Bugtraq? ;-)
The difference there was that Red Hat had already rebased to 2.2.6 in RHEL 6.7 so they were in the position where TLS 1.2 would be negotiated and there'd subsequently be invalid MPPE keys in the Access-Accept rather than just TLS 1.0 being negotiated, clear bug territory. With 3.0.4, with no TLS 1.2 support being present, TLS 1.0 will be negotiated by the EAP client so there's technically no bug to fix. I doubt they'll consider rebasing 3.0.4 to 3.0.10 or later, buy they ought to IMO with the next point release of RHEL 7. Nick
On 24 Sep 2015, at 07:53, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
my first advice to you is to upgrade - 2.1.12 is *old*. seriously old. it came out in sept 2011 and is no longer maintained. If you go to CentOS 7 you'll get 2.2.x (but once again, you really should be using version 3 now)
Well, on CentOS 7 you should be getting 3.0.x, actually... That was John's last gift before he moved on as FR maintainer ;-)
Yes, but they seem fixated on 3.0.4 unfortunately. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Thu, Sep 24, 2015 at 08:00:59AM -0400, Arran Cudbard-Bell wrote:
Well, on CentOS 7 you should be getting 3.0.x, actually... That was John's last gift before he moved on as FR maintainer ;-)
Yes, but they seem fixated on 3.0.4 unfortunately.
Like most distributions; out of touch with reality in the name of "stability", at least with how FreeRADIUS code releases work. Does anyone know if there is an active Debian maintainer at the moment? Testing has a fairly recent version 2, but there's no version 3 in sight. Keep thinking I should have a hack at it myself, but I'd probably get too frustrated without being able to just go up to the latest version. Cherry-picking bugfixes isn't my idea of fun when there's already a released version out that fixes the problem. Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
version 3 in sight. Keep thinking I should have a hack at it myself, but I'd probably get too frustrated without being able to just go up to the latest version. Cherry-picking bugfixes isn't my idea of fun when there's already a released version out that fixes the problem.
Well, there was a volunteer a while back. The Moonshot repository is at v3.0.7(+) :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On 24-09-15 14:14, Matthew Newton wrote:
Does anyone know if there is an active Debian maintainer at the moment? Testing has a fairly recent version 2, but there's no version 3 in sight. Keep thinking I should have a hack at it myself, but I'd probably get too frustrated without being able to just go up to the latest version. Cherry-picking bugfixes isn't my idea of fun when there's already a released version out that fixes the problem.
The official maintainer (Josip Rodin) seems to be MIA or retired. The latest Debian release (Jessie, released in april this year) has been updated to 2.2 instead of 2.1, which at least resolves a number of problems, those have been Non-Maintainer Uploads from Sam Hartman (he also contributed a thing or two to upstream FreeRADIUS). I remember him saying that he wanted to package 3.0.x too, but I can't find it anymore. -- Herwin Weststrate
On Thu, Sep 24, 2015 at 02:34:22PM +0200, Herwin Weststrate wrote:
On 24-09-15 14:14, Matthew Newton wrote:
Does anyone know if there is an active Debian maintainer at the moment? Testing has a fairly recent version 2, but there's no version 3 in sight. Keep thinking I should have a hack at it myself, but I'd probably get too frustrated without being able to just go up to the latest version. Cherry-picking bugfixes isn't my idea of fun when there's already a released version out that fixes the problem.
The official maintainer (Josip Rodin) seems to be MIA or retired. The latest Debian release (Jessie, released in april this year) has been updated to 2.2 instead of 2.1, which at least resolves a number of problems, those have been Non-Maintainer Uploads from Sam Hartman (he also contributed a thing or two to upstream FreeRADIUS). I remember him saying that he wanted to package 3.0.x too, but I can't find it anymore.
Ah, yes - it's Sam's name I remember, but couldn't find as any of the current freeradius packages maintainers. I'm sure the package name will need to change to freeradius3 for the official Debian version because of the extensive config changes required, but that doesn't show up anywhere either. It shouldn't be too hard to get a package made up, based on the existing debian/ dir in the source tree, I'm sure - it'll have to be set to a 3.0 format (not native) and a few other bits. As with all things, guess it just needs a bit of TLC. Added note is that the current debian package in FR doesn't build cleanly - first time make fails with rlm_sqlhpwippool (which is odd as it's not listed in 'stable') but re-run dpkg-buildpackage and the second time it works fine, which indicates another problem because the debian/rules clean isn't cleaning up properly :) Trying to work this one out at the moment for our local install, but I'm going to have to stop shortly for other things so will continue next week if possible. Matthew -- Matthew Newton, Ph.D. <mcn4@le.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>
Hi,
Does anyone know if there is an active Debian maintainer at the moment? Testing has a fairly recent version 2, but there's no version 3 in sight. Keep thinking I should have a hack at it myself, but I'd probably get too frustrated without being able to just go up to the latest version. Cherry-picking bugfixes isn't my idea of fun when there's already a released version out that fixes the problem.
theres been several fixes for it recently....and a few other nice bits - Arrans trying ot get them to be the maintainer ;-) alan
On Thu, Sep 24, 2015 at 08:19:31AM +0000, A.L.M.Buxey@lboro.ac.uk wrote:
my first advice to you is to upgrade - 2.1.12 is *old*. seriously old. it came out in sept 2011 and is no longer maintained. If you go to CentOS 7 you'll get 2.2.x (but once again, you really should be using version 3 now)
Is there any issue you can think of using 3.0.9 on CentOS 6? I don't mind building it from source if the infrastructure will support it.
Mac clients can no longer have 802.1X config done manually in the network config section - they need to be configured using a .mobileconfig file
Alright. Thanks. I'll look at this.
the commonname of the cert is its CN as per the output of
openssl x509 -in server.pem -text -noout
Oh, I know this part, but I'm wondering how the CN is *used*. Specifically, is my FreeRADIUS server sending something that has to match the cert? If my server is foo.bar.com, does it actually send its hostname to the client that's trying to connect? The examples I've found so far have CNs that are more or less freeform, quoted strings. Related, my goal once I've worked out the details is to have a small cluster of these. I can load-balance between them but I was thinking more of having a freestanding pool. If FreeRADIUS is sending its hostname for matching this would be problematic done through a load balancer, and if I'm not doing it through a load balancer it seems like I'd need one certificate per FreeRADIUS server, rather than having a shared cert for the role, especially if I can't use wildcards. Maybe the local CA option will be best here. I'll explore it. Knowing how the CN is used between the client and server would be great, though. In this case, it's assumed that the clients won't have other access to the network until they authenticate and connect through the WAPs and FreeRADIUS.
well, you need the xpextensions for sure.... but you also need the root CA to be known and trusted by the device...
The DigiCert CA certificate was known by the Macs already, but I'll look at the provisioning mechanism(s) you described to see if there was something there.
*however* if you are doing things with a configuration tool, then local CA issue for ease of use goes...its configured for the user AND secure.
This sounds more and more appealing the more I think about it. Thanks for the help thus far! I'll write back more if I get stumped by other things, but for now I'm going to try to get 3.0.9 on my EL6 test box and look at the provisioning situation. -- Mason Loring Bliss mason@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I
Hi,
Is there any issue you can think of using 3.0.9 on CentOS 6? I don't mind building it from source if the infrastructure will support it.
MPPE issue in 3.0.9 - wait until 3.0.10 (if you've got TTLS clients and TLS 1.2 around......) :-) some around here would say to use 3.1.x - all depends on how you feel. I have 3.1.x on a couple of production systems...stability isnt an issue from my experience and I needed the features....
Oh, I know this part, but I'm wondering how the CN is *used*. Specifically, is my FreeRADIUS server sending something that has to match the cert? If my
your server sends its cert (the one with the CN)..and the client is configured to check that value. the servers hostname isnt in the mix at all. its identity is only via the CN in the server string...which means.... yes, you've got it, if you have multiple servers you can have exactly the same server certificate on all of them making your client config very nice and simple (and meaning you DONT need wildcards or nasty things like that)
CN is used between the client and server would be great, though. In this case, it's assumed that the clients won't have other access to the network until they authenticate and connect through the WAPs and FreeRADIUS.
assumed? thats exactly how it works :-) alan
Hi, I'm not clear on what the exact circumstances are that trigger the problem. We have 3.0.9, and I was able to authenticate with iOS 9 and EAP-TTLS without any apparent problems. We're on RHEL 6, so TLS 1.2 is supported on the server. What am I missing? Sebastian
MPPE issue in 3.0.9 - wait until 3.0.10 (if you've got TTLS clients and TLS 1.2 around......) :-)
-- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universität zu Köln / Cologne University - Tel. +49-221-470-89578
What am I missing?
You're missing that the change was reverted in the iOS 9 GM due to the current compatibility bite. If you look at a packet capture of the EAPOL, you'll see TLS 1.0 being negotiated and used in the EAP exchange. That's likely to change again when all the cards are in order. Nick
What am I missing?
You're missing that the change was reverted in the iOS 9 GM due to the current compatibility bite. If you look at a packet capture of the EAPOL, you'll see TLS 1.0 being negotiated and used in the EAP exchange.
That's likely to change again when all the cards are in order.
Thanks! Somehow that part of the discussion went past me. -- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universität zu Köln / Cologne University - Tel. +49-221-470-89578
You cannot use a wildcard certificate with Windows clients, EAPhost does not support it. Nick On Thu, Sep 24, 2015 at 1:24 AM, Mason Loring Bliss <mason@blisses.org> wrote:
Hello, all. I'm setting up freeradius-2.1.12-6.el6.x86_64 on CentOS 6, and I'm close to having an acceptable solution, but I've got a couple obnoxious issues I'm not cracking despite diligent searching.
A broad outline: My FreeRADIUS is being used by some AeroHive wireless access points to authenticate against AD, and I've got that happening over Centrify using their winbindd stand-in. That all works fine.
There are two problems.
First, MacOS clients are asked to accept the certificate. It's described as valid, and I'm presenting an intermediate and my cert, and they're hooking that up to a trusted DigiCert certificate and everything is happy... Except, why is it asking the user to accept a cert, and especially one based on a root that's shipped out with every Mac? A twist is that it's a wildcard cert. Does that matter? I can't see anywhere in example configs, cert Makefile, or online searches that folks set any sort of coherent common name that must match. I'm not seeing where FreeRADIUS would even keep this config.
The second issue is that Windows clients must turn off cert validation. I suspect that this is because the cert wasn't built with the xpextensions OIDs. We can get a cert that *is* built with them, but coming back to the Mac issue, I wonder what else I'd want to do to make an acceptable certificate.
To potentially tie the two issues together, it's conceivable that Macs also want that xpextensions OID stuff, but that seems like a stretch.
The Mac clients don't present anything on screen to match against the common name / subject name in the wildcard cert. We can get a cert that's not a wildcard and bake in the Windows-happy OIDs, but I'd really deeply like to craft a cert that's accepted without prompting by our Macs and that's also acceptable to Windows hosts. I suspect that whatever issue is making the Macs prompt us would also be a problem for the Windows clients, above and beyond the Windows clients wanting the xpextensions stuff.
This all works if the Macs hand-approve the cert and the Windows users add a network that doesn't validate the cert, but it's a big environment and we want the stuff to work out of the box. (I've heard that best practises are to hand-sign certs with a local CA and make everything trust the local CA, but we really want to use a public CA for this.)
Thanks in advance for help.
-- Mason Loring Bliss mason@blisses.org http://blisses.org/ "I am a brother of jackals, and a companion of ostriches." (Job 30 : 29) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Herwin Weststrate -
Mason Loring Bliss -
Matthew Newton -
Nick Lowe -
Sebastian Hagedorn -
Stefan Paetow