ISE default trusted CA certificates

[Johannes Luther]

Hi all,

in ISE 2.4 i see the following enabled default CA certificates in the trusted store for infrastructure and endpoint trust:

Root: Cisco Root CA M2 / Intermediate: Cisco Manufacturing CA SHA2

Root: DigiCert root CA / Intermediate: DigiCert SHA2 High Assurance Server CA

I don't quite get why these CAs are preinstalled for infrastructure and client trust. These CAs are not mentioned in any ISE guide I found.

If you don't build your EAP-TLS authorization rules very carefully (e.g. not checking the issuer CN or doing an additional AD lookup), client certificates signed by these CAs are allowed to access the network. (certificate based authentication will pass / it all depends on the authorization).

Are the CAs there by intention (because we're doing intention-based networking >:) ). If yes, what is the purpose?

[Arne Bier]

that's an interesting observation about the Digicert CA certs.  Yes it could cause a backdoor into ISE if not careful.  Might be worth deleting these certs - they serve no purpose.

[Johannes Luther]

Hi again Arne (obviously the ISE world is kinda' small) :)

>> Might be worth deleting these certs - they serve no purpose.

I'm assuming this as well, but I'm quite unsure... Before I delete them in a big production environment, I want to understand the purpose (or the itention :) )

Perhaps anyone from Cisco stumbles upon this... Otherwise I guess I'll have to open a TAC case.

[hslai · Accepted solution]

The DigiCert CA certificate pair are actually used for Guest Social Login Flow with FaceBook. The trust settings are those for the protocol runtime. You may disable/delete them if not using such flow in your deployment.

Sorry for wrong info, earlier.

[hslai]

---

Root: Cisco Root CA M2 / Intermediate: Cisco Manufacturing CA SHA2

This is there for your convenience to use cert-based auth for Cisco devices, such as Cisco APs and Cisco IP phones. You may disable or delete them if you have no Cisco devices performing EAP-TLS against ISE.

Root: DigiCert root CA / Intermediate: DigiCert SHA2 High Assurance Server CA

---

 Earlier on, this was the root CA certificate for www.cisco.com in some region and needed for ISE feed services. With

Field Notice: FN - 70122 - Cisco Identity Services Engine – Posture and BYOD Package Updates Will Fail Without ISE Trust Store Update to New HydrantID Root Certificates - Software Upgrade Recommended - Cisco, I do not think ISE still needing it. You may double check the certificate chain of https://www.cisco.com in your region.

[Johannes Luther]

Hey hslai,

thanks for the feedback!

---

@hslai wrote:

---

Root: Cisco Root CA M2 / Intermediate: Cisco Manufacturing CA SHA2

This is there for your convenience to use cert-based auth for Cisco devices, such as Cisco APs and Cisco IP phones. You may disable or delete them if you have no Cisco devices performing EAP-TLS against ISE.

---

Ok - got that. Except the point with the APs ... the lightweight APs are only capable of performing EAP-FAST using credentials if acting as an 802.1X supplicant. For the phones - I don't know.

Root: DigiCert root CA / Intermediate: DigiCert SHA2 High Assurance Server CA

---

 Earlier on, this was the root CA certificate for www.cisco.com in some region and needed for ISE feed services. 

---

I might be wrong, but then the "trusted for" settings are incorrect. For feed service the "trusted for" purpose must be set to "Cisco services" - correct? Furthermore the field notice is referring to another CA....

[hslai · Accepted solution]

I am probably wrong in assuming Cisco AP using the manufacturing CA, but potentially anything made by Cisco could use the same chain. Newer Cisco APs appear capable of such. See 802.1X EAP Supplicant on COS AP - Cisco

---

I might be wrong, but then the "trusted for" settings are incorrect. For feed service the "trusted for" purpose must be set to "Cisco services" - correct? Furthermore the field notice is referring to another CA....

---

Correct. For ISE Feed Services, the option "Trust for authentication of Cisco Services" is what required, so we may disable the other options unless the same certificate chain used for other purposes.

As to the field notice about another CA used for the feed services, that is correct as well and that is the reason why the DigiCert one likely no longer used.

[Johannes Luther]

Hello Hslai,

thank you for the very detailed answer! I didn't know, that the newer Cisco APs supplicant support EAP-TLS (well, the 8.7 release is kinda new) :)

So for now I'll disable those CA certificates. Thanks again!