ISE 3.0 Sponsor Portal Certificate - broken after all these years

[Arne Bier]

Hello

I found my own Community postings dating back to 2017 when I lamented about the broken nature of ISE's certificate handling for the Guest Sponsor Portal. It seems it's still broken in ISE 3.0 because I can't get it to work.

My Admin cert uses a PKI cert.

My Portals use a Digicert cert. And I assign that cert to Sponsor portal - but when I browse to the sponsor portal, the TLS connection terminates on the Admin cert - if I manually accept that, then I land on the Sponsor Portal and then only does it use the correct Digicert cert.  Have I done something wrong?   Sponsor Portal is on TCP/8445 and on Gig0 of the PSN. I also tried TCP/8443 but it didn't make a difference.

I have lost track of the many discussions about this in the past - I thought it all got sorted out.

I could potentially live with this issue for Sponsor Portal, but it's a show stopper for Guest portals. 

[Milos_Jovanovic]

Hi Arne,

Yes, mine setup is different. I was just throwing ideas and my experience, for someone to get some idea.

Thanks for posting your findings.

If I may ask - is there a reason you can't use internal PKI for Sponsor? It looks to me you could make an easy workaround on this if using internal PKI.

BR,

Milos

[Arne Bier]

Yup - the workaround we have in place is to add a SAN entry to the Admin cert and then to create a new Portal tag just for the Sponsor Portal. The issue with internal PKI is that Firefox doesn't trust those certs even if the Root CA chain is installed in the operating system. That's always been a pain. I believe that might change in future, but for now it's still an issue.

Long term solution would be to use a single cert that contains a long SAN list of all ISE nodes and all portals. That seems to be the no-brainer way of doing it. But for some customers this comes at a major cost, since certificates can be very expensive, especially if there is some enterprise agreement in place. In those cases the regular price of a cert is multiplied by 100! Go figure. How is this driving the adoption of certificates to make system safer? It's not. It's just an easy money grab. And all the more reason to use services like Letsencrypt. 

[Milos_Jovanovic]

Regarding Firefox, from certain point, they made it possible to use Windows native credentials store, by doing some tweaking. Please take a look at this. This will enable your Firefox browser to trust everything defined as trusted on Windows (I don't have much experience with Mac). Firefox also became more corporate-friendly, and, again from certain point, it is possible to manage certain configuration via GPO, so you could actually do this silently. I managed to find this post for this particular action, but there might be some more/easier options.

Regarding public CA, I believe it is not possible to purchase this kind of certificates for internal domains (such as .internal or .local).

BR,

Milos

[Ideal Networks]

@Arne Bier Thank you for sharing this experience, we have run into the same issue with Digicert, unfortunately we are only using a self signed cert for admin access, note comments that the SAN for the sponsor portal needs to be added to certificate used for admin access, do you think its possible to regenerate the self signed certficate, but define the sponsor porta;l SAN there, instead of getting a CA to sign both admin and portal certificates?

Our ISE deployment is using an FQDN that isnt publically resolvable (eg: ise.corp.local) so we cannot generate a multi-use certificate to be signed by a public CA.

Edit: Ignore comment regarding self signed cert, tried it, but didnt work

[Arne Bier]

Sometimes it makes sense to deploy internal-facing IT systems (like ISE) using a DNS domain that is publicly visible. It doesn't mean that your ISE nodes must get public IP addresses. If you have a mycompany.com domain, then your internal DNS servers will resolve ise01.mycompany.com to your private RFC1918 address. But there will be no ise01.mycompany.com DNS A record on the internet. But, now you have a FQDN in a cert that you can submit to a public CA for domain verification - and it will pass  

[Arne Bier]

Hi @bhjortsberg 

Nope. I gave up in the end, even with ISE 3.2 patch 3 at the time. My solution was to use one certificate for Admin and Sponsor Portal - basically, just added another DNS SAN entry to the existing ISE nodes' Admin cert.  It is what it is - I will consider this is how the product works and use that method in future. Luckily the Sponsor Portal uses the same DNS domain as the Admin Portal - I think that's possibly a common situation - there is no need for the Sponsor Portal to use a public CA.