03-14-2024 04:13 AM - edited 03-14-2024 06:47 AM
I have almost completed the build of the 3.2, what I observe is the following:
- in 2.7, the "Sponsor portal URL" is the classic 443 (the link that ISE offers to quickly check it out), in the setup page TCP 9445 is specified. Hence ISE sends the client a redirect from 445 to 9445; and indeed the client is offered the same certificate when the client it connects to 443 and 9445;
- in 3.2, the settings are the same (have been imported from 2.7) but when connecting to the port 443, the clients gets the cert signed by the internal CA, not the public one.
I don't see any specific option to attach a cert to the socket 443, neither in 2.7 nor in 3.2. I may assume that in 2.7 is automatic, but in 3.2 this automatism is brokem.
[EDIT]
In another words, the URL proposed by Cisco ISE doesn't include the port. Is that normal? Where do I configure the redirection and the certificate associate to the first socket?
Would you have any experience/idea to share for this issue?
TIa, Gio
Solved! Go to Solution.
03-14-2024 03:14 PM
This is expected behaviour for the Sponsor portal redirect. See https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut16630
The workaround is to include the Sponsor portal FQDN in the SAN of the Admin certificate as suggested in the How To Implement Digital Certificates in ISE
03-14-2024 09:05 AM
Sorry I found this explanation in 2.7, not in 3.2.
I fear this is linked to the following: but I don't know how to interpret it.
-----------------------------------------------------------------------------------------------------
The navigation path for these settings is Work Centers > Guest Access > Portals & Components > Guest Portals > Create, Edit or Duplicate > Portal Behavior and Flow Settings > Portal Settings.
HTTPS Port: Enter a port value between 8000 to 8999; the default value is 8443 for all the default portals, except the Blacklist Portal, which is 8444. If you upgraded with port values outside this range, they are honored until you modify this window. If you modify this window, update the port setting to comply with this restriction.
If you assign ports used by a non-guest (such as My Devices) portal to a guest portal, an error message appears.
For posture assessments and remediation only, the Client Provisioning portal also uses ports 8905 and 8909. Otherwise, it uses the same ports assigned to the Guest portal.
Portals assigned to the same HTTPS port can use the same Gigabit Ethernet interface or another interface. If they use the same port and interface combination, they must use the same certificate group tag. For example:
Valid combinations include, using the Sponsor portal as an example:
Sponsor portal: Port 8443, Interface 0, Certificate tag A and My Devices portal: Port 8443, Interface 0, Certificate group A.
Sponsor portal: Port 8443, Interface 0, Certificate group A and My Devices portal: Port 8445, Interface 0, Certificate group B.
Sponsor portal: Port 8444, Interface 1, Certificate group A and Blacklist portal: Port 8444, Interface 0, Certificate group B.
Invalid combinations include:
Sponsor portal: Port 8443, Interface 0, Certificate group A and My Devices portal: 8443, Interface 0, Certificate group B.
Sponsor portal: Port 8444, Interface 0, Certificate tag A and Blacklist portal: Port 8444, Interface 0, Certificate group A.
Note | We recommend that you use interface 0 for Guest services for best performance. You can either configure only interface 0 in the Portal Settings, or you can use the CLI command ip host to map a hostname or FQDN to the IP address of interface 0. |
-----------------------------------------------------------------------------------------------------
03-14-2024 03:14 PM
This is expected behaviour for the Sponsor portal redirect. See https://bst.cloudapps.cisco.com/bugsearch/bug/CSCut16630
The workaround is to include the Sponsor portal FQDN in the SAN of the Admin certificate as suggested in the How To Implement Digital Certificates in ISE
03-19-2024 01:45 AM
Thanks @Greg Gibbs , your reference helps.
There is still one small question that I would like to verify.
"In another words, the URL proposed by Cisco ISE doesn't include the port. Is that normal? Where do I configure the redirection and the certificate associate to the first socket?"
In short whoch URL is Cisco ISE supposed to show in the link to the Sponsor portal?
1) https://FQDN?
2) https://FQDN:<port> ?
3) https://FQDN:<port>/<path_with_portal_id>?
Mine shows just 1), making my colleagues think it's normal to give people just the FQDN and then they are redirected.
I apologize if this discussion sounds moot points but I'd like to know what's for ISE the right way to work. Also if put behind a firewall this leads to the choice of blocking access to the port 443.
TIA, Gio
03-19-2024 02:43 PM
The 'friendly' FQDN is configured on the Sponsor portal and ISE uses that to determine which portal ID to direct the user to. That is how ISE supports multiple portals.
Example:
This is essentially the flow used for direct access portals (like the Sponsor portal) with ISE. The initial redirection to port 443 is the the reason ISE initially presents the Admin certificate; hence the error if the Admin cert does not include the portal FQDN in the SAN.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide