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 Bier,

I have recently upgraded one deployment to v3.0 patch 3, and didn't faced any issues.

What I did faced in the past was behavior in which certificate is not applied properly, unless server is rebooted fully (application restart didn't helped). I faced this across different versions, so I adopted this as a must - whenever I replace certificate, I reboot servers, one at a time. I guess you already tried that as well?

BR,

Milos

[Arne Bier]

Hi Milos

I agree with the reboot option - I tried that earlier today but it didn't resolve the issue. This is ISE 3.0 patch 3

Are you saying that in your own scenario you have a different cert for Admin, versus the Portal cert? And in particular, the Admin cert is signed by a different CA than the Portal cert?  What interfaces are you using for your portal, and what TCP ports?

Perhaps something is not right in my config.

The ISE node has gig0 and gig1

Originally I tested with the Sponsor portal running on Gig1 - but I reverted to using Gig0. I want Sponsor Portal to use gig0 because it's a trusted network and sponsors are internal users. I think that's acceptable.

I want to use Gig1 for my Guest Portals. ISE wants me to use TCP/8446 and upwards for any portals on Gig1. I don't know whether I have confused the situation?   I would also assume that TCP ports are not shared across interfaces?  TCP/8446 on Gig0 should not clash with TCP/8446 on Gig1.

And also, I am not using the default (factory) Sponsor Portal - I create a new one from scratch. I assume that should also be allowed.

I have not tested the Guest Portal yet, since this requires someone on site to test.

I have configured my Sponsor Portal to use Gig0 and TCP/8446 (so that it doesn't clash with Sponsor portal on TCP/8445) - and rebooting.

If ISE is not happy with a TCP port configuration then it informs you on the GUI - therefore I assume everything I have done so far is allowed. 

I have the DigiCert Root CA and issuing CA in the ISE trusted certs. Rebooting again

[Arne Bier]

Reboot doesn't fix it

Even when I browse to https://sponsorportal.mycustomer.com:8445/ ISE will redirect to https://sponsorportal.mycustomer.com:8445/portal/  and then I get this error

Is it at all significant that I am using a wildcard certificate (wildcard in the Subject Common Name and SAN) ?

[Milos_Jovanovic]

Wildcards are allowed for sure, for both Sponsor and Guest. I've used it multiple times.

Looks to me like your sponsor portal is not provisioned correctly. To what node does your sponsorportal.mycustomer.com FQDN points?

BR,

Milos

[Arne Bier]

The FQDN resolves to the IP address of the PSN’s Gig0 interface. 

There are other PSNs in the deployment but I have been able to test the portal on them. The DNS only points to one PSN for the Sponsors Portal. For now anyway. 

[bhjortsberg]

Hi @Arne Bier 

Did you solve this? I'm experiencing exactly the same but on device portal.

Regards Brian

[Amine ZAKARIA]

Hi @Arne Bier ,

Did you try to access the sponsor portal with http instead of https or with https://fqdn:8445 ? still shows the Admin Cert or took you directly to the Digital Cert?

[Arne Bier]

@Amine ZAKARIA  -  when I try http://sponsor..../ it will redirect to the Admin cert (with browser cert warning).

When I go to https://sponsor ....:8445/ then it redirects to :8445/portals/ and tells me HTTP 404 Resource Not Found.

[Amine ZAKARIA]

@Arne Bier ,

When I go to https://sponsor ....:8445/ then it redirects to :8445/portals/ and tells me HTTP 404 Resource Not Found. Try to specify the whole URL-Redirect like https://ise1.ccie-security.com:8443/portal/gateway?sessionId=C0A82890000000170016724C&portal=50fbc805-6bde-4e28-8a3e-17750f938538&action=cwa&token=8aa306f5c74cd1414ada12ea2a4a201e  Does it work with Dig Cert ?

I found these bugs some of them same behavior as yours :

CSCut16630

CSCuw70713

CSCva84197

CSCve85686

[Milos_Jovanovic]

Hi Arne,

Based on your description, I don't see anything unusual. All of your requests are quite reasonable to me, and legit to be used, from my standpoint.

I'm using different certificates for Sponsor and Guest portals indeed. My Sponsor poratal certificate is actually my corporate CA issued cert, as it is meant for people who are employees and trust internal PKI. For Guest portal, I'm using public CA signed certificate, as here anyone can land. From this perspective, we are using same thing.

When it comes to multiple interfaces, I haven't used it this way, but, again, I don't see anything out of order here. This should be relevant only for connectivity, and you need to take care of routing, but, apart from that, everything else should be same.

Now, comming back to port configuration, I'm not convinced that system looks at interface looking at port binding, rather IP:Port combination. You can take a look at this by using 'tech netstat'. When I look at it, it looks to me that it is binding port to localhost address also, so this might be why there is a colision.

I think I remember, when using non-standard HTTP port (I belive it was 8442) for Client Provisioning Portal, that I faced similar behavior. I wanted to use dedicated certificate for this portal, but my conclusion was that ISE firstly defaults you to default TCP/443 port, in order to figure out that it should redirects you to different FQDN (I was using direct FQDN, something like sponsor.mydomain.com). Eventually, I ended up with same certificate on Admin/Sponsor/Portal, with multiple SANs, but this wasn't for Guest portal.

Perhaps somene from Cisco can explain this behavior in more details?

BR,

Milos

[Arne Bier]

Your setup is different to mine. I am using a Digicert cert for Sponsor Portal, and for Guest Portal. Admin portal using customers PKI. And you’re not getting the error because your admin and sponsor URLs hit the PKI cert. 

I think I need to switch to an internal FQDN for Sponsor Portal. 

[Mohammed al Baqari]

Hi,

I used DigiCert wildcard cert of admin/sponsor/guest portals. That is
working fine. What are you facing exactly?

**** please remember to rate useful posts

[Arne Bier]

Hi @Mohammed al Baqari - if you're fortunate enough to have Digicert for Admin/Sponsor/Guest, then you won't face the problem. I didn't build the ISE deployment, and the customer made the choice to build the deployment using a mydomain.local DNS domain, and hence the Admin certs were also provided by the internal PKI. 

If I had built that deployment I would not have involved the *.local domain at all - everything would have used the public CA (*.mycompany.com).

But - why does ISE provide a facility for an Admin cert, as well as Portal cert? Admin cert should be independent of portal usage, and that is my point. For some reason, the Sponsor portal redirection relies on (or is coupled with) the Admin cert. Or at least that is the behaviour I am seeing. 

[Arne Bier]

I think I found the answer in this old Community Posting.

Seems that HSTS is the "problem" and because the redirection is done on port 443 to 8445, ISE doesn't permit a redirection to an FQDN that is not included in the certificate - in my case I am using a wildcard cert for sponsor portal, and the SAN does NOT include portal.mycompany.com - it just has *.mycompany.com - and due to HSTS this will break.

What a pain. Something so simple made so complicated and not well documented.