Tuesday 22 March 2016

FreeRADIUS - production SSL certificates

In the previous post, we covered the basic setup of FreeRADIUS.

In this post, we're going to focus on getting the SSL certificates right, and meet some of the common client snafus and their work-arounds (aka "hello Microsoft, please stop sucking at enterprise WiFi").

Production SSL certificates

Conveniently, FreeRADIUS makes this really quite easy by providing helpful configuration files and a makefile that will run all the OpenSSL commands for you - very quickly ending up in workable SSL certificates. There's even a well written README in there which is quite helpful.

Stop/exit your radius daemon.

Copy the /certs/ directory somewhere else (in case you want to revert).

Deploying Radius has a good walk-through of most of the process; I'm not going to reinvent the wheel: http://deployingradius.com/documents/configuration/certificates.html although I'd suggest you start by deleteing all the csr and key files, editing the .cnf files and then running make.

You should also take note of the following things as you edit the .cnf (ca.cnf and server.cnf; client.cnf is only needed if you're doing TLS) files:

  • change the default in/output passwords - and change the FreeRADIUS configurations to match (specifically, you're going to need to get the ones in server.cnf to match in RADIUS [in the tls section of the eap module] as those are what will be presented by the RADIUS server through the APs to your clients)
  • edit the CA information to match your school - Something like "YourSchoolName Wireless Certificate Authority" will work well
  • edit the validity period; the CA should probably be valid for 10 years (3650 default_days; the server.cnf validity probably only a year [put a reminder in your diary to re-do them for next year before they expire...]); a maximum of 5 years is recommended. 
  • Create a crl web address that is reachable and resolvable; future clients are likely to check and may freak out if these are not present.
  • the server common name (in server.cnf) should be a fqdn (even if it is somewhat fake) but it ought to be recognisably yours and may even resolve to something if you wish. I used ap.secure.wifi.mydomain.tld
Here is a reasonably non-sensitive config snippet to give you an idea of what you're going to want to change in ca.cnf:

Once you've done your new configurations, run the make command in the /certs/ directory; it will chug along for a while and create the details you need.

Once all the certificates are made, you will need to copy the root certificate public key .der and .pem files (ca.der and ca.pem) so you can give them to your clients. Copying them to your user home directory (possibly with a command like cp ca.der /home/<user>/yourschoolnamewifi-ca.der) and then using something like (Win)SCP to copy them elsewhere will work quite well. I simply put mine in a google drive folder with read only access from signed in members of my domain, together with brief how to connect documents for the major platforms.

Restart your radius daemon, possibly in debug mode; test that your clients can connect; with Windows clients, install the root certificate first.

If all your clients are connected to to your domain (unlikely in BYOD scenarios), you can use a group policy object to distribute the public key to all of your clients.


In an ideal world, you should now remove the root CA private key (ca.key) and config file (ca.cnf) and store them airgapped and offline somewhere. Possibly in a safe. Possibly in separate pieces. You will only need them when you create new server or client certificates, which is not usually a frequent thing. (if you forsee regularly signing client certificates, consider creating an intermediate CA that signs things - or a completely separate PKI - beyond the scope of this article).

Client Configuration


Android devices simply get on with things if you set them up to use TTLS and MSCHAPv2 and enter the user/pass pair into the relevant fields (leave anonymous identity blank); they seem to natively not care about trusted roots. You may want to force it to check the CA after you import the certificate - but that's an exercise for the reader.


In the IOS/OSX case, all you need to do is trust the CA warning dialog that comes up, and it Just Works; after you enter valid user/password pairs.  Again, you may want to import the root certificate to get the devices to trust your CA automatically.


Windows 7 pretty much just works after you correctly import the root CA (click on the network name, enter credentials, connect). Windows 8 and 10 require manual setup, which is a bit of a pain, but nothing a screenshotted "howto" won't solve. Assuming your users can actually read and follow instructions. If you don't do this, they seem to try authenticating as the machine account (which is generally nonsense in a BYOD context).

If you've already installed the root certificate for your CA (otherwise, skip down):

  • Open Network and Sharing Center (right click on the wifi icon by the clock)
  • Click on Set up a new connection or network
  • Click on Manually connect to a wireless network
  • Carefully enter: 
    • the exact SSID (case sensitive)
    • Select WPA2-Enterprise as the security type
    • Tick Start this connection automatically
    • Next
  • Click on Change connection settings
  • Click on the Security tab; make sure Remember my credentials is unticked (optional)
  • Make sure the network authentication method is PEAP
  • Click on Settings
  • Make sure Verify the Server's identify by validating the certificate is ticked. 
    • Optionally, enter the full certificate name (which should be in FQDN format) into the Connect to these servers box. 
  • Make sure your root certificate is ticked.
  • Don't ask user to authorise new servers or trusted CAs
  • Make sure Authentication Method is EAP-MSCHAPv2. 
  • Click on Configure and untick Automatically use my Windows login
  • OK
  • OK
  • Click on Advanced Settings in the Security tab of the Wireless Network Properties window
  • Tick Specify authentication mode and select User authentication
  • OK
  • OK
  • Enter user credentials if the pop-up shows, or when they are requested after you click on the relevant SSID. 
Below, you'll find screenshots so you can compare your settings against ours (which work). 

Importing root CA certificates - Windows

You should already have copied the root CA public key files off the FreeRADIUS server and stashed them somewhere - some kind of removable storage or a networked location make sense. They're reasonably public knowledge, so you could even email them or stick them on your intranet. 

To import it into Windows: 
  • double-click on the .der format certificate (it should have a certificate file icon)
  • Click Install Certificate...
  • Next
  • Select the Place all certificates in the following store radio button and click on Browse...
  • Select the Trusted Root Certificate Authorities store
  • Click OK
  • Next
  • Finish
  • Accept any warning dialogs - get users to verify the SHA1 thumbprint if you want them to be security conscious. A poster on your helpdesk wall may be useful. 
  • You may sometimes need to reboot to have this take effect. 
Again, here's a bunch of screenshots: 

Well done, you now have production SSL certificates in use.

No comments:

Post a Comment