ISE v3.0 - Trusted Certificate Store for 802.1x PEAP Certificate Authentication

[Mike Pennycook]

Hi All, 

I'm trying to configure Wireless 802.1x with PEAP and I understand for ISE to verify the user certificate that it will present, I need to have a Root CA in the list of 'Trusted Certificates' within ISE. I've imported that as follows:

That's the Root CA Certificate which should authenticate the User certificate when presented.

However, when hovering over it next to the 'i' , like the other certificates it says 'This certificate is not used to verify the authenticity of client certificates presented to ISE':

If I go into Edit mode, and see the certificate usage, I've selected 'Trust for client authentication and syslog':

What I wanted to confirm is - 

1) Is the above certificate being used to authenticate the user when it presents it's certificate during PEAP authentication?

2) Is there any debug/trace within ISE that would show the User certificate authentication passed? I know in the Radius live logs I can see a detailed log of authentication steps, but there seems to be nothing related to certificates itself, unless I've missed something?

Many thanks for your help!

[Greg Gibbs]

First of all, PEAP only provides for the client authenticating the server. For this to work, the client needs the Root CA that signed the ISE EAP certificate in it's own Trusted Root Certificates store. If you want mutual authentication where the server must also authenticate the client, you need to use EAP-TLS.

Secondly, the message you are seeing is likely due to the Enhanced Key Usage (EKU) in the certificate having the Server Authentication usage and not the Client Authentication. These settings are defined in the certificate template on the CA.

Example client cert:

[Mike Pennycook]

Hi  @Greg Gibbs 

Thanks very much for your help & response - 

Understood about PEAP and authenticating the server (ISE) - The Root CA is in the Client which is attempting to connect, and can validate the ISE certificate.

I've now configured the ISE Policy Set with a filter for 'allowed protocols' as follows:

For the certificate on the Client Windows 10 laptop, in the Local Computer certificate store, we have a certificate configured for client authentication:

I imported the Root CA from MS AD Certificate Services ('Download a CA Certificate', in Base 64) which had no option to configure the EKU, and placed it in ISE 'Trusted Certificates'. 

Where I came across a certificate template was when I generated a CSR on ISE, got it signed by the Root CA (advanced certificate request), I selected a template I had created previously for client authentication and then imported that into ISE 'System Certificates', with a usage of 'EAP Authentication'. However I assumed what was in 'System Certificates' was only used for the certificate that ISE presents itself when the client laptop authenticates it. So I didn't think it was this certificate that would be authenticating the client certificate when presented. Maybe I have understood that wrong?

Currently, the attempt to sign into the SSID fails with this log on ISE:

[Greg Gibbs]

I agree with @Peter Koltl. If you want mutual authentication, you should just use straight EAP-TLS. I don't see the value in using PEAP-EAP-TLS.

See the EAP-TLS section of the Wired 802.1X Deployment Guide  for more information on the EAP-TLS flow.

With Windows, you should have Group Policy that auto-enrolls a Computer (and optional User) certificate on the client. This will also install the Root CA certificate in the Trusted CA store on the client.

If you sign the EAP certificate used by the ISE PSNs from the same Root CA, both ISE and the client will have the same chain of trust. You just need to ensure that the ISE Trusted Certificates store has any Intermediate/Issuing CA certificates as well as the Root.

[Peter Koltl]

The combination of outer PEAP and inner EAP-TLS is so complicated to set on the client side properly, why not use plain EAP-TLS?

[Mike Pennycook]

@Greg Gibbs @Peter Koltl Thanks for your response, I'll look into EAP-TLS, the guide is also quite helpful.

Reading about the differences I understand the benefit with PEAP-EAP-TLS is to hide the fact that client certificate authentication is being used, in case certificates are stolen for example: https://www.wiresandwi.fi/blog/peap-eap-tls-vs-eap-tls - the author does mention at the end that he would still use EAP-TLS if given the choice, and PEAP-EAP-TLS is unusual!

Just out of curiosity have you guys seen PEAP-EAP-TLS working properly before?

[Peter Koltl]

I used PEAP-EAP-TLS until I learned it can be used without PEAP.  

[Mike Pennycook · Accepted solution]

Hi @Greg Gibbs @Peter Koltl 

I've followed your suggestion and implemented EAP-TLS, thanks for your help.

For anyone else's reference, my colleague got the bottom of the reason why the Windows 10 Laptop wasn't responding to ISE, hence the 'Supplicant stopped responding to ISE after sending it the first EAP-TLS message'. Windows 10 has specific requirements for certificates being used with EAP-TLS/PEAP: 

https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/certificate-requirements-eap-tls-peap

One of them being:

"The Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN) of the user."

Very difficult to find as there was no clue on the error message itself or the Windows Event logs. Once we added the UPN within the certificate SAN, the error went away. 

I also wanted to ask you both, what would you consider to be the best standard in authenticating wireless users for Corporate network access? Is EAP-TLS secure enough or would you recommend anything on top of that? We're considering whether MDM (Intune) integration with ISE would be worth it for an additional check on the client, in case a certificate ever gets stolen. 

[Aref Alsouqi]

If you configure ISE to verify the certificates status whether using the traditional certificate revocation list or OSCP that will be enough for ISE to reject the authentication requests coming from a stolen endpoint because in that case you would have revoked the stolen machine certificate on your PKI. Stolen the cert itself but not the machine is difficult and could be mitigated by setting the private key not to be exported. A part from that, having more conditions on ISE policies before allowing accesses is good, however, I would try always to keep things simple and effective at the same time. Another option you would have is to use TEAP which uses chaining, for example, with TEAP you can set some access levels when the machine authenticates but not the users, and full access levels when both the machine and the users authenticate.

[Akin Utku]

So no one has actually answered your question as far as I can tell. 

Could you kindly confirm that the message "This certificate is NOT used to verify the authenticity of client certificates presented to ISE. It is only used to..." doesn't actually mean what it says and the root certificate is being used to validate client certificates? 

Thank you! 

[hslai]

Known issue -- CSCwb93156

[Akin Utku]

Thank you so much, that's exactly it.