ISE EAP Certificate with Alternate Certificate Chain

[andrewswanson]

Hi

I'm using a 3rd party signed certificate on ISE 3.2 patch 3 for EAP authentication.

This certificate has 2 Alternate Certificate Chains. ISE currently has the top path/chain installed in its Trusted Certificates store for chaining the EAP certificate to clients.

I'm in the process of configuring client supplicants to trust both root CAs as we move to switching to the lower, more secure path/chain.

I haven't added the lower path root CA to ISE yet. When I do, how does ISE react when its EAP certificate has 2 certificate chains in its Trusted Certificates store? Will it automatically use the shorter path/chain for EAP?

Thanks
Andy

[Arne Bier]

ISE only supports a single EAP System Certificate per PSN.  You cannot have multiple EAP System Certificates on the same node - as soon as you import (or create a CSR for a new EAP System Certificate) you will be told that it will replace the existing/current EAP cert. 

You can install as many Trusted CA certs in the Trusted Cert section in ISE. Which is useful if your endpoints (supplicants) have certs signed by a variety of CA cert chains.

So if you switch out your ISE EAP System cert with one signed by the shorter CA chain, then it simply means that your supplicants will receive that cert when they perform the TLS negotiation (during the "Server Hello" phase). If your supplicants have the CA Chain installed in their trust store, then they will have no trouble connecting to ISE for 802.1X

[andrewswanson]

Thanks for the reply Arne

I'm not replacing the ISE EAP certificate - the current one already has an alternate certificate path. ISE just has the longer chain of root/intermediate in its trusted store so this is the one chained to clients for EAP.

The question is, if ISE has an EAP certificate with 2 alternate certificate paths (and has both path's roots/intermediates in its trusted certificate store), which chain/path will ISE use to send to EAP clients?

Thanks
Andy

[Arne Bier]

Oh right - I hadn't grasped what was going on since I have never seen a client certificate with such a branched origin. I don't quite understand how this works, or why you would do such a thing?  It's certainly not what I see out in the field.  Is the EAP Server certificate cross-signed, or what is the technical principle used here?

My guess is that if whatever you are doing is standardised, the by adding the "bottom CA cert" into ISE will not break anything. You can click on the ISE EAP cert and view the cert in ISE - ISE will then display the trust path (CA's used). I would assume that this is the CA chain it would deliver during the TLS Server Hello.  

If you're unsure, then spin up an eval ISE node and install the "top row" CA certs and install the ISE EAP cert. Then, install the bottom CA cert and observe the results. You can also test the TLS with tools such as wpa_supplicant - this means you can test it all on a linux host without needing any networking gear.

I am keen to know how this dual-signed cert thing works - it's boggling my mind.

[andrewswanson]

Yes, the alternate certificate chain had me scratching my head when I first came across it.

The top path root CA is AAA Sectigo with the lower path root being UserTrust - they cover the alternate chain in this article:

https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots

I'll look at deploying an eval ISE and see how it reacts when both roots in the chain are present in the ISE Trusted store.

Thanks

Andy

[Arne Bier · Accepted solution]

@andrewswanson - very interesting. I searched around and found that this is not common, but it does happen with public CAs. e.g. this example with VeriSign. What I surmised from the author of the Verisign article, is that it may require you to edit the Client devices' Trusted Cert store settings to avoid choosing the wrong CA chain.  But it's unclear to me what ISE would return to the supplicant during the TLS Server Hello. A Wireshark analysis will be helpful.

Since you're in the (un)fortunate position to own one of these certs, you're also in the best position to test it out.  I am keen to know what you find. 

[andrewswanson]

I deployed an ISE eval (3.2 patch 6) and tested the chaining with a Windows 10 native supplicant - supplicant was configured for PEAP and to trust both roots in the alternate chain as well as to flag any issues with validating server identity.

Jus to clarify my previous post, the alternate chain of certificates (with issuers) is below. The "USERTrust RSA Certification Authority" certificates have the same cn (but have different issuers and serial numbers)

The first test was with ISE having the "top" chain of certificates in its trusted store:

• Packet capture showed ISE presenting the chain below to client:
• ISE Certificate
• GEANT OV RSA CA 4 (INTERMEDIATE)
• USERTrust RSA Certification Authority (INTERMEDIATE)
• AAA Certificate Services (ROOT)

Client passed 802.1x with no issues

The second test was to add the "USERTrust RSA Certification Authority" root to ISE. When I went to add it, ISE showed the following window:

When I clicked on yes, the "USERTrust RSA Certification Authority" root replaced the "USERTrust RSA Certification Authority" intermediate certificate in the ISE Trusted certificate store. When I tested the windows 802.1x client again:

• Packet capture showed ISE presenting the chain below to client:
• ISE Certificate
• GEANT OV RSA CA 4 (INTERMEDIATE)
• USERTrust RSA Certification Authority (ROOT)

Client passed 802.1x with no issues

So it looks like the best way forward is to:

• configure supplicants to support both roots in the chain
• replace the "USERTrust RSA Certification Authority" intermediate with the root on ISE

Thanks for your input Arne - much appreciated.
Andy

[Arne Bier]

Nice job @andrewswanson - nothing beats testing things in the lab!