EAP-TLS,SCEP failing with Windows 10 11514 Unexpectedly received empty

[PiotrBurczyk80035]

Hi,

I've been working on a setting up an EAP-TLS wireless auth in Cisco ISE 3.2 for mix of domain joined and Autopilot machines.

At first I focused on machine authentication...I know it's not the easiest and not a best practice to set this up for AAD joined devices.

ISE is a lab setup (single node with all personas), but it's integrated with AD, its cert (used for Admin, EAP, Portal etc.) is signed by our Intermediate CA.

For domain joined laptop (W10) with an old NPS certificate for Client Auth. EAP-TLS authentication works like charm.

But Autopilot machine could not authenticate to the same SSID.

For Autopilot I've asked the guys managing our PKI/Intune to follow the guides and they've configured the NDES/Azure App Proxy, Intune Connector, configured Cert. Template and deployed SCEP cert. via Intune profile to test machines.

Cert looks good, at first sight...I tried to be changing stuff in it, making sure the config match the certificate template, but no difference in wireless authentication.

Also Root and Intermediate certs have been pushed to the Autopilot client with a help of Intune.

Whatever ISE policy and whatever CAP I've tried the client could not pass the Authentication phase.

I'm getting a error:

5400 Authentication failed
11514 Unexpectedly received empty TLS message; treating as a rejection by the client

Now, it's hard to vouch for the certificate template config...basic checks not revealed any discrepancies from the guide, but I can't vouch for it.

I'm trying to rule out the the issue of a client failing to trust the ISE EAP cert.

My thinking was, that if the same cert is being used for Admin, Web Portal and EAP, I can validate the trust by opening WE GUI of ISE on the test Autopilot machine - this reveals no errors, machine trust the ISE Gui webpage and cert assigned.

Question 1. Is this a proof, that machine should also trust ISE EAP certificate?

From the other hand, I was trying to test with the same SSID, also supporting EAP-PEAP with MsChapv2, as in this case client should also trust ISE EAP cert.

And when I do not pre-configure Wireless Profile on Windows, but just try to connect, I'm being prompted for Username and password. When I provided valid AD creds, I got a certificate warning:

Question 2: Does that warning proves, that client does not trust ISE certificate?

Because when I do pre-create a profile (still for PEAP with Mschapv2) and select Root CA, that provide trust to ISE, it allows me to connect without any certificate warning.

I hope you guys could point me out to some direction, as I'm quite fed up with this Autopilot/SCEP authentication

[Aref Alsouqi]

During EAP negotiation both parties will be looking at each other certificate, and both need to trust each other. From ISE perspective, we usually import the internal PKI root CA or subCA certs and we enable the "Trust for client authentication" option. That will tell ISE that if a client presents a certificate issued by one of those issuers trust it and carry on with the authentication check. The EAP cert that ISE presents to the client should be trusted by the client as well, usually the issuer of the clients and ISE EAP certs is the same.

[PiotrBurczyk80035]

That's the case for us.
Same CA issuing ISE and client cert.
Does work for Domain joined PC and PKCS issued client cert, but doesn't work when we try Autopilot machine with SCEP client cert.

[Aref Alsouqi]

What issuer certificate are you using on InTune? is it your internal PKI root/subroot CA cert? or is it Microsoft one? either way, is that cert(s) imported into ISE certificate trust store and has the "trust for client authentication" tickbox enabled?

[PiotrBurczyk80035]

Yes. We're using internal PKI SubCA, which is issuing client authentication certs. via SCEP, with the help of NDES/Intune Certificate Connector and Azure App Proxy.

I've just triple checked, and looks like SubCA which has issued the client SCEP cert is in ISE Trusted certificates.

Below the certificate details from ISE:

SubCA:

Root CA, that issued SubCA is also in the same Trusted Certificate store:

Root CA:

ISE System EAP cert:

[PiotrBurczyk80035]

I'm keep my testing.

Have generated Self Signed Cert for EAP authentication in ISE. Exported it and added to Trusted Root CA store on my test PC's.

