Cisco ISE EAP-TLS with Windows Domain Cert

MattMH · ‎03-23-2023

I am trying to migrate our 8021x auth from NTLM to EAP-TLS. It's a production env and the ability to test certain changes is limited. With that said, here is the error message that I am getting when trying to test with a couple of machines.

12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client certificates chain.

When I look at my ISE certificates, under System Certificates, I see that the cert associated with EAP Authentication (pxgrid, Admin etc) has a cert SN# ending in 02c1.

When I download our internal CA root from a domain controller, it has a cert SN# ending with cc6.

Is that an issue? Assuming it is, but can I get help confirming this?

If so...

I took the cert I downloaded from the Internal CA (cc6), generated a new CSR in ISE using that cert, and changed the "used for" option to be EAP Authentication only, went through the Microsoft AD CA Web Enrollment process and have my certificates downloaded. I want to bind these new certs, but when I go through the bind process, it states there can only be 1 system certificate associated with EAP Authentication. We do not use EAP for anything in our environment yet, so I am assuming that this bind process would not cause issues. Would that be a safe assumption? Once the bind process completes, will there be a different system certificate associated with EAP Authentication in my cert list linked to that cc6 SN#?

Final question, I see some posts suggesting that there is something from ISE that has to be imported into MS AD. I am not sure what that would be since the documentation I find does not seem include that as something needed. Am I missing a step altogether? Considering we are using our Internal CA, not a 3rd party CA, I do not think that is necessary. However, ISE is new to me.

I followed the steps in this post for reference.. ISE - Adding Certificates to ISE and Creating Certificate Profiles - Cisco Community

Octavian Szolga · ‎03-23-2023

Hi,

Each cert has a unique serial number. Replace a cert with your passport. You have a passport, I have one. Assuming we're citizens of the same country, the same entity signed/issued our passports. Still, each passport has it own serial/id number.

Same goes for certs.

Long story short, the error you're seeing in ISE may be related to:

1. You've missed the step where you have to import Internal CA cert in ISE using Administration>System>Certificate>Certificate Management>Trusted Certificates

2. You may have a PKI with multiple CAs (like Root CA which has multiple SubCAs) and actually one SubCA signes the certificates of your PCs. In this case, it's not enough that you imported in ISE the RootCA. You have to add to Trusted Certs the SubCA as well.

3. Maybe you did everything right (1 and 2) but actually your PC is sending to ISE another certificate, signed by a totally different CA, in which case is normal for ISE to complain about the fact that it doesn't have any info regarding the issuer, thus cannot authenticate your endpoint

BR,

Octavian

MattMH · ‎03-23-2023

OK, good info and that makes sense. So, I am going to, in ISE, bind my Windows AD root certificate to a new ISE System Certificate that will be assigned the role of EAP Authentication. What I am not able to determine is, what will my system certificate section look like? Will a new certificate be installed that has the EAP Authentication use role? Will the current system cert that has the EAP Authentication role be modified by this bind process to that the EAP Authentication use will be removed after the bind? Tough questions I know. I don't have a test env to test, so maybe a TAC case is my best option. Assuming I could backup/export the current certificate being used for EAP Auth. I suspect the cert from my PC (see below) has to have a certificate path back to the proper root CA cert in ISE with the same SN#.

Octavian Szolga · ‎03-24-2023

Hi,

Why do you compare ISE Cert SN with the SN of CA cert?
At least this is that I see when I look at your picture. The SN you're looking in ISE is not the SN of Root CA. It is the SN of ISEs own certificate signed by Root CA.

Also, regarding this statement - I am going to, in ISE, bind my Windows AD root certificate to a new ISE System Certificate - binding refers to the fact that you're glueing a previsoulsy created ISE CSR with a signed certificate (which is basically the public key from CSR signed by CA with additional fields).

Recap

- Root CA - has to be in Trusted Certificates with 'Use for Client Authentication' box checked

- ISE Cert - seems to be ok - why do you want to sign a new EAP-Auth ISE certificate, if ISE already has a valid certificate signed by the same CA that signed your PC cert?

You can always add a new ISE cert in system certs and enable the checkbox 'use for client authentication' afterwards, after you deselect the option on the former certificate, but in your case, I don't see the point.

BR,
Octavian

MattMH · ‎03-24-2023

Thanks Octavian. Wrapping my head around this (I am a phone guy and have setup 8021x for CCM phones with another product).

1. Should I see a certificate in the Trusted Certificates section that has a SN# equal to the certificate/SN# setup for EAP Authentication? I do not see a SN# in the Trusted Certificate section ending with 02C1.

2."...binding refers to the fact that you're glueing a previsoulsy created ISE CSR with a signed certificate (which is basically the public key from CSR signed by CA with additional fields)" My guess is, over the years (because have never used EAP), the ISE CSR generated from our Windows CA is no longer "glued" to the certificate responsible for EAP Auth. I am making that determination simply because the SN#'s do not match. Maybe a moot point.

3. "...Root CA - has to be in Trusted Certificates with 'Use for Client Authentication' box checked" The root CA is checked, but its not "glued" to the certificate used for EAP Auth. That's the part that I am confused about. Although its not apples to apples, if a phone (using past experience) was not tied to the proper Windows CA root it would not auth). Whether or not that is applicable vs using a domain PC, I am not sure. That's why I am focusing on this I guess.

4. "You can always add a new ISE cert in system certs and enable the checkbox 'use for client authentication' afterwards, after you deselect the option on the former certificate, but in your case, I don't see the point." That is where I wish I had a test environment. The current Trusted Certificate from our Windows CA has all the boxes checked, Trust for Auth, Trust for client Auth, Trust for Admin Auth, trust for auth of Cisco services. I have gone through the process of generating a CSR, setting the "Certificate will be used for" only to EAP Auth, signed that CSR by our internal Windows CA and am at the binding step. I just do not know what impact, if any, this has on our current environment (or if this is what is preventing our test machines from Auth-ing). Since the Windows CA cert in the Trusted Root section (which someone else imported at some point) is setup as "Trust for certificate based admin authentication", does that break our connectivity to manage ISE if I complete this bind process? When I complete this bind process what happens? Will I see a new Trusted Cert or a new System Cert?

I need to keep reading into this. These seem tough questions to answer since 1) I am not clear on the cert process within ISE and 2) no way for me to safely test the changes.

I'll keep digging.

rileybrok · ‎07-22-2023

I appreciate the information. It makes sense to me. I will refer this to my blog Admin.