ISE 2.0 TLS Cert Chaining?

[Toivo Voll]

We have an ISE 2.0.1 install, and are running into an issue with cert chaining. Specifically, for the web interface, ISE only provides the system cert, and not the rest of the cert chain.

We have an enterprise CA and associated root cert, and then an intermediate CA, and associated cert, signed by the enterprise root. I've generated (via openssl) a key and cert signing request, and they've been signed by the intermediate CA.

Both the root and the intermediate CA are in the Trusted Certificates, trusted for Infrastructure and Endpoints, valid life times, and all that.

I've imported the signed cert and private key into system certificates, and everything looks a-ok. It's trusted for Admin and EAP auth.

However, some browsers, notably Firefox, completely refuse to allow connections to ISE after this; there's not even an advanced option to bypass the error. It appears that while ISE during the TLS negotiation offers the system cert, it does not provide the rest of the cert chain. I've been trying to figure out where this is configured or documented, but haven't been successful. In the past on other web servers we've always had a way to tell the server to provide the server cert and any required intermediate certs.

Any hints, help, or pointers?

SOLVED

User error. Turns out that our organization had for some reason released a new intermediate CA cert, with the same issuer and subject names. Both certs had lifetimes well into the next decade. Once I used the correct intermediate cert, everything worked like a dream. This was still pretty challenging, as nothing clearly indicated what the problem was and why the server cert wouldn't chain.

For future use, here's a handy OpenSSL command to verify the chain and the certs being sent. You can skip the -CAfile option if your trusted root CA is in the OpenSSL search path.

openssl s_client -connect <ISE APPLIANCE>:443 -CAfile <YOUR-ROOT-CA-FILE> –showcerts

[Marvin Rhoads]

If the client does not trust the root CA (by having it in the local store) I don't think ISE can make it do so even if it provides the entire chain back to root. Typically when we have an enterprise CA we push out trust of the enterprise root CA via GPO, SCCM or other software deployment method apart from ISE.

PKI is fundamentally based on mutual trust of a common root CA (or set of roots). If a given server could assert the entire chain and be accepted by a client, then there would be no need for public trusted CAs.

[Toivo Voll]

The client has the root CA in the local store, but not necessarily the intermediate. A typical Apache install would provide the server cert and the intermediate cert, and the client would trust it. From what I've read, ISE is supposed to figure it out on its own and do the same, but it doesn't appear to, and I haven't found good documentation.

[jan.nielsen]

I have had issues in the past, where the order in which the root/intermediate/identity cert is installed, caused ise to not update the chain which it sends. There is no setting to tell ISE to use specific certs for the chain it sends to the client, this is supposed to happen automatically. The last time i had this issue a reboot of the ISE node solved the problem. One other time, i had to reinstall the root/issuing ca to get it working.

[Toivo Voll]

Huh, interesting. I went ahead and power-cycled the appliance (instead of just letting the application restart), and now ISE is returning the expected certificate chain in the negotiation (as per openssl s_client), but is still not presenting the expected intermediate cert.

So it went from:

---
Certificate chain
 0 s:/C=US/ST=Florida/L=Tampa/O=<REDACTED>/OU=<REDACTED>/CN=<ISE APPLIANCE>
   i:/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/CN=<INTERMEDIATE CA>
---

to

---
Certificate chain
 0 s:/C=US/ST=Florida/L=Tampa/O=<REDACTED>/OU=<REDACTED>/CN=<ISE APPLIANCE>
   i:/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/CN=<INTERMEDIATE CA>
 1 s:/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/DC=<REDACTED>/CN=<INTERMEDIATE CA>
   i:/CN=<ROOT CA>
 2 s:/CN=<ROOT CA>
   i:/CN=<ROOT CA>
---

where the i->s  i->s and i->s all match and chain, including all the DC and CN entries.

...but Firefox still refuses to allow connections to it at all.

I should mention that under System Certificates, when I view the cert cert, it has a red X and "Certificate trust chain is incomplete" message.

[Toivo Voll]

User error. Turns out that our organization had for some reason released a new intermediate CA cert, with the same issuer and subject names. Both certs had lifetimes well into the next decade. Once I used the correct intermediate cert, everything worked like a dream. This was still pretty challenging, as nothing clearly indicated what the problem was and why the server cert wouldn't chain.

For future use, here's a handy OpenSSL command to verify the chain and the certs being sent. You can skip the -CAfile option if your trusted root CA is in the OpenSSL search path.

openssl s_client -connect <ISE APPLIANCE>:443 -CAfile <YOUR-ROOT-CA-FILE> –showcerts