Same result, meaning:

- Computer Authentication doesn't work

- User Authentication works, when I setup PEAP/MaChapv2

Any clues where I'm messing things up?

[Nancy Saini]

This seems to be an issue with the client certificate. Can you share the detailed authentication report from ISE? Also, is the client certificate chain (intermediate and root CA certificate) present on the trusted store of client?

[PiotrBurczyk80035]

Machine certificate, issued by SubCA.

Root CA cert under Trusted Root Certification Authorities folder:

SubCA in the Intermediate Certification Authorities folder:

Now, when I preconfigure this W10 machine to connect to SSID with EAP-TLS below settings:

I'm getting "Can't connect to this network" info on W10, and in ISE it looks like this:

If it's more helpful with a copy text report, rather than screenshots, please let me know and I can send you over PM.

[Nancy Saini]

The reports are not complete, need to understand at which step during the SSL handshake is client sending an empty TLS message. This really seems to be a client side issue. Have you reached out to Microsoft support regarding this?

[Aref Alsouqi]

Could you please try to disable the "Verify the server's identity" tickbox and see if that makes any difference? also, could you please share ISE certificate authentication profile configuration for review?

[PiotrBurczyk80035]

Hello guys.

Think I found the problem.

It's TLS 1.2 issue between Windows and Cisco ISE.

It's not clear to me yet, if it's a specifically TPM related issue - described here and here , or a Windows/ISE TLS1.2 issue described here , where Microsoft is blaming Radius vendor.

I only have 2 test machines and got some strange results while applying workarounds. In any case I got it to work finally. 

I'm going to find some additional machines for testing and share the results.

But I wanted to have an clear answer from anyone here, to one of my initial questions:

Is below warning proving, that there's a certificate trust issue between Windows client and ISE radius server?

Or not necessarily?

I am aware, that I can workaround this by pre-configuring WLAN on Windows, but I'm just curious why I'm seeing this warning in some specific test cases, and not in others.

[Aref Alsouqi]

That warning would show up when the machine doesn't trust the certificate. Please make sure that you import that certificate (or the issuer of that certificate) into the machine trusted root certificates container, that should fix it.

[Hege · Accepted solution]

Hi,

I have faced similar issues and the problem was related to TPM stored certificates.

See the solution here: CSCwb77915 - Toggle to enable/disable RSA PSS cipher - Cisco Community

Go to CLI and use application configure ise command. Choose menu item 33 and disable RSA PSS cipher.

Note that ISE application will restart so there will be downtime! Do it on all PSNs.

[PiotrBurczyk80035]

Thx Hege,

This was the right spot.

Although applying the workaround on the Windows machines and manipulating their registry settings worked, the workaround with disabling RSA PSS ciphers on Cisco ISE fix the issue more effectively.

It took me some time to apply patch 2 for ISE 3.2 (which is required to have the option to disable RSA PSS ciphers) and to restore admin cli access, where I seems the face another ISE bug.

The whole process of troubleshooting and testing the solutions was an uphill battle for me, but all in all it works like a charm now.

Happy to went through this....got some better understanding how things works.

[TedB123]

---

@PiotrBurczyk80035 wrote:

Thx Hege,

This was the right spot.

Although applying the workaround on the Windows machines and manipulating their registry settings worked, the workaround with disabling RSA PSS ciphers on Cisco ISE fix the issue more effectively.

It took me some time to apply patch 2 for ISE 3.2 (which is required to have the option to disable RSA PSS ciphers) and to restore admin cli access, where I seems the face another ISE bug.

The whole process of troubleshooting and testing the solutions was an uphill battle for me, but all in all it works like a charm now.

Happy to went through this....got some better understanding how things works.

---

im in exactly the same boat as you ...
editing the regkeys fixed the issue but now i need to make the change on ISE 3.2...
and looking at the cli, i do not have option 33 so i need to apply patch 2 to do this

like you, troubleshooting this was a real pain and it was pure fluke that i stumbled onto this post and another that pointed me to the ciphers.

time to get patching....