Zero clients with SCEP cert not authenticating via ISE

[snyderkv]

ISE authenticates Windows machines via 802.1x but not with Zero clients (both wired). The Zero clients obtain a root and pfx cert via SCEP. The pfx cert which I select when checking the 802.1x button on the Zero client shows issued by "issuing" and that is the cert the Zero client sends to ISE. The Zero is using EAP/TLS. 

SCEP is setup completely default so perhaps the certificate template needs to be setup with Client Auth EKU and not just signature/Key. Here is a stock photo online of the SCEP template settings (mine does not show Client Auth) just for an example and below that are the ISE errors. The last error shows a normal workstation cert for 802.1x. You can see it has a root cert in the chain. But my SCEP cert pfx does not show a root cert in the chain, just the issuing. Any ideas? 

 

 

[Arne Bier · Accepted solution]

Hello @snyderkv ,

Do you use the same Root CA and Issuing CA to issue client certs to Windows and Zero clients?  If so, then I assume you have this Root CA and issuing CA cert installed in ISE under trusted certs, and marked as "used for client auth"?

For any client certificate creation, client authentication EKU attribute is mandatory. 

Here is an excellent reference on what to do on ISE, regarding certificate creation and usage.

And on the client supplicant, do you have the option of trusting (or not trusting) the RADIUS server? A secure client would be configured to trust the RADIUS server certificate, and that is done by telling the client which CA cert(s) to expect from the RADIUS server. Of course, that also means that the client must have the CA cert chain that was used to sign the RADIUS server's EAP certificate.

If you look at a Windows CA Server default template for a client, then you can use that as a starting point. You can try RSA 2048, SHA256 as a basic config. But other encryptions and hashing algorithms are supported. Somewhere in the ISE release notes I think there are more details.

[snyderkv]

Thanks Arnie. I think the "client auth" may be the issue but I'll try and answer your questions.

1) The root is offline and the Issuing CA issues certificates I believe. Does this change anything?

2) ISE does have a root and issuing CA in it's certificate store.

3) I have the management console set to "Check TLS CN disabled" which I think disables this ISE certificate check (unchecks the ThinPC box "Validate server certificate") but I did export the ISE server cert and import it into the ThinPC.

4) I'll look at the CA template used to generate our Windows keys but  SCEP is using a default IPSEC (offline) template to generate the ThinPC keys and did not see "client auth" in its EKU as shown in the picture. I'll look into fixing that.

[Arne Bier]

> 1) The root is offline and the Issuing CA issues certificates I believe. Does this change anything?

The CA certs do not have to be online for EAP-TLS to work. If you're interested in rejecting revoked client certs, then you have to provide ISE with a way to check that - either via CRL (cert revocation list) download from the issuing CA, or via OCSP (online cert status protocol) to the issuing CA.

I am keen to know how you get on with this

[snyderkv]

I'm going to create a new template shortly but wanted to answer that SCEP renews certs on the ThinPCs at the half life of the certificate it issues so I guess revocation checking isn't important unless I misunderstood you. 

[Arne Bier]

@snyderkv  - ISE can optionally perform client certificate revocation checks, to check whether a client cert has been revoked by your (offline) CA. Cert revocation checks require that ISE would have either http access to download the .crl file periodically, or, if using OCSP, then the http server needs to be online 24/7.  The CA can still be offline (as in your case) - CRL download is a simple http request to any http server that you statically configure in ISE (or in the certs CDP attribute "CRL Distribution Point"). In your case you'd have to generate the CRL from your CA, then place the resulting CRL file on the http.

If you don't plan to revoke any client certs, then don't worry about this comment.

[snyderkv · Accepted solution]

Arnie,

I figured it out.

It was in fact what the ISE error stated. The SCEP certificate was pulling from the default CA template IPSEC (Offline Request) which I don't believe had "client authentication" and whatever else in the application policy.

I duplicated another template and just configured it similar to the existing computer template that ISE is already authenticating. SCEP then pulled a cert constructed from this new template with (client authentication) in the template properties and was able to authenticate.