cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2783
Views
0
Helpful
13
Replies

Guest Portal Certificate Conundrum

scsc_tech
Level 1
Level 1

So we have our guest portal successfully working, but its using a self signed cert that is causing issues with some clients being able to join (browser cert restrictions)

I updated the portal certificate to a DigiCert publicly signed cert. I thought this would work great, but then realized the guests were hitting the IP of ISE to authenticate. The IP address is not in the SAN of the cert, and Digicert wont let me add an IP SAN.

So then I thought to change the portal URL to be a DNS name rather than IP, but ran into another issue that the guests are using public Umbrella DNS servers and not our internal DNS servers, so the address does not resolve.

 

Im not sure how to fix this issue now. I appear to be in a catch 22.

1 Accepted Solution

Accepted Solutions

Jason Kunst
Cisco Employee
Cisco Employee
The easiest route is to do a wildcard in the SAN.

Please check the certificate information in the Prescriptive guest guide on https://cs.co/ise-guest community pages for more information

View solution in original post

13 Replies 13

Mike.Cifelli
VIP Alumni
VIP Alumni
Do you have an internal PKI that you could get a certificate from? If not, you could always use the internal ISE CA to issue a certificate for you guest portal. I would recommend checking this out: https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_0111.html#concept_C0EDF372974E459CA8E4A14389853525

We dont have PKI

Using the internal ISE CA would still present an untrusted cert to the end user, no?

Yes i wouldn't recommend that at all for a guest portal or any user device facing portals at all unless they are in a corporate domain and you can push the internal chain to the endpoints before hand (useful for posture, sponsor, my devices, certificate provisioning type portals but not for guest or BYOD)

Jason Kunst
Cisco Employee
Cisco Employee
The easiest route is to do a wildcard in the SAN.

Please check the certificate information in the Prescriptive guest guide on https://cs.co/ise-guest community pages for more information

Our digicert SSL is a wildcard cert.
The issue is the guests navigate to the IP address of ISE when they authenticate to the portal.

OK don't have them do that? why is that necessary? You can have them go to enroll.cisco.com or any http site

We have a self-registration redirect. When someone joins our guest network, it redirects them to the self-registration portal that is hosted on ISE. The redirect takes them to an internal IP of ISE because they only have access to public DNS servers, thus cant use the FQDN of ISE.

You will need to get the IP in the cert or get your DNS to resolve.

Here is a thread on your issue https://community.cisco.com/t5/identity-services-engine-ise/ise-guest-dns/td-p/3734037
, there might be some others as well

Hi @scsc_tech 

 

I would like to see your Authorization Profile that is used for the re-direction - why the heck would that include an IP address?  Portal URL's should never include an IP address.

In the ISE Authorization Profile, either state the Static FQDN, or leave that field blank, and then ISE will auto-populate with the PSN node's FQDN on the CLI.

 

There's all sorts of shenanigans should can do with DNS etc - but let's check the AuthZ Profile first.

 

regards

Arne

Access Type = ACCESS_ACCEPT
cisco-av-pair = url-redirect-acl=DNAC_ACL_WEBAUTH_REDIRECT
cisco-av-pair = url-redirect=https://10.200.254.11:port/portal/gateway?sessionId=SessionIdValue&portal=5a386de2-15f1-11e9-8d48-b08bcf6d2bcc&daysToExpiry=value&action=cwa

 

Again, the reason for the IP is that we don't have a private DNS server exposed to the guest VN.

 

I ended up giving guest vn access to our internal DNS servers. Solved the issue.

Right, now I get it.  The DHCP server was handing out some public DNS server (like OpenDNS) and therefore you had to hard code the ISE IP address into the URL.  That's nasty.  

So you ended up doing what pretty much every one else does, which is to allow guests to use the internal DNS server.  Nothing too wrong with that.  In that case you may as well put the FQDN into the URL Authorization Profile (as long as that FQDN lives in the cert (preferably in the Subject Alternative Name as   DNS: <FQDN>)

The ideal case is to either

  • Use the DNS/DHCP server of the ISE PSN (very cool if your design allows it) or
  • Use a separate DNS server that only resolves the IP of two PSN FQDNs, and conditionally forwards everything else to an external public facing DNS server

We are using a Cisco Umbrella DNS relay internally, so it decides whether to query our internal DNS servers or public based on domain.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: