ISE 1.3 and 2.0 certificate EKU requirements and CSR

[Tim Baum]

Is ISE 1.3 and/or 2.0 suppose to request EKU=client auth in the CSR it generates?

Customer ran into upgrade issues (1.3 -> 2.0) and I think I've found the issue. The server certs have a EKU with only server authentication. No client auth. I had them generate a new CSR and check it with openssl, there is a EKU of server auth, no client auth.

I've checked a couple versions and it seems to be consistent. When I look at my lab's server's certs they all have server AND client auth. My guess is my CA was adding it.

Is it expected that the CA adds this EKU or should the CSR request it (bug with ISE)? The cert usage type does not seem to change the KU or EKU fields.

Thanks

Tim

[hslai · Accepted solution]

That should not matter normally.

If you mean ISE system server certificates, then they only need "server auth" unless used for pxGrid nodes. Microsoft CA issues certificates based on the certificate templates used.

Many well-known CA, including HydrantID SSL CA, nowadays issue certificates with "server auth" and "client auth" in EKU, when we request for web server certificates.

[Tim Baum]

The customer requested new certs, specifically asking for server and client auth and that appears to have fixed the problem. There may be something else at work here but odd that these certs work with 1.3 but not with 2.0.  And requested new certs does.

[Tim Baum]

It appears the problem is that ISE 2.0 is doing revocation checks when it is not enabled. The test environment has partial connectivity i.e. DNS works but LDAP is not allowed. It appears that when you try to register one ISE node to another, even with revocation not configured for the trusted CA certs, ISE is trying to check the CAs.

The CA certs have a LDAP and HTTP link for CRL, LDAP listed first. From the trace it appears that ISE does a DNS request, gets 30+ addresses back since the FQDN is a MS AD controller name and all the controllers are returned, then ISE tries an LDAP bind to each one, fails and then tries the next one. This goes on over and over. The ISE server seems to hang.

We tried configuring CRL retrieval with the HTTP link and that did not change the situation.