Charles Plater wrote:

Many moons ago, i set up a FreeRadius server as part of our 802.1x / WPA project. At that time, I asked this list about using a commercially signed SSL certificate as opposed to a self signed certificate. I’m not sure I understood all of the reasons, but I was advised by another member of this list to use a self signed certificate. Fast forward 6 years to today, and our management is convinced that problems we are seeing w/ clients having problems connecting are related to the self signed SSL certificate.

It would help to describe *what* problems you're seeing.

Could someone please describe to me the reasoning behind using a self signed certificate with on with FreeRadius? What kinds of problems / vulnerabilities will we be exposed to if we use a commercially signed (DigiCert) SSL certificate?

Let's start off by talking about HTTPS. When your browser connects to an HTTPS web site, it has (largely) three pieces of information. (1) the domain name it's connecting to. (2) the certificate of the site in question. And (3) the rest of the certificates to the CA root. (1) is where you want to go. But you don't know if the place you ended up is "really" the web site in question. (2) is a certificate which contains the domain name from (1). This lets you know you're connected to a site which is claiming to be (1). (3) lets you know that everyone ELSE agrees that the site in (1) and the certificate in (2) really are the same thing. In WiFi, there is domain name, because you don't have network access yet. You have an SSID. But the certificate being presented isn't checked against the SSID. This is because you may be roaming, which means that multiple SSIDs may end up at the same server + certificate. If you use a "well known" cert from a CA root, all you know is that the CA handed out the cert to... someone. You can't check it against the SSID as with (1) above. You can't check that the certificate has the "domain" information as with (2) above. So the certificate gives *no* information about the identity of the server. It might *look* like it's giving you information about the server. But you can't trust the certificate, because you can't verify it against anything else. And because the certificate is signed by a "well known" CA, then *anyone* on the planet can claim to be a server, and you have no idea who they really are. Using a self-signed certificate is more problematic to set up for the end-users. They have to get the CA cert, etc. onto their machines. But it's MUCH more secure. When the end user connects to a system present a certificate signed by that CA, you're sure that YOU are the only person the planet capable of creating such a certificate. Which means the end user is sure that they're connecting to YOUR site, and not to some random strangers site. Alan DeKok.

hi, this question pops up every so often look at the mailing list history for previous discussions but summary is 1) its BCP for 802.1X to use a prvate CA - its more secure in that you control the CA and thus you control who gets certificates...so if a client can ONLY check the CA and not the CommonName, thats not an issue..) 2) if using private CA your RADIUS server can be directly signed - no intermediates - less data during 802.1X exchange 3) you are in control of destiny - YOU decide what your CA policy and server certificate policies are. want 5 years? fine. want 10 years (not advisable) fine. ..and more. however, using a private CA has its difficulties 1) clients need to have the CA on their device - use a profile tool! 2) you are operating a PKI/CA system - you need to know what you are doing, have policies, keep it secure , etc 3) you need to know what random things you need to add into the certs (fortunately plenty of other people are doing that work in the world of 802.1X and contributing to FreeRADIUS so eg the current example/demo certificate scripts make things that work your problem is PROBABLY that your CA/cert is MD5 - newer OSes wont like that. you need to be SHA1 or higher now. Windows Phone/Windows 8 need CRLDP to be present. at the end of the day, when it comes to the actual x509 data, there is NO difference between a private CA signd cert and a public CA signed cert for 802.1X alan