ISE 802.1x authentication SCEPcertificate verify Common Name not chain

[117222400]

Hi Experts

Recently we renewed our Root CA certificates and Intermediate CA certificates, we didn't uploaded them to our ISE server. While all devices with new certificates or old ones are working. Just curious it seems didn't verify the certificate chain of trust, and it mainly verified the Common Name(username) in AD.

1. On ISE , the certificates are: Old Root CA certificates, old Intermediate(issuing) Certificates x 2.

  The settings are

2.On users’ devices, the below certificates can pass authentication:

• on iPhones, SCEP certificates pointing to Old Root CA certificate
• on iPhones, SCEP certificates pointing to New Root CA certificate
• on Windows10, user/computer certificates on Windows 10 all pointing to New root CA

3. the below is Authentication logs, it looks ISE will only use the uploaded Intermediate CA certificates for CRL verification, and then select Common Name from the SCEP certificate to verify it in AD.

Looks ISE didn't verify the chain of trust, as new SCEP certificates pointing to new Root CA will still get allowed. It only do CRL verification via old intermediate CA certificate.(I think the CRL didn't change during our Root CA renew).

If it is right, then when should we upload the new Root CA and new Intermediate(issuing) CA certificates onto ISE? only when the old ones expired? or we can just upload the new ones to let them coexist in parallel.

Thanks very much

[Arne Bier]

CRL downloads use http (TCP/80) and there is no transport security involved - therefore, no certs/SSL involved here.

I'm struggling to understand the issue - there is no danger whatsoever in installing the new Root CA and its new Intermediate CA certs - just be sure to tick the right boxes to ensure they are used for Endpoint auth.  On the Issuing CA certs, you can (or should) set the CRL URL manually, since ISE doesn't look in the client cert's CDP (CRL Distribution Point) to pick out the http URL - in the past, I noticed that it would pick the LDAP URL (if the CA is a Windows box) and then fail spectacularly. 

Also, are you sure that you want to perform an AD lookup of the user's cert, for each EAP-TLS authentication?   It's not technically required, and I don't know if you have read into the pros and cons of doing this - happy to be corrected on the merits of doing this. But generally, if ISE is performing the cryptographic checks for the cert's authentication, then the authentication is done (in my opinion) and needs no further checks - the Authorization can of course (and often is) performed by looking up the Identity in that cert (from the Subject CN or SAN) to query AD Group membership etc.

[117222400]

Hi Arne, 

Thanks very much for your reply. the issue.

My concern is:  

The Root CA certificate and Intermediate CA certificates in the ISE are the old ones, but the Root CA certificate has been renewed with the same key.  Should we upload the NEW Root CA certificate and the NEW Intermediate CA certificates to ISE ?

Right now, we didn't, and ISE worked well. Could we just wait until the old Root CA and Intermediate CA certificates expired then upload? 

We have Intune SCEP policy deployed to iPhones, it failed to request a new SCEP certificate because the certificate chain was broken. After we uploaded the new Root CA certificates, it works. This seems different from Cisco ISE EAP authentication, which seems didn't verify the entire chain. It seems if the old Root CA has the same key with the new one, ISE will still pass.

Another concern is: 

Seems in ISE 3.3 p4 ( we are in 3.2 now), it acts NOT the same as above. It will fail if the new Root CA was not uploaded. So if we need to update ISE, we might need to upload new Root CA and Intermediate CA first ?

I didn't find any article about this certificate authentication details in public, maybe only in Cisco's internal documentations.

Thanks again.

[Arne Bier]

I wouldn't know why 3.2 and 3.3 behave differently in the handling of the EAP System certificate. You should be ok to upload the new Root and Intermedia CAs and then test EAP auth. If it fails, it's quick enough to revert back.

One small trick for distributed deployments, would be to de-register one PSN node, and then when it's in Standalone Mode, perform your CA cert uploads there - that would ensure you only affect one PSN. If it works, then register the PSN back into the deployment.