EAP-TLS authentication ending with "client alert message"

[David Bird]

This is the last step in a migration from ACS to ISE. ACS is running 5.8 on the last patch, and ISE is running 2.4p9.

The two SSIDs involved here are for BYOD managed by MobileIron with a very limited trust check in ACS or ISE.

The only difference between ACS and ISE on SSID1 or SSID2 should be the cert chains/rootCAs. The policies are as similar as they can be between ACS and ISE.

If SSID2 is pushing the publicly signed CA chain as used on ISE for trust on the endpoints instead of the publicly signed CA chain used for SSID1 on ACS it should work the same manner as the trusted CA chain does on ACS, but it definitely does not.​

In ISE we are seeing the following:

A request for SSID2 goes through the steps of EAP-TLS handshaking and eventually fails with a "client (endpoint) alert message".

When the above happens enough times, the action is being blacklisted and blocked on the WLC

ISE diagnostics theorize that the certificate chain used for EAP in ISE is not trusted on the client (endpoint)

The cert trust is definitely the issue, the question is where it is failing and why. The question is, has anyone else seen this at all?

[Colby LeMaire · Accepted solution]

If the client doesn't trust the certificate being presented by ISE during the EAP-TLS exchange, the client will reject the certificate and stop the session.  You will see the client alert message that you are referring to.  Make sure that the EAP certificate in ISE is issued by a CA that the client trusts.

Also for troubleshooting, you can disable "Client Exclusion" on the SSID under the "Advanced" tab.  Uncheck that while you are troubleshooting so as to not cause confusion.  In ISE, you can also disable suppression under Administration->System->Settings->Protocols->Radius.  Then once everything is working, go back and turn suppression and "Client Exclusion" back on.