Configure Certificate-Based (EAP-TLS ) Authentication

Let's start it with Mist Access Assurance and we'll start by looking at various 802.1x authentication use cases. There's both wireless and wired but the first very simple use case we'll look at the wireless certificate-based or EAP-TLS authentication. What do we need to get this up and running? So objective is allow you know our clients to authenticate to the network and allow them on the network if they're presenting trusted digital certificates.

Prerequisites we need client certificates installed on client devices. We have a separate video how you can create your own certificate authority and sign client certificates if you don't have any PKI and you just want to do your lab testing for example. That's a there is a good video covering that.

In production environment in production deployments the client certificates are typically distributed automatically by MDM solutions or mobile device management or group policies if you're in the Windows environment or any other onboarding solutions. But we are assuming that in for our exercise client certificates are already in there. Before we go into configuration I just want to review the authentication flow.

What's actually going to happen when client is trying to access the network? So we have a wireless client, we have a Mist AP, we have access assurance service that's configured. So client will try to associate to the AP which advertises 802.1x enabled SSID. The client the AP will ask about the IP identity.

In other words, what's your what's your username? Client will send the IP identity response. At this point, the Mist Access Assurance will present its server certificate that's to provide the mutual authentication.

So client will need to trust the Mist access assurance certificate to say okay I'm actually trusting this service to pass authentication credentials. Then after the client validates the service certificate and client can either truly validate the certificate or it can bypass that service certificate validation that there is a setting that you can configure. Not a great practice, actually, a horrible practice from a security point of view, but for testing in lab purposes, would be a good option.

Now after the client validated the server certificate in a TLS scenario, client is presenting its own client certificate, or in other words, called client hello and sends it over through the AP to the Mist access assurance service. At this point, access assurance will look at the client certificate and validate it against the trusted certificate authority list that that it has configured. In other words it will look at okay so which certificate authorities do I trust in my configuration? Is any of those trusted CA's signed the client certificate? And if yes, great the certificate is validated right, and at this point, we can look through authentication policy rules and make sure that we are matching a configured authentication policy rule and at this point we declare success.

If configured, we can also send a VLAN. We can send a role to the AP so it can assign the client into the right network and at this point we're good to go. Now let's look at the actual setup procedure - what do we need to configure this? So right now, we have an organization, the test organization. We'll be using for this tutorial that has one test AP connected, one switch connected with virtually no config on it whatsoever.

So we will start by configuring the access assurance for our use case to authenticate clients using EAP-TLS only validating certificates all we need to do is to go to Organization > access certificates. We'll need to import our certificate authority. If you have your own PKI infrastructure then you would import your root certificate authority typically also your intermediate CA so it's going to be a couple of certs that you will need to to import only the public certificate you would need to import obviously not the private keys. So we just we are just telling access assurance which certificates to trust based on this trust chain.

In our case, we're using our lab certificates that we've created in in another video so I'm going to open up this lab Mist CA that we've created in a different video I'm going to copy the certificate contents paste it in here so it will now decode my CA common name it will see okay it's valid until this at this date it's actually a CA cert because it's self-issued we can hit save. So now we've imported the certificate authority at this point we are trusting any client certificates have been issued by the CA right very very simple and remember in in the in this step where the client is validating the server certificate how do you know which server certificate to trust so by default Mist access assurance will get its own cert signed by your organization CA. So this is an automatically generated certificate authority for your Mist organization that is signing the certificate for access assurance authentication service.

You can optionally import your own certificate if you want to if you want clients to trust certificates issued by your organization right. For now, we will just use default search. Now the next step for us to complete our basic scenario we can go to organization auth policies by default you could see there is there no policies configured all the authentication requests will be implicitly denied so we'll need to create a rule to allow valid clients to connect. So click on add rule. We'll just say this is wireless EAP-TLS authentication and all we need is to say on the left hand side we are matching on certain criteria. User labels on the right hand side we're deciding what we want to do with this types of users. So here, we are saying we want to look at wireless users. These are predefined labels that that we have in access assurance by default and we want to match on the authentication type EAP-TLS meaning clients will use certificates at this point, that's really all you need to do.

The initial testing right your your policy says allow clients to connect if they match these two criterias and you know technically you would you would have been also able to assign VLANs. We can actually do that here as welL. So we want to assign a VLAN, how do we do that? We can create a label. We can create a label and let's say we want to assign a VLAN 750 let's just say it's going to be our corp VLAN the label type will be AAA attribute okay and the label value would be VLAN. So in this case, you want to assign VLAN 750 and now we if we click here oh now we have our new label showing up so what what this rule is going to do is if a client has a valid cert and it's a wireless client we will allow them to connect and we will assign them to VLAN 750. Very simple very easy let's say.

The next step is to configure our SSID, right? We'll go to Organization > WLAN Templates. We'll create a template we'll call it mist-secure-net i don't know create add WLAN. I'm going to use the same SSID name i'm going to configure it as 8.1x security actually we can also use WPA3 we can then scroll down under authentication service list. We don't need to configure radio servers anymore none of that all we have to do is say our authentication server is Mist Auth. That's it.

