There are many options for wireless authentication. Most of us have a home router and use some form of passphrase based authentication for our home networks. Most likely you’re using WPA/WPA2 personal. It is perfectly suitable for a small home network but is not at all best security best practice when moving to an enterprise environment. That’s where EAP, also known as WPA/WPA2 enterprise or 802.1x/EAP, is widely deployed. I’ve spent some time configuring several flavors of EAP and was surprised at the variety that is available for this model of security. Configuring EAP can be as simple as clicking a box and as difficult as, well, EAP-TLS.
I had planned on writing this as one article but setting up the PKI required a lot more explanation and configuration than I anticipated. Therefore this is part one of a series of posts outlining EAP-TLS and its configuration. It’s definitely one of the most elaborate setups I’ve ever done but I had a lot of fun and learned really interesting things.
WPA2 enterprise has three main parts: the supplicant, the authenticator and the authentication server. The supplicant is usually the user trying to gain access to the network. The authenticator is the wireless access point (WAP) or wireless controller (WLC) and the authentication server is usually a RADIUS server. I used a Cisco 2504 WLC and a 3702I WAP for this setup. For the authentication server, I used two VMs running Windows server 2016 and 2019. I also installed Window’s implementation of RADIUS called the Network Policy Server (NPS) on the server acting as the subordinate Certificate Authority. I explain what that is below.
The private PKI:
The biggest reason why EAP-TLS is so complicated to configure is this. Because client devices and the authentication server authenticate each other through certificates, you have to use a Public Key Infrastructure (PKI.) What exactly is a PKI? At a high level, it is a series of servers that are responsible for creating and issuing certificates. Whenever you visit a secure website using HTTPS, the web server hands your browser a certificate that has a few pieces of crucial information in it. Firstly, there is a name on the certificate that matches the name of the website you’re visiting. Secondly, there is the server’s public key which your computer will use to encrypt all information you want to exchange with the web server. Thirdly, there is a digital cryptographic signature from an issuing Certificate Authority. This signature is basically what guarantees that the server is the server hosting the website that you’re trying to reach. Your computer will verify that the signature is valid by checking the issuing Certificate Authority’s identity. The issuing Certificate Authority itself will have a certificate that itself has a digital signature. Your computer checks that digital signature and will keep following this chain of certificates until it reaches a certificate that was self signed. This is the root certificate. If a copy of the root certificate is found in a special folder on your computer then it is a trusted certificate and that means, ultimately, that the web server’s certificate checks out. You can now exchange your public key with the web server and all communication between you and the server will be encrypted and secure.
The certificates that are issued to web servers are issued through public PKIs. If you’ve heard of Verisign or Thwate or GoDaddy then you’ve heard of public PKIs. The entire point is to establish a chain of trust, starting with the root certificate. If a server presents you with a certificate that can be traced back to a trusted root certificate then you trust it and the connection is securely established. This is the idea behind EAP-TLS. If the supplicant and authentication server both present certificates that they both can trace back to a root certificate that they both trust then they can both be sure that the other end is who they say they are.
Let’s get down to the specifics. The certificate that you’ll see most often is something called an X.509 certificate. The current version is version 3 so you might also see it as an X.509v3 certificate. It has several extensions which provide information about the function of the certificate. For example, a certificate can be used for server authentication, client authentication, encryption, issuing certificates and many other things. When a server or device or user wants a certificate they must do two things: generate a private encryption key if they don’t already have one and create a certificate signing request. The encryption key is used to generate the certificate signing request which has information about the device/user, usually a common name or FQDN and the purpose of the certificate, along with the public/private key pair. This request is submitted to an issuing Certificate Authority server that then issues a certificate using information in the signing request and then, crucially, signs the certificate with its private key. This signature can be checked if you have a copy of the Certificate Authority’s public key.
That’s the basic process of getting a certificate. A natural question to ask is, what about the original certificate? The original or root certificate is special because it signs itself. It then creates a Certificate Revocation List (CRL, pronounced krill) and an Authority Information Access (AIA) entry and stores these two things in a place on the network where all devices have read access. The AIA is just a copy of the root certificate itself. There is a special folder in any device where trusted root certificates are stored and all devices that want to participate in the PKI needs access to a copy of the root certificate in order to copy it and place it in this folder. Certificates all have a lifetime and after that, they expire and are no longer valid. There are times, however, when a certificate should be revoked before that expiration date. A simple scenario is when a user leaves a company. The user certificate should be revoked at that point to remove the network privileges for that user. That user certificate will then be added to the CRL and every device afterwards can, after checking the CRL, reject that certificate if it is presented in the future. The user will no longer have a valid certificate that they can use to access the company’s resources.
So how do you set up a private PKI? You have to first create the root certificate. This process has a few steps depending on what type of server OS you’re using. You must generate a private key for the server and use that to generate the root certificate. I did it on Windows server 2016/2019 which involved 1) installing Certificate Services as a role, 2) using the installation wizard to install the Certificate Services and generate the private key and 3) Issuing the server a self signed certificate. On Windows server specifically, you have two options when defining what type of certificate server you want. One is a standalone server and the other is a domain joined server. When creating a root Certificate Authority, best practice is to NOT join it to any domain. You create the root CA, configure the paths to the CRL and AIA and then issue certificates to other, subordinate certificate servers. After the subordinate servers receive their certificates, you shut down the root CA. It has fulfilled its function, the root certificate is accessible somewhere else on the network and the only time the root CA needs to be brought back online is when the root certificate needs to be renewed.
This post is more focused on setting up the certificate chain for the PKI and not necessarily installing the service onto Windows server. Here are a few links to Microsoft’s official documentation on how to install the Certificate Services along with configuring the CRL distribution points and AIA.
Depending on how elaborate you want to be, the subordinate CA can be policy CAs which themselves issue certificates to subordinate CAs. Or the subordinate CAs can be issuing CAs that handle certificate signing requests and issue certificates to devices and users on the network.
After the issuing CA has received a certificate from the root CA (or from a policy CA if the PKI has more than two tiers), the PKI’s core has been established. The next step is to issue certificates to devices on the network. As mentioned before, there are many extensions for a X.509 certificate but the two that you’ll need are certificates with server authentication and client authentication. In Windows, a user/device has to be given rights to enroll for a specific certificate before actually being able to request the certificate. On the issuing CA, here are the steps for adding a specific certificate to the list of certificates that the server will issue:
- Open the Certificate Authority console from the services tab in Server Manager
- Go to Certificate Template
- Right click and choose Manage
- Choose the certificate that you would like to issue and right click it, then choose duplicate the template. The certificate for a RADIUS server will be the RAS and IAS certificate.
- A wizard will open that allows you to customize details of the certificate. You will need to go to the security tab and add the RADIUS server that you want to get the certificate to the list. Note that on Windows Server, the RADIUS service is called NPS (Network Policy Server.)
- Click on the RADIUS server that you just added and click the box for enroll.
- Click OK and then close the management window.
- Back in the Certificate Authority window, right click the Certificate Template folder and choose add a new certificate to issue.
- Under the list of certificates, add the certificate that you just created.
Now that the RADIUS server has permission to enroll in the certificate, the next step is for it to create a certificate signing request (CSR) and submit it to the issuing CA. For Windows server, this is all done as part of a wizard. On the RADIUS server, here are the steps to generate the CSR.
- Go to the search bar on the taskbar and type mmc. This is the Microsoft Management Console. (If mmc doesn’t show up you can also type run and then type mmc into the run window.)
- Click on the mmc icon that shows up in the results.
- On the top left, click on file and then choose Add or remove snap-ins.
- In the left most panel, there will be a list of items. Choose certificates and click on the Add button in the middle.
- There will be a pop-up offering three choices. Choose the radio for computer account and click Next.
- On the next screen, choose the radio for local computer and click Next.
- You’ll be taken back to the original window. Certificates should be added on the right. Click OK.
- Certificates should be added to the mmc. Click the arrow on the left to expand it.
- Under the list of folders, expand the Personal Folder.
- Choose the Certificates folder.
- On the middle panel, there should be a few certificates listed. Right click anywhere in the middle panel and hover over All Tasks.
- Choose Request New Certificate.
- A wizard will pop up. Click Next.
- Choose next when asked to choose the Enrollment Policy. The enrollment policy should have been defined by a domain administrator.
- Under the list of certificates, the RADIUS certificate created earlier should be listed. Click on it and choose Finish.
- The certificate should be added to the panel. Right click on it and choose enroll.
At this point, the CSR has been submitted to the issuing CA and once the green bar completes, the requesting server has been issued a certificate. You’ll see the certificate show up in the personal certificate folder for the server.
Next is to issue a certificate request for the user. The certificate is included in the standard installation when you install the Certificate Services on Windows server so there is no need to add it to the certificate templates folder to issue the User certificate. Sign on as the user who you want to request the certificate for and follow the steps above. The two differences are:
- Choose local user account when adding the certificate snap-in to the mmc.
- Choose the User certificate when enrolling for the certificate.
You then need to export the certificate to the mobile device that you want to use to authenticate onto the EAP-TLS SSID. I used my macbook. Here are the steps for exporting the certificate and installing it onto a macbook.
- In the mmc console, right click on the certificate, go to All Tasks and choose export.
- A wizard will pop up. When asked if you want to export the private key, choose yes.
- Click on the password box on the next screen and enter a password. You’ll need to enter this password when installing the certificate on the macbook later.
- Define the path to the USB drive that you’ll be using to plug into the macbook. Of course you can also choose a network share on your local network if the macbook has access to the share.
- On the macbook, open your file explorer and in the search bar search for keychain access.
- On the left side panel, click on System.
- Move the certificate from the USB drive into the keychain access window.
- You’ll be prompted for your macbook password to perform this move.
- You’ll then be prompted for the certificate password that you entered when you exported the certificate.
With that, the certification process is finished! There’s still the RADIUS server configuration along with the SSID configuration before EAP-TLS is implemented but the PKI part of the implementation is done.
There are several things that I want to note about the way I configured the PKI. Particularly, the way that I issued and then exported and installed the User certificate is not best practice and neither is it scalable. In a production environment, if the end devices are all joined to the Active Directory domain then you’ll provision the certificates through GPOs instead. If you haven’t studied AD, GPOs are the way to provision policy within a domain and through them you can automatically install your private root certificate in the trusted certificate folder of all your domain joined devices at once. There’s also the possibility of giving a user, computer or group auto-enroll rights to a certificate. This means that when they sign on to the domain, they will automatically be issued the certificate! I’m not going to argue that creating and maintaining a PKI is easy but GPOs certainly ease some of the administrative load.
I should also note that this is just the surface of certificates and PKIs. If you scroll through the certificate templates you’ll see dozens of different pre-defined certificates that each are issued for a particular reason. A lot of those are Windows specific but they still serve as good examples of what can be accomplished with a PKI. I had so much fun learning these ideas that I’m researching how to configure this process on linux systems. I’ll just say that there’s a lot more CLI work and editing configuration text files. Believe it or not, Windows actually abstracts a lot of the gritty details for you.
Here are a series of pictures documenting the configuration process. I had already configured everything before writing this post so these are screens of me going through the process again.
Configuring a CA to issue a RADIUS certificate:
Now for the client certificate. Only a few steps differ so I’ll only show the differences. Make sure you’re signed in as the user to whom you want to issue the certificate.
That’s it! You actually don’t have to add enrollment rights for users to request this certificate. As long as the user is an authenticated user on the domain, they’ll have enrollment rights by default.
Exporting and Installing User Certificate to a Macbook:
As you can see, I experimented with a lot of different certificates before this write up. Above, the root CA and issuing CA certificates are both installed on the system along with the user certificate. This is actually one of the options that are available when you export the certificate.