CSCut26025 - Doc. ISE certificate chain is not being send till services restarted - not resolved in ISE 2.4 Patch 8

[randomuser]

Hi all,

today I installed Patch 8 on ISE 2.4 over Patch 6. After updating to Patch 8 the Certificate (chain) configured for guest portal with Comodo RSA Domain Validation Secure Server CA certificate was not shown anymore to the client (affected Clients are different Android Devices, Windows 10 Workstations with Chrome or Opera Browser). Even testing via openssl to verify the certificate chain results in failure in the chain (openssl result: "unable to get local issuer certificate").
We did a lot of testing with different certificates (root and/or intermediate) and certificate chains (also refered: https://community.cisco.com/t5/policy-and-access/guest-portal-url-certificate-issue-ise-2-3/td-p/3403241) and tried the workaround from CSCut26025, but this did not resolve the issue.

Then we decided to rollback to Patch 6 and everything works again as expected. The certificate chain was provided/shown through the ISE again.

Did not test with Patch 7 because we directly updated from Patch 6 to 8.

Any ideas or information when Patch 9 will be available and if this is fixed again?

Thanks in advance.

Regards

[CarlCarlson1234]

I had the same issue this week, TAC pointed me to CSCvp75207.  I added trust for certificate based admin authentication for both certs in our chain, rebooted the server (standalone lab) and my portals started sending the full chain.

This is from the 2.4 admin guide, so they added a cert feature in patch 8 that might be a side effect of.

"If you plan to use any sub-CA certificate in the certificate chain for EAP authentication or certificate-based administrator authentication, ensure that you check the Trust for client authentication and Syslog checkbox while importing all the certificates in the certificate chain up until the Root CA. Starting Cisco ISE 2.4 patch 8 and above, you can import more than one CA certificate with the same subject name. For certificate-based administrator authentication, select the checkbox Trust for certificate based admin authentication when adding a trusted certificate."

[randomuser]

Thanks for your reply.

But the CSCvp75207 refers to ISE System Certificate, which are also used for EAP. In my case these are public signed certificates (i.e. Comondo) used to serve the Guest Portal.

Here I have a more insecure feeling of safety to check the boxes to "Trust for authentication within ISE" and "Trust for client authentication and Syslog" (also stated in CSCut26025), because this are public CAs, not internal).

Regards

[CarlCarlson1234]

ISE system certificates can be used for Admin, EAP, RADIUS DTLS, pxGrid, SAML, or Portal.  Portal includes your guest portal certificate, it is a system certificate.  Even if it is publicly signed.

[randomuser]

My initial discussion/post was just about the guest portal, where the chain is not provided through ISE with public signed certificate(s).

For visitors/third parties people not belonging to the company the guest portal should (is) configured with an public trusted certificate. To allow a public certificate to be allowed for client auth, syslog, and so on is not common or secure I think.

With internal system certificates (used for company own/internal portals) where you have the "issue", the provided solutions/workarounds would be fine, but not to use for public ones.

Edit: or did I misunderstood something? 

Regards

[CarlCarlson1234]

My issue was with my guest portal. Our guest portal certificate is signed by a public ca. The guest portal was sending it's certificate to external endpoints and not the entire cert chain (the public root and intermediate). This was causing the endpoints to not trust the https connection to our guest portal.

The portal certificate is installed under the system certificates, (Administration, system, certificates, certificate management, system certificates) and the "Use by" is set to portal the "Portal Group" tag is guest portal.

The public root and intermediate certs, that my guest portal chains to for external clients to build a trust with, are installed under trusted certificates. Then the guest portal itself (work centers, Guest access, portals, guest portal) is set to use the certificate group tag, guest portal. This builds the connection within ISE between the guest portal and the certificate I want the guest portal to present to external clients.

I agree that selecting the boxes for auth within ise, client auth and syslog, and admin based auth is not ideal and I would think not intended by Cisco. However, it just allows those root certs for those purposes it doesn't necessarily enable them. For example if you don't have cert based admin authentication enabled under admin access then ISE won't accept a cert for that purpose anyway.

EAP could be a concern, but if you have the correct client cert validations in your authc policies then a cert presented to ISE for EAP using the same root ca would be denied.

Anyway, all I'm saying is it fixed the issue for me, we could debate security implications all day.

[randomuser]

Thank you very much for your answer. I agree with you and you describe it very well.

Unfortunately the given workaround did not work for me. Possibly this is also related to the issuer 🤷‍♂️(and is treated differently by ISE).

But I think the behavior should be changed or corrected by Cisco, because I find this quite confusing (and give me security concerns).

Selecting the boxes for auth within ise, client auth and syslog, and admin based auth or interception or "correcting" by the policy should not be the goal.

..."we could debate security implications all day"....agree totally ;-)

Regards

[randomuser]

Did you also check via openssl? i.e.  .\openssl.exe s_client -showcerts -connect website.domain.name:port

I performed all steps after each other from the workaround stated in CSCut26025, with the same result.

The issue is not with Windows Clients (using either Firefox, Chrome, Edge Chromium, Chrome) or Apple iPhone for example, but with Android Devices.

Windows Devices trust the chain, even if the chain is not send properly. Android Devices gave me the same as openssl shows up:  Verify return code: 21 (unable to verify the first certificate).

I tested witch certificates signed by Comodo for one webserver and the other one was with a wildcard certificate even in Version 2.6 Patch 1. 

Regards

[randomuser]

Patch 9 has been released. Has anyone tested this yet? Unfortunately I could not test this yet.

[hslai]

CSCvp75207 is due to another bug fix in ISE 2.4 Patch 8 but NOT resolved in ISE 2.4 Patch 9.

However, the issue documented by CSCut26025 is not related at all to CSCvp75207.

[randomuser]

Thanks for your reply. Through the circumstances we decided to wait for 2.4 Patch 10 and also in Version 2.6 for Patch 2 before installing an other Patch than Patch 6 for ISE 2.4 or ISE 2.6 without Patch ;-)

[rchockeelopez]

Patch 10 is already release. Have you test it with patch 10?
I have the same issue with comodo certificates.

[rchockeelopez]

Hi,

2.4 Patch 10 has already launched. Have you test it ?

I have the same issue with comodo certificates with 2.4 patch 9.

[CarlCarlson1234]

I've not tested it yet, but CSCvp75207 is specifically called as being resolved by patch 10. So it should be fixed in 2.4 patch 10.

[randomuser]

I have updated the environment to patch 10 and tests also with openssl (see above) were successful. Now only patch 3 of version 2.6, which is also affected, is missing ;-)

Regards