NAC EAP-TLS Unknown CA Error

[Anonymous]

Hi,

In the process of configuring EAP-TLS with NAC acting as the RADIUS, the problem I keep hitting it the following error when the device tries to authenticate:

EAP-TLS: fatal alert by server - unknown_ca
TLS Handshake failed in SSL_read with error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
eap-tls: Error in establishing TLS session


The command I used is as follows, and made sure the answer to Common Name is the FQDN of NAC at that a DNS entry exists for it:

openssl genrsa 2048 | openssl pkcs8 -topk8 -out nac01-server.key
openssl req -new -reqexts server_auth -key nac01-server.key -out nac01-server-reqext.csr

Have then taken the CSR to the root CA, used the RAS / IAS template and generated the certificate. Then taken the certificate bundle and imported into the RADIUS certificate section in NAC.

The client certificate has been generated using the following rules:

https://support.microsoft.com/en-gb/help/814394/certificate-requirements-when-you-use-eap-tls-or-pea...

The PKI is simple in that there is only the root CA, no intermediate CA and both the client and the NAC have a certificate chain to the root.

Have tried to follow the following post best I can, but obviously slightly different being geared to NPS rather than NAC:

https://community.extremenetworks.com/extreme/topics/how-to-guide-extreme-wireless-authenticates-dom...

Wondering if anyone has any ideas.

Many thanks in advance.
 

[Anonymous]

So managed to figure this out, and as you said and as the description details the issue is related to unknown CA.

I had actually missed a step... school boy error.... but hopefully useful to someone else.

I had uploaded the RADIUS certificate chain, which was indeed correct. But I hadn't actually updated the trusted certificate repository in NAC with the actual root certificate itself.

Here is where you do it:

Once done make sure you enforce.

After that it worked a charm 🙂

[Ryan_Turner]

I will need to get my DDI Architect to help me a bit on this. I setup our freeRadius a long time ago and don't remember all the specifics (and he has since made it much much better).

I don't think the problem the individual is having has anything to do with certificate fields. We troubleshoot these types of problems from time to time and normally we have this sort of problem if someone attempts to connect to eduroam with a self signed certificate, or when we decide to start issuing certificates from a new CA and we have to tweak the certs file. I think the certificate setup will be in the eap.conf file. There is a line for the certificate file.

I will ask our architect on Tuesday (I am off tomorrow).

To answer the easy question... I don't like abstraction that the Extreme NAC does for complex radius configurations. As I know you know, NAC is using freeRadius. And if you don't make changes through the GUI, then those changes get overridden if you hand edit files upon enforce. We have a complex radius setup due to eduroam and proxying requests outside of UNC, so I just prefer to have the authentication requests for EAP to be handled by a hand crafted radius configuration. We can tweak the settings to tune our EAP-TLS authentications. I think it also allows your RADIUS configuration to scale better. Instead of a maximum of 4 RADIUS servers that can authenticate requests, you can spread it to 8 (send all requests to NAC, terminate the MAC auths, and then proxy the EAP requests to another bank of 4 servers (or 3, I can't remember the maximum offhand). What we've noticed is that even though EAP requests actually have to get proxied to another bank of radius servers, our EAP requests are actually FASTER (average around 20ms) versus 70ms for mac authentication. Makes no sense, but our instrumentation is correct.

We also have a scale that most people don't obtain. We have 10,000 access points. We can't get away with a lot of things smaller institutions can get away with.

[Anonymous]

Thanks again Ryan for taking the time to post back. Interesting to hear about your particular scenario.

Look forward to hearing back when you've spoken to your Architect.

[Anonymous]

Hi Ryan,

Thanks for taking the time to answer.

Their certificate chain just exists of the root CA and the client or the server itself. The client and NAC certificate (RADIUS Certificate) should be correct both in the CA and the chain, but there is an assumption i.e. I've been assured its correct rather than me actually checking, so thanks for your answer I will make sure I double check myself.

My other thought was that the client certificate being presented to the NAC isn't the one we are expecting it to be, need to find out how I check that.

Don't suppose you know where on the client certificate repository should the client certificate reside, and possibly the root CA for EAP-TLS to work...something I will also be checking when I next visit also.

The other parts that I wasn't 100% sure on was the actual generation of the both the client and server certificates. For example; using the CSR generated on NAC I used the RAS/IAS template on the root CA to generate the NAC RADIUS certificate, and wondered perhaps if the template contained all the correct certificate fields EAP-TLS required i.e. I made sure it includes the common name. Equally the same when creating the client certificate i.e. the link above I provided mentions it needs to have some specific EKU extensions?

Also, one side question. There was a time a while back where we were tutored not to use NAC as the main termination point for authentication but pass that on to something like NPS or FreeRadius.

Later I have been told the opposite, in that using NAC is perhaps better as its easier to manage and scales to pretty much anything you want.

So out of interest I was wondering why you are using FreeRadius, perhaps it is something you already had implemented?

Many thanks.