cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
742
Views
0
Helpful
10
Replies

ERROR 12321 PEAP failed SSL/TLS handshake

jonzhong
Level 1
Level 1

Hi

I have a non window/ios/android device that uses security protocol "WPA2-PEAP-RADIUS" to connect to our corporate network.

Our device only require SSID, Username and Password input to join the network. Previously, it was working fine until a recent certificate replacement was perform on our ISE.

Under this security protocol, there is no option for us to upload the new certificate to our device.

How can we resolve this?

Thank you

10 Replies 10

marce1000
Hall of Fame
Hall of Fame

 

  - FYI : https://community.cisco.com/t5/network-access-control/12321-peap-failed-ssl-tls-handshake-because-the-client-rejected/m-p/3567819#M497093

  M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Hi, I have read this solution, however there is no way for me to upload any certificate to my device. 

The client device was setup to trust the old ISE EAP certificate. If it didn't care about the RADIUS server cert, then replacing the ISE cert wouldn't be significant - but it appears that way.  Or did you change any Security settings in ISE ? e.g. disable TLS 1.0/1.1 etc.?

jonzhong
Level 1
Level 1

TLS 1.0/1.1 are all enabled.

Before certificate replacement, devices were working normally. Really at a lost on how to resolve. As the device representative highlighted that they are not using any certificate for authentication.

Your vendor is correct - EAP-PEAP uses username and password, and does not use a client certificate (that would be EAP-TLS). What your vendor is not telling you, is that with any good EAP implementation, the clients SHOULD validate the RADIUS server (i.e. ISE) certificate when the TLS tunnel is established. That check seems to be happening and it failing, because the ISE cert has been changed - therefore the client no longer trusts ISE. Which is good.

I don't know what your ISE EAP Server Cert looks like and how it was generated - I hope it was generated by a PKI (Root CA etc.) - in that case, the client devices should NOT have the ISE EAP cert installed, but rather, they should have the Root CA and all other CA's that were in volved in creating the ISE EAP cert. In that way, no matter how often you change the ISE EAP cert, the client will trust ISE as long as the same Root CA and and any Issuing CA's are still the same as before. 

If (heaven forbid) the ISE EAP certificate(s) are self-signed, then you need to get that cert into all those "IOT" style devices. That would be a reason to implement a PKI and get ISE EAP certs signed properly. Any device that does EAP should have some kind of interface (graphical or CLI) to manage the supplicant (i.e. the 802.1X software stack)

 

We are waiting for principal vendor to provide some update. what you have mention is exactly what my network team is advising. we do have another IOT device that also face the same error but their case have an interface upload new certificate.

Since your device lacks an interface to upload the new certificate, the only viable solution is for the vendor to push a firmware update that trusts the new ISE certificate. Meanwhile, consider temporarily enabling a certificate chain that matches the previous root or intermediate CA if possible, to restore connectivity.

ISE only supports a single EAP Server certificate installed on a PSN. This issue has nothing to do with the ISE Trust Store. With EAP-PEAP, ISE is not checking the endpoint during TLS - there is no client cert!

The issue is with the client not trusting ISE - and that's what @jonzhong is trying to resolve.

Even if you had the old cert and private key, you can't install that into ISE and run it alongside the new one. The problem is that the IOT device only trusts the old ISE EAP Cert, and not the new one. And that's a client problem. Since, the alternative would be to swap out the ISE EAP Cert (if that's even viable ... there's probably a good and valid reason why it was replaced ... expired etc.) - but doing so might impact other clients.

 

you are right, the old cert and the new cert cannot co-exist. i am pending corporate end to get back to me on what was the difference between the old and new cert. the corporate cert would been created from the root CA as well.

thanks for replying.

we are waiting for vendor to get back to us on this.