ISE, EAP, and certs. Odd issue.

[Dustin Anderson]

Ok, so for the longest time, my ise units have just been ise1.company.com, with an internal cert from our domain CA. This has worked fine until Android 11 and users being unable to set to not validate cert.

So, I thought we could just get a public cert and it would fix the issue, but I am seeing more issues now. The public cert is from COMODO, and everything web wise is valid, but part of the issue is internally, the AD and stuff is company.us, and I think there is issues with that and the company.com cert, but not sure.

With the android device, I can put the domain as company.com, and it will join the wireless, if I do company.us it will not, but that's not a big issue.

The big issue is domain joined PCs will no longer authenticate. I have a test PC and even reloaded the root and intermediate certs from COMODO and I'm still failing auth. If I use a cert from our internal CA, it works fine. Now with public, or internal, the ise is always .com

I'm really at a loss as to why the PCs stop authentication on switches.

Event 5411 Supplicant stopped responding to ISE
Failure Reason 12934 Supplicant stopped responding to ISE during PEAP tunnel establishment
Resolution Verify that supplicant is configured properly to conduct a full EAP conversation with ISE. Verify that NAS is configured properly to transfer EAP messages to/from supplicant. Verify that supplicant or NAS does not have a short timeout for EAP conversation. Check the network that connects the Network Access Server to ISE. Verify that ISE local server certificate is trusted on supplicant.

[Mike.Cifelli · Accepted solution]

The big issue is domain joined PCs will no longer authenticate. I have a test PC and even reloaded the root and intermediate certs from COMODO and I'm still failing auth. If I use a cert from our internal CA, it works fine. Now with public, or internal, the ise is always .com

-During your testing have you confirmed that the certificate chain for your new ISE cert is trusted by your client with the respective root and intermediate certs in the proper stores? What supplicant are you using (native/nam)?  Can you share your supplicant configuration from your test client? Double check the supplicant config to ensure/verify if the new trusted root is allowed.  This may shed some additional light as to what I am mentioning: Configuring Windows Supplicant for 802.1x authentication – integrating IT (wordpress.com)

HTH!

[Dustin Anderson]

OK, I think you sent me down the right path, but not sure why it works with an internal cert.

So, these are windows supplicant. Under the 802.1x setting, there is a validate cert setting, and a list of trusted CAs. None of them are checked, not even our domain CA, so although checking COMODO seems to fix it, I'm not sure why/how the local domain works as that is not selected as a valid CA.

So, that looks to be the missing piece, but now confused why domain cert ever worked.

[JPavonM]

I know this is an old thread but I have found the same behaviour with internal and publics certs presented by ISE, which is not happening when using MS NPS.

I can confirm that both Win10 22H2 and Win11 22H2 are impacted by this, and the workaround is to use internal certs for the corporate connection, and public certs for BYOD.

In parallel, I have a support case open with Microsoft to investigate this, as the problems seems to be related to the lack of trust in the issuer from Windows.

The workaround is to configure the wireless profile in Windows with the option "Don’t prompt user to authorize new servers or trusted CAs" unchecked, so Windows will ask the user to trust on the cert to connect, BUT if that option is checked, then Windows won't connect.

[MHM Cisco World]

thanks for this note 

MHM