WPA Certificate Question
I was able to get freeradius 2.1.3 and wireless WPA working, likely due to the fact that FreeRadius was mostly configured for me (thanks ;) ). I’m a little confused about the certificate that is required in the process, and what the relationship is with the client, the Wireless Controller and the FreeRadius server. The README file states: “ In general, you should use self-signed certificates for 802.1x (EAP) authentication.” Why self signed versus CA signed? Ideally I would like my clients to not be questioned about the certificate at all. Is that even possible with WPA? If I purchase a CA signed cert, would that eliminate the requirement on the client to acknowledge the certificate or import it? -Mike
On 31/01/2010, at 11:59 AM, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
I was able to get freeradius 2.1.3 and wireless WPA working, likely due to the fact that FreeRadius was mostly configured for me (thanks ;) ). I’m a little confused about the certificate that is re quired in the process, and what the relationship is with the client, the Wireless Controller and the FreeRadius server. The README file states:
“ In general, you should use self-signed certificates for 802.1x (EA P) authentication.”
Why self signed versus CA signed? Ideally I would like my clients to not be questioned about the certificate at all. Is that even possible with WPA? If I purchase a CA signed cert, would that eliminate the requirement on the client to acknowledge the certificate or import it?
It would also mean that anyone could go to the same CA, get a client certificate and would be able to login to your wireless network. Not really ideal IMHO ;) Hence why controlling your own CA, and managing the CRL or OCSP is the only way to go if you want to properly maintain control over your wireless or 802.1x wired network. Minting certificates is pretty trvial depending on the CA software you are using and importing a CA into every workstation is also easy using the numerous tools available. My preference is to use the "rootsupd" package and extract that out and update the p7b with your own ca. Then get everyone to run that, or use software distribution to get it out enterprise wide.
-Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 30, 2010, at 6:39 PM, Peter Lambrechtsen wrote:
On 31/01/2010, at 11:59 AM, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
I was able to get freeradius 2.1.3 and wireless WPA working, likely due to the fact that FreeRadius was mostly configured for me (thanks ;) ). I’m a little confused about the certificate that is required in the process, and what the relationship is with the client, the Wireless Controller and the FreeRadius server. The README file states:
“ In general, you should use self-signed certificates for 802.1x (EAP) authentication.”
Why self signed versus CA signed? Ideally I would like my clients to not be questioned about the certificate at all. Is that even possible with WPA? If I purchase a CA signed cert, would that eliminate the requirement on the client to acknowledge the certificate or import it?
It would also mean that anyone could go to the same CA, get a client certificate and would be able to login to your wireless network. Not really ideal IMHO ;)
Hence why controlling your own CA, and managing the CRL or OCSP is the only way to go if you want to properly maintain control over your wireless or 802.1x wired network.
Minting certificates is pretty trvial depending on the CA software you are using and importing a CA into every workstation is also easy using the numerous tools available.
My preference is to use the "rootsupd" package and extract that out and update the p7b with your own ca. Then get everyone to run that, or use software distribution to get it out enterprise wide.
Except that asking users to use one certificate is hard enough. Expecting them to use one for WPA, one for email, etc just makes things worse. It'd be nice to filter acceptable certificates by, say, regexp on the rfc822Name. Accept certificate if: It is signed by our chosen CA and the rfc822Name =~ /.*@ourdomain.com$/ StartCOM Class 2 puts the "organizer's" full name in the CN attribute. That's already built into the eap filtering capabilities, if I understand things correctly.
On Sun, 31 Jan 2010, Peter Lambrechtsen wrote:
On 31/01/2010, at 11:59 AM, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
I was able to get freeradius 2.1.3 and wireless WPA working, likely due to the fact that FreeRadius was mostly configured for me (thanks ;) ). I’m a little confused about the certificate that is re quired in the process, and what the relationship is with the client, the Wireless Controller and the FreeRadius server. The README file states:
“ In general, you should use self-signed certificates for 802.1x (EA P) authentication.”
Why self signed versus CA signed? Ideally I would like my clients to not be questioned about the certificate at all. Is that even possible with WPA? If I purchase a CA signed cert, would that eliminate the requirement on the client to acknowledge the certificate or import it?
It would also mean that anyone could go to the same CA, get a client certificate and would be able to login to your wireless network. Not really ideal IMHO ;)
Hence why controlling your own CA, and managing the CRL or OCSP is the only way to go if you want to properly maintain control over your wireless or 802.1x wired network.
Minting certificates is pretty trvial depending on the CA software you are using and importing a CA into every workstation is also easy using the numerous tools available.
My preference is to use the "rootsupd" package and extract that out and update the p7b with your own ca. Then get everyone to run that, or use software distribution to get it out enterprise wide.
But I don't plan on distributing client certificates for authentication. I intend for them to login with a username and password checked against my Radius server, so I'm not sure what role the certificate plays in that process? -Mike
On Sun, Jan 31, 2010 at 12:09 PM, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
Why self signed versus CA signed? Ideally I would like my clients to not be questioned about the certificate at all. Is that even possible with WPA? If I purchase a CA signed cert, would that eliminate the requirement on the client to acknowledge the certificate or import it?
It would also mean that anyone could go to the same CA, get a client certificate and would be able to login to your wireless network. Not really ideal IMHO ;)
But I don't plan on distributing client certificates for authentication. I intend for them to login with a username and password checked against my Radius server, so I'm not sure what role the certificate plays in that process?
I think the recommendation made perfect sense when you require client certificate, like when deploying EAP/TLS. If you intend to use EAP as a secure tunnel only, and login with user/password (like with PEAPv1/EAP-GTC), using a CA-signed cert might make more sense. -- Fajar
On Sun, 31 Jan 2010, Fajar A. Nugraha wrote:
On Sun, Jan 31, 2010 at 12:09 PM, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
Why self signed versus CA signed? Ideally I would like my clients to not be questioned about the certificate at all. Is that even possible with WPA? If I purchase a CA signed cert, would that eliminate the requirement on the client to acknowledge the certificate or import it?
It would also mean that anyone could go to the same CA, get a client certificate and would be able to login to your wireless network. Not really ideal IMHO ;)
But I don't plan on distributing client certificates for authentication. I intend for them to login with a username and password checked against my Radius server, so I'm not sure what role the certificate plays in that process?
I think the recommendation made perfect sense when you require client certificate, like when deploying EAP/TLS. If you intend to use EAP as a secure tunnel only, and login with user/password (like with PEAPv1/EAP-GTC), using a CA-signed cert might make more sense.
In the Windows WPA setup screen, Protected EAP Properties, there are options to "Validate server certificate", and "Connect to these servers". Do I specify my two Radius servers there? My clients don't have direct access to my Radius servers, so what actually happens when I enter them here? Does it just compare the FQDN to the one on the certificate that is presented during the login? -Mike
Hi,
In the Windows WPA setup screen, Protected EAP Properties, there are options to "Validate server certificate", and "Connect to these servers". Do I specify my two Radius servers there? My clients don't have direct access to my Radius servers, so what actually happens when I enter them here? Does it just compare the FQDN to the one on the certificate that is presented during the login?
your 2 radius servers can have the same cert, there is no issue there (eg radius.my.org) - dont forget, this is all pre-network stuff so no DNS is involved. and yes, the value entered in that part is a string match to the name in the certificate sent via the RADIUS server. some supplicants easily let you enter more than one RADIUS server name, use multiple certs etc.... alan
On Sun, 31 Jan 2010, Alan Buxey wrote:
Hi,
In the Windows WPA setup screen, Protected EAP Properties, there are options to "Validate server certificate", and "Connect to these servers". Do I specify my two Radius servers there? My clients don't have direct access to my Radius servers, so what actually happens when I enter them here? Does it just compare the FQDN to the one on the certificate that is presented during the login?
your 2 radius servers can have the same cert, there is no issue there (eg radius.my.org) - dont forget, this is all pre-network stuff so no DNS is involved.
and yes, the value entered in that part is a string match to the name in the certificate sent via the RADIUS server.
some supplicants easily let you enter more than one RADIUS server name, use multiple certs etc....
Ok, so I could just establish a certificate for a single host name, apply that same certificate to all my FreeRadius servers, and in that "Connect to these servers" client field, just enter the 'common name' entered on the certificate? I wonder if a wildcard cert would work for this. As in *.myorg.ca, then entering *.myorg.ca for client servers field. Just asking because I have one of those. In the README file there is this warning: "You will have to ensure that the certificate contains the XP extensions needed by Microsoft clients." But I can't find any further information about it. How do I ensure my certificate has these extensions? Would a CA signed cert have this? -Mike
Hi,
to these servers" client field, just enter the 'common name' entered on the certificate? I wonder if a wildcard cert would work for this. As in *.myorg.ca, then entering *.myorg.ca for client servers field. Just asking because I have one of those.
depends on supplicant - some understand wildcards...some just need the domain name to be specified
In the README file there is this warning:
"You will have to ensure that the certificate contains the XP extensions needed by Microsoft clients."
But I can't find any further information about it. How do I ensure my certificate has these extensions? Would a CA signed cert have this?
check the FreeRADIUS certificate makefile - you can see the xpextensions file and the required attributes. you can use the openssl tool to view the certificate in text mode - whethr the CA will sign it - you may have to request this functionality alan
On Sun, 31 Jan 2010, Alan Buxey wrote:
Hi,
to these servers" client field, just enter the 'common name' entered on the certificate? I wonder if a wildcard cert would work for this. As in *.myorg.ca, then entering *.myorg.ca for client servers field. Just asking because I have one of those.
depends on supplicant - some understand wildcards...some just need the domain name to be specified
In the README file there is this warning:
"You will have to ensure that the certificate contains the XP extensions needed by Microsoft clients."
But I can't find any further information about it. How do I ensure my certificate has these extensions? Would a CA signed cert have this?
check the FreeRADIUS certificate makefile - you can see the xpextensions file and the required attributes. you can use the openssl tool to view the certificate in text mode - whethr the CA will sign it - you may have to request this functionality
I generated a server certificate using the provided documentation in the certs/README file. I took the generated server.csr and got it signed by Thawte (just a 20 day trial cert for now). They provided my certificate and I replaced the contents of server.crt with it. Now when I start up FreeRadius in debug, I get: rlm_eap: SSL error error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch rlm_eap_tls: Error reading private key file /usr/local/freeradius/etc/raddb/certs/server.key rlm_eap: Failed to initialize type tls /usr/local/freeradius/etc/raddb/eap.conf[17]: Instantiation failed for module "eap" /usr/local/freeradius/etc/raddb/sites-enabled/inner-tunnel[223]: Failed to find module "eap". /usr/local/freeradius/etc/raddb/sites-enabled/inner-tunnel[176]: Errors parsing authenticate section. } I did update the private key password in eap.conf, to match the one I used in the original signing request. So what did I do wrong? -Mike
On Tue, 2 Feb 2010, Alan Buxey wrote:
Hi,
I did update the private key password in eap.conf, to match the one I used in the original signing request. So what did I do wrong?
did you also update/put the right .key file into place?
It would be the same server.key file that was generated with the make scripts, no? -Mike
I think you should install the openssl-delvel package for tls header and lib, if you can not run radiuxd -X also before replacing the the certs.and then build freeradius again. On Sun, 31 Jan 2010, Alan Buxey wrote:
Hi,
to these servers" client field, just enter the 'common name' entered on the certificate? I wonder if a wildcard cert would work for this. As in *.myorg.ca, then entering *.myorg.ca for client servers field. Just asking because I have one of those.
depends on supplicant - some understand wildcards...some just need the domain name to be specified
In the README file there is this warning:
"You will have to ensure that the certificate contains the XP extensions needed by Microsoft clients."
But I can't find any further information about it. How do I ensure my certificate has these extensions? Would a CA signed cert have this?
check the FreeRADIUS certificate makefile - you can see the xpextensions file and the required attributes. you can use the openssl tool to view the certificate in text mode - whethr the CA will sign it - you may have to request this functionality
I generated a server certificate using the provided documentation in the certs/README file. I took the generated server.csr and got it signed by Thawte (just a 20 day trial cert for now). They provided my certificate and I replaced the contents of server.crt with it. Now when I start up FreeRadius in debug, I get: rlm_eap: SSL error error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch rlm_eap_tls: Error reading private key file /usr/local/freeradius/etc/raddb/certs/server.key rlm_eap: Failed to initialize type tls /usr/local/freeradius/etc/raddb/eap.conf[17]: Instantiation failed for module "eap" /usr/local/freeradius/etc/raddb/sites-enabled/inner-tunnel[223]: Failed to find module "eap". /usr/local/freeradius/etc/raddb/sites-enabled/inner-tunnel[176]: Errors parsing authenticate section. } I did update the private key password in eap.conf, to match the one I used in the original signing request. So what did I do wrong? -Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
But I don't plan on distributing client certificates for authentication. I intend for them to login with a username and password checked against my Radius server, so I'm not sure what role the certificate plays in that process?
the certificate is for the RADIUS server - this will let your clients know that they really are establishing a RADIUS authentication for a server they can verify. ie myCA signs the RADIUS server, the client then has the myCA cert installed and is configured to check the RADIUS server eg radius.my.org and validate that against the server. in this case, you will need the myCA CA cert installed on the client. why do this? so that you can verify and validate the RADIUS server - if you dont, then a man-in-the-middle attack could be accomplished and then you'll be sending usernames and passwords to that 3rd party server. very nice for Mr Cracker. why use your own CA? well, in the case of EAP-TLS, this gives extra security... but even in the case of EAP-TTLS or EAP-PEAP - if the RADIUS server is signed by eg Verisign, then ANYONE can get a verisign certificate with some cash.... eg radius.fake.org and then they can attempt a man-in-middle.... okay, if the client is secured properly, then it wont talk to radius.fake.org because its been asked to validate the RADIUS server....but if it hasnt been configured properly, then the client will happily talk to radius.fae.org - because it has the Verisign CA installed and will validate that all is okay. how often is this a worry? I'm afraid, after looking at man sites 'how to configure your client' , the 'validate cert' stage is often overlooked, ignored...or even worse...people are told NOT TO (probably because the site havent got their RADIUS configured correctly, cant handle the SSL stuff properly or have chosen the self-sign CA and havent got around to ways of deploying that client :-( ) alan
On Mon, Feb 1, 2010 at 12:43 AM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
why use your own CA? well, in the case of EAP-TLS, this gives extra security... but even in the case of EAP-TTLS or EAP-PEAP - if the RADIUS server is signed by eg Verisign, then ANYONE can get a verisign certificate with some cash.... eg
radius.fake.org
and then they can attempt a man-in-middle.... okay, if the client is secured properly, then it wont talk to radius.fake.org because its been asked to validate the RADIUS server....but if it hasnt been configured properly, then the client will happily talk to radius.fae.org - because it has the Verisign CA installed and will validate that all is okay.
Won't the client see the name first, i.e. radius.fake.org in your example, and they (should) see something wrong?
how often is this a worry? I'm afraid, after looking at man sites 'how to configure your client' , the 'validate cert' stage is often overlooked, ignored...or even worse...people are told NOT TO (probably because the site havent got their RADIUS configured correctly, cant handle the SSL stuff properly or have chosen the self-sign CA and havent got around to ways of deploying that client :-( )
Yep, many admins do that :( -- Fajar
participants (6)
-
Alan Buxey -
Chris -
Fajar A. Nugraha -
hongjianli.nudt＠gmail.com -
Mike Diggins -
Peter Lambrechtsen