The last step is if we are doing dynamic VLAN assignment which we do in in our scenario we want to enable dynamic VLANs we'll say the VLAN type is standard and we'll just say that for now we will only allow VLAN 750 and if no VLAN is sent back from from access assurance, we'll just call it we'll just assign the client into default VLAN 1, that's it just enabling some filters as best practices. Click create our SSID is ready. The last thing for us is to assign this to our org so the template will get advertised on our app. We only have one side, so we can assign it to the org, otherwise you could have assigned the template to the side of your choosing. Hit save. Now our configuration is ready and we can now go ahead and test with a real client.

Authentication policies a little bit. How can we use them in combination with certificates alone? What we will do is we'll create another example, right? So far we've just authenticated the user that used the test certificate we've created before. What if we want to differentiate between different types of users just by looking at certificates? So what I have done is I've created another test user certificate that has a different common name, that has different attributes in the subject that we will use to differentiate between our original test user and the new one.

So what I will do is I will create a label matching on certificate attribute and I will call this my new user one cert because our test user, where is it, the common name is different on the certificate. It's user one at different domain name, right? So we'll take a look at the certificate attribute and we'll match on the common name of this certificate. So in this case, we want to do a full match and just let's say we want to say if this certificate is being used, then we want to assign these users or this user into a different VLAN.

Let's just say other VLAN. So label value VLAN, let's say VLAN one. So I'm going to create another rule. I'm going to say special user or special cert, I should say, select wireless, select TLS. But in this case, we are also going to match on the certificate attribute that we've just configured. So all three conditions here must match in order for this specific policy to hit, right? And when it hits, we will assign the user into a different VLAN.

So we're going to hit save. Now we have two policy rules. Now let's connect the device. I've already configured my iPad with this new certificate. Okay. Now the iPad is connected to a different VLAN. Okay. We see that this is a new user, a different username connected to the same SSID, just assigned to a different VLAN ID. So if we click on it, we'll look at the insights. Let's see if we have new events in there just coming in. Okay. Now we are seeing the new set of events coming in.

We're seeing the new certificate. With a different common name in assert, this is the attribute we've been matching on. And now we see the new rule hit. And in this case, this specific user, this specific client went and hit a different rule. This is how we can make policies just by looking at the certificate with nothing else at our hands. And this is just an example. You could look at part of the subject in the certificate. You could look at the issuers if you have different CAs issuing certificates for other users. You could look at virtually any certificate attribute that you want to look at and use that as the differentiation factor in your access policies.

Configure a Windows device to use a certificate to authenticate-- again, still talking about the lab use cases where you need to man ually install a certificate, manually connect a device to the network . So we have our test lab client certificate with the CA cert embedded. We have our Mist certificate we've exported from the Mist dashboard previously.

So we're going to take those two files. We're going to copy them. We'll move over to our Windows machine. We're just going to paste those two files. So now we will install the client certificate. It is going to be installed as a user certificate. Click Next, put in the import password, confirm installation, and then install the Mist certificate as the trusted certification authority. So we could do-- here, we're going to install it as a trusted certification authority. Next click Finish. And we have installed our CA cert.

Now the next step is to configu re a profile on the Windows device to connect to our SSID using EAP-TLS using our client certificates. So now - by the way, if we want to validate that the client certificate has installed, we could sea rch for certificate manager, go to personal certificates. We now have our test certificate installed that we've created in th e previous step, assigned by our lab CA. You could see it right there.

So now we will create a manual network profile. So we'll go to Control Panel. We'll go to Network and Sharing Center. We'll click on Setup a new connection or network. We'll select Manually connect to a wireless network. We'll put in our SSID name. Security type will be WPA3 enterprise, right? Don't start this connection automatically just yet.

Let's click Next. Change connection settings, that's important. We'll then go to Security. So we'll change the default PIP for smart card or other cert EAP-TLS. We'll go to Settings. We'll then select the Mist certificate we've just imported. This is for the client to trust the Mist authentication service. Again, this is about the mutual authentication piece. We will then click OK. We'll go to Advanced Settings. And we'll use user authentication, because we have a user certificate, in our case. Click OK. Click OK. Click Close. We'll go select Turn on Wi-Fi. We'll connect to our Mist securenet SSID. We'll select our certificate. That's the certificate we've imported. Click OK. And our client device is connected.

Let's take a look how we configure an Android device, in this particular case this is a Pixel 7 device, with our certificate. So we have the same two certs that we need to copy over to the Android device, either through USB or any other way. You'll then go to Settings. You'll then go to Security and Privacy. You'll then need to install those certificates. We will go to encryption and credentials. Install a certificate. Always select Wi-Fi certificate.

First, select the mist certificate. Just call it mistcert. Click OK. Then install the user certificate, the test-lab-client that we have created before. That is the client - oh, that's the password. Should have read that. Desktop client. Installed as well, great.

Final step is to go to Netw ork settings. Go to internet. We will find our SSID we are trying to connect to. We'll select the EAP method as TLS. CA certificate will be mistcert, right there. Now, Domain is the name of the server common name. In the case of Mist default cert, that's off auth.mist.com. The user certificate will be test-lab-client. And identity is your common name of the certificate, basically, your username. In my case, that's my email address. I'm going to click Connect. And now you see my client disconnected using a certificate that we'll just load it.