WPA Radius and Windows

The universe conspired to coerce me into getting WPA radius working for Windows. My wife started taking a Microsoft SharePoint class at the local community college and started bringing her laptop home from work so she could work on the homework. I have a bunch of wired RJ-45 ports around the house but none of them are where it's really convenient for her to work on her stuff. That meant getting WPA radius working for her Windows XP laptop. It also turned out that my certificates were expiring from my original exercise in setting up freeradius, WPA radius and getting them working with ndiswrapper on my laptop.

Regenerating the certificate for my laptop running CentOS Linux was easy. It also turned out to be futile and therein lies the tale.

I revisited the applicable Paranoid Penguin articles (Part 2 and Part 3) and carried out the steps described for setting up a certificate for a Windows box. This apparently only entailed making sure that the xpextensions file had the right contents and running openssl one more time for each Windows client to produce the Windows certificate:

openssl pkcs12 -export -in client_cert.pem \ -inkey client_key.pem -out client_cert.p12 -clcerts

I copied the certificates (cacert.pem and client_cert.pem) to my Windows laptop and imported them using the Microsoft Management Console (mmc) as described in Part 3 of the Paranoid Penguin articles. I then attempted to connect to my server only to get a variety of "access denied" responses. Unfortunately, neither the Windows error message nor the radiusd log messages were very enlightening as to what the problem was.

I finally ran across an article that suggested verifying that the certificates I was providing were valid. I had not considered this possibility since I had just generated the certificates. Sure enough, the client certificate indicated that the originating server in the certification path was not valid.

This sent me off on another set of searches. I finally found a Ubuntu bug report that precisely described the condition I had encountered. Windows was complaining that:

"This Certificate is not valid because one of the certification authorities in the certification path does not appear to be allowed to issue certificates or this certificate cannot be used as an end-entity certificate."

Unfortunately, the solution suggested in the bug report meant making a change to openssl.cnf and then regenerating every certificate starting with cacert.pem. Note that an alternative solution is also provided in a comment attached to the bug report. I only implemented the solution suggested in the bug report and did not investigate whether the proposed alternative would also work.

Cutting to the chase, the bug's author suggested making the following change in opensll.cnf:

Change this:

x509_extensions = usr_crt

To this:

x509_extensions = v3_ca

Also, the original line in my CentOS 5.2 installation was:

x509_extensions = usr_cert

Your mileage may vary.

I regenerated the server certification and all of my client certifications and then installed the "new" certificates on my laptop. The next trick was getting right passwords since you create a number of them in the process of generating the various openssl certificates. It turns out that the wpa_supplicant under Linux wants the PEM password used when creating the certificate while Windows wants the challenge password created when signing the certificate. S-I-G-H

Both Windows XP and CentOS 5.2 Linux now connect to my WAP using WPA radius.

Cheers,
Dave