Goodday, In my FreeRadius setup for authenticating WiFi devices with EAP-TLS, I use server- and client SSL certificates from CA provider ' X '. I understand that now everyone with knowledge of this fact, can get a client SSL cert (PKCS#12) from this CA provider X and can authenticate with my WPA2 Enterprise network. After reading the following from the README: "In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organisations in the "ca_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS." I would like to ask the following question. Is there something I can configure on the server side that only certain CommonName's and/or serial's can be used to authenticate correctly? Next to this question, I wonder why also a username (Benutzername) is asked in iOS when we use EAP-TLS with a certificate? I can fill out this field with whatever string and it authenticates in FreeRadius (when a correct cert is presented of course). screenshot: https://hilfe.uni-paderborn.de/images/thumb/4/4f/Eduroam_iOS7_04.png/250px-E... I run version 3.0.11 on Ubuntu 14.04 LTS 64bit. Thank you
Hi,
In my FreeRadius setup for authenticating WiFi devices with EAP-TLS, I use server- and client SSL certificates from CA provider ' X '. I understand that now everyone with knowledge of this fact, can get a client SSL cert (PKCS#12) from this CA provider X and can authenticate with my WPA2 Enterprise network.
No. If your server certificate is from a CA, the client can verify that your server is genuine (if the client side is configured correctly to actually check CA and server name). The *client* certificates /can/ come from the same CA or from a different CA. If you choose the same CA, then yes, you run into the issues below that everybody who got a client certificate from that same CA can authenticate to your network. Since there's no need to go down that route: don't. Issue client certificates from your own self-signed CA, and hand out client certs only to your own account holders. Then, no further checks are needed.
After reading the following from the README:
"In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organisations in the "ca_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS."
Yep; that's good advice :-) It's written in a condensed way as it touches both sides: it's better for the server certs to be from a private CA/self-signed, and it is also better for the client certs to be from a private CA.
I would like to ask the following question. Is there something I can configure on the server side that only certain CommonName's and/or serial's can be used to authenticate correctly?
Yes. There are examples in the shipped tarball of FreeRADIUS for that I think. That does not mean that it's the best idea to go down that route.
Next to this question, I wonder why also a username (Benutzername) is asked in iOS when we use EAP-TLS with a certificate? I can fill out this field with whatever string and it authenticates in FreeRadius (when a correct cert is presented of course). screenshot: https://hilfe.uni-paderborn.de/images/thumb/4/4f/Eduroam_iOS7_04.png/250px-E...
I run version 3.0.11 on Ubuntu 14.04 LTS 64bit.
It's about roaming support. It's a client issue and not for this list, but anyway: If no username is selected, iOS will copy the CN or the eMail field from the cert and use that as username. /usually/ this already contains a domain suffix which can be used for routing, and /usually/ that domain matches the RADIUS realm settings. Sometimes it doesn't - in which case the certificate would work locally, but not in a roaming case where the request needs to be routed correctly. Imagine a client cert with CN="Edward Ulysses Roam" - that's no good for roaming. In this case, you need to configure a different username such as "eduroam@uni-paderborn.de" so that the request gets routed correctly. When you write above that you can use whatever string you like then probably you didn't try this at a remote hotspot. :-) Greetings, Stefan Winter
Thank you - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I would like to ask the following question. Is there something I can configure on the server side that only certain CommonName's and/or serial's can be used to authenticate correctly?
yes check_cert_cn , TLS-Client-Cert-CN , theres also the dynamic OSCP check you can do - but the best thing to do it use a privtae CA for a EAP-TLS system. as for the username - thats the 'outerid' as such - allowing proxying of the to-be-commenced authentication - protecting the real user id from the local RADIUS ssytem, allowing proxying etc without the EAP engine of the local server to be invoked. user@othersite.com - proxied off (as the client wont be able to talk to YOUR RADIUS server - think 'eduroam' :-) ) alan
Hi Stefan, Thank you for the quick reply. On 04-04-16 11:45, Stefan Winter wrote:
No. If your server certificate is from a CA, the client can verify that your server is genuine (if the client side is configured correctly to actually check CA and server name).
With using client: you mean the RADIUS explanation of client? Like the Access Point? or the WLAN device, like a smartphone?
Since there's no need to go down that route: don't. Issue client certificates from your own self-signed CA, and hand out client certs only to your own account holders. Then, no further checks are needed.
Ok, thanks. I will reconsider. It's not that I am too lame to generate new certs and then import them to a handful devices. It's more that I like it that the same client cert in iOS can be used for S/MIME and for auth with WPA2 Enterprise.
Yes. There are examples in the shipped tarball of FreeRADIUS for that I think. That does not mean that it's the best idea to go down that route.
I'll look into that (I think it has something to do with the by Alan suggested check_cert_cn).
When you write above that you can use whatever string you like then probably you didn't try this at a remote hotspot. :-)
Thats correct :D. In fact, last week was the first time I experienced WPA2 Enterprise and only with one (my own) AP. Cheers!
Hi,
No. If your server certificate is from a CA, the client can verify that your server is genuine (if the client side is configured correctly to actually check CA and server name). With using client: you mean the RADIUS explanation of client? Like the Access Point? or the WLAN device, like a smartphone?
In this context, I meant the WLAN device.
Since there's no need to go down that route: don't. Issue client certificates from your own self-signed CA, and hand out client certs only to your own account holders. Then, no further checks are needed. Ok, thanks. I will reconsider. It's not that I am too lame to generate new certs and then import them to a handful devices. It's more that I like it that the same client cert in iOS can be used for S/MIME and for auth with WPA2 Enterprise.
Ah, well that's a reason for using a commercial CA for the client certs indeed. As others have pointed out, attributes like TLS-Client-Cert-CN can be used to compare the cert name against a list of known-good names. Of course you'll have to manage that list of names yourself in config; on a scale of "handful" that's not a problem I guess. But on a larger scale, it will get bothersome. Greetings, Stefan Winter
Yes. There are examples in the shipped tarball of FreeRADIUS for that I think. That does not mean that it's the best idea to go down that route. I'll look into that (I think it has something to do with the by Alan suggested check_cert_cn).
When you write above that you can use whatever string you like then probably you didn't try this at a remote hotspot. :-) Thats correct :D. In fact, last week was the first time I experienced WPA2 Enterprise and only with one (my own) AP.
Cheers!
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Morning, On 6-4-2016 09:31, Stefan Winter wrote:
Ah, well that's a reason for using a commercial CA for the client certs indeed. As others have pointed out, attributes like TLS-Client-Cert-CN can be used to compare the cert name against a list of known-good names. Of course you'll have to manage that list of names yourself in config; on a scale of "handful" that's not a problem I guess. But on a larger scale, it will get bothersome.
Thanks alan and Stefan, I followed your hint of TLS-Client-Cert-Common-Name and used the example from http://security.stackexchange.com/questions/85239/freeradius-eap-tls-authent... and now my config not only checks the validity of the certificate but also that the CommonName matches one of the few domains I control. Cheers, Wouter
Hi All, On 6-4-2016 09:31, Stefan Winter wrote:
No. If your server certificate is from a CA, the client can verify that your server is genuine (if the client side is configured correctly to actually check CA and server name).
After days of work, I still cannot fixed this 100% correct. My client certs -signed by StartSSL- authenticate fine in this WPA2 Enterprise setup. What I cannot get to work is the authentication of my radius server with iPhones running iOS 9.3.2. I keep getting the cert warning that the domain is not trusted. Ofcourse I can choose for 'accept' after the warning, but this is not the best... I own the domain example.com and have a valid cert for server.example.com signed by StartSSL with "StartCom Class 1 DV Server CA". This cert is issued by "StartCom Certification Authority". Both the root CA and the intermediate CA are installed on the two iPhones. All three certs are in /etc/freeradius/certs/ . My EAP config is like this: certdir = ${confdir}/certs cadir = ${confdir}/certs ca_file = /etc/freeradius/certs/both.pem ca_path = /etc/freeradius/certs certificate_file = /etc/freeradius/certs/server.example.com.crt private_key_file = /etc/freeradius/certs/server.example.com.key I have been reading posts like these: http://lists.freeradius.org/pipermail/freeradius-users/2013-August/067987.ht... and trying to make it work with only the root CA in ca_file, together (both.pem in the listing above) with the intermediate cert, with the cert for tommie.example.com in it.. nothing helps. Again, all is working, but I'd like to get rid of the warning! Any help? Using FreeRADIUS on Ubuntu 14.04 with package 3.0.11-ppa2~trusty. Thank you!
Hi All, On 3-7-2016 16:13, Wouter wrote:
I have been reading posts like these: http://lists.freeradius.org/pipermail/freeradius-users/2013-August/067987.ht... and trying to make it work with only the root CA in ca_file, together (both.pem in the listing above) with the intermediate cert, with the cert for tommie.example.com in it.. nothing helps. Again, all is working, but I'd like to get rid of the warning! Any help?
Anyone with a working configuration for FreeRADIUS with StartSSL certificates? Cheers
Hi Wouter Am 05.07.2016 um 20:31 schrieb Wouter:
Hi All,
On 3-7-2016 16:13, Wouter wrote:
I have been reading posts like these: http://lists.freeradius.org/pipermail/freeradius-users/2013-August/067987.ht... and trying to make it work with only the root CA in ca_file, together (both.pem in the listing above) with the intermediate cert, with the cert for tommie.example.com in it.. nothing helps. Again, all is working, but I'd like to get rid of the warning! Any help?
Anyone with a working configuration for FreeRADIUS with StartSSL certificates? Yep, still me.
I renewed our RADIUS server certificate unfortunately almost right before they changed their issuing CAs last year. Depending on your validation with them you might have another intermediate CA or even root CA so be careful at that point. What changed is in the time too is how StartSSL now gives you the signed server certificate. As of 1-2 months ago they gave a zip archive with the signed server certificate and the intermediate certificates combined for i.e. IIS, Apache and nginx formats. I've checked on another more recent certificate and it seems the nginx variant comes in the order of 1. server certificate, 2. intermediate certificate. In this case all you'd need is adding the right signing certificate at end of the combined file for nginx and be quite good to go. I have even left ca_file on 3.0.11+ as is by default and have the order of 1. server cert, 2. intermediate cert, 3. root CA and that seems to work for me. Concerning the warning: Am I guessing correctly you are on Windows? Even If all of this worked especially on BYOD Windows 8.1/10 boxes I have realized that even if users follow Windows' regular wizards it still presents them a hash of the certificate which isn't really helpful. (It just says "here is a hash do you accept?" no CA no common name is shown) In order to not make that thing pop up I had to give them WiFi XML profiles that (still) strictly check the issuing CA and the common name - that is what made that popup go away for me.* -- Mathieu * Disclaimer: I do use the service 802.1x-config.org operated by fellow list contributor Stefan Winter who again is related to eduroam CAT development. CAT simplified both my (admin) life and generates also simple installers for Windows taking care for the user importing the XML config the right way (If not part of eduroam you can actually get the CAT code and install your own instance that is)
Dear Alan, On 04-04-16 12:05, A.L.M.Buxey@lboro.ac.uk wrote:
yes check_cert_cn , TLS-Client-Cert-CN , theres also the dynamic OSCP check you can do - but the best thing to do it use a privtae CA for a EAP-TLS system. as for the username - thats the 'outerid' as such - allowing proxying of the to-be-commenced authentication - protecting the real user id from the local RADIUS ssytem, allowing proxying etc without the EAP engine of the local server to be invoked. user@othersite.com - proxied off (as the client wont be able to talk to YOUR RADIUS server - think 'eduroam' :-) )
Thanks a lot. Also after reading http://serverfault.com/questions/410495/how-many-user-supplicant-certificate... I better understand what check_cert_cn = %{User-Name} does; please correct me if I'm wrong. It is in no way a check of Issuer of the certificate with the root CA. It is only a check if the username that was entered is the same as the CN of the client cert. So I guess it's nice to have learned this for now, but this doesn't help me in authentication for only (lets say) the client certs bob@example.com and alice@example.com. Now I better understand your hint of proxying. Thanks for helping a FreeRadius newbe! Wouter
Hi,
I better understand what check_cert_cn = %{User-Name} does; please correct me if I'm wrong.
It is in no way a check of Issuer of the certificate with the root CA. It is only a check if the username that was entered is the same as the CN of the client cert.
in the example mentioned, yes.
So I guess it's nice to have learned this for now, but this doesn't help me in authentication for only (lets say) the client certs bob@example.com and alice@example.com. Now I better understand your hint of proxying. Thanks for helping a FreeRadius newbe!
for other checks , unlang parsing with TLS-Client-Cert-CN can verify if the CN matches something that you've handed out - your realm, for example, shouldnt be present int he CN from commercial CAs as noone else owns it/has authority (unless something interesting is going on in your company.....) - likewise, OCSP can also be used to verify if the cert is valid/current (more advanced methods also involve cert CNs being registered and looked up in SQL or rejected!) alan
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Mathieu Simon (Lists) -
Stefan Winter -
Wouter