CSR for guest portal

[Madura Malwatte]

If I need to generate a certificate for the guest portal for two psn's where I am not using a load balancer but rather the static ip/hostname option, where psn1 is guest1.company.com and psn2 is guest2.company.com, would the cert look something like this: ?

CN: guest.company.com

SAN: DNS - guest1.company.com, DNS - guest2.company.com

Would this work?

All my portal are on port 8443, so if I change the group tag of the hotspot guest portal to a new certificate, it seems this affects all portals on the same port. But I want my other internal portals on a different cert. Is the only option to change the port number on the hotspot portal to something else other than 8443?

[Francesco Molino]

Hi

For your CSR, yes you can do it like you said. Don’t forget to add the ip host command on ISE Cli to associate your PSN1 with guest1 fqdn and PSN2 with guest2 fqdn....

When you attach a certificate group tag, it will change it for all portals associated to the same port. You will need to change your port portal if you want to associate a different certificate.

Can I ask you what is your use case for this? 

Just to answer your statement regarding loadbalancer. You can associate your guest portal to a specific interface and do an anycast architecture which will allow you to have only 1 fqdn with 1 IP and based on your routing, users will attach to the closest server.

[Madura Malwatte]

Hi @Francesco Molino,

Thanks for the quick response. Is the CLI ip host config required? I have my authz policy to match "network access ISE Host name psn01" which has the matching authz profile with "Static IP/Host name/FQDN" to guest1.company.com which resolves to the same PSN. I have the matching config for psn02. I don't have a load balancer which is why I am using this option.

Use case is I have the CWA portal for BYOD, it is internal and hence using a different public cert for internal subdomain. While the hotspot portal is public facing only, and is in our normal domain. Hence why I am trying to use a public cert for portals in top level domain and another for the subdomain portals. Does this make sense?

When I go to generate a CSR, if I don't select the "allow wildcard certificates" option, mean I have to select the specific nodes. I select the two dmz psn's and this makes two separate CSR's, one for each node, even though my SAN DNS would covers both (guest1.company.com and guest2.company.com). As it generates two CSR's, it means I would need to pay for two certificates right? To do this in one certificate, do I need to select the"allow wildcard certificates" option? But this generates the CSR to my PAN node. This is okay yeh, I can import these into the dmz PSNs without issue?

[Arne Bier]

You should create one CSR - the Subject of the cert is ignored if the cert contains a SAN.  So here's the thing.  Create a cert with a Subject of guest.company.com (yes, that doesn't match either of your PSN's - doesn't matter) - then create two SAN's

DNS: guest1.company.com

DNS: guest2.company.com

This is a called a multi-domain cert and it's still cheaper than a wildcard.  Some providers allow up to 5 domains in the SAN

You can install that cert in the second PSN node and it will work, because the guest2.company is in the SAN!

Alternatively:  You can avoid exposing your PSN FQDN entirely!  This requires a bit more DNS work.  I have written about this before in other postings.  But essentially you configure a static FQDN on the portal - like guest.company.com.  It means that the URL redirect to the clients will be guest.company.com.  And then the cert just contains guest.company.com (which means you don't expose your internal PSN FQDN's!  They could be psn01.internal.net, and psn02.internal.net for example).

DNS comes into play.  You create a CNAME called guest.company.com that resolves to  two A records - psn01.whatever and psn02.whatever - these A records will contain the IP address of the PSNs.  The client browser always displays guest.company.com

One last thing about this method - in your MAB policies you need to create a rule that returns the appropriate URL for each respective PSN - because now guest.company.com no longer informs which PSN is processing the web redirect.  This has been discussed a few times on this forum. In my opinion it's the best way to do this because you can present a clean FQDN to the end clients' browsers.

cheers

Arne

[Madura Malwatte]

Hi @Arne Bier 

Thanks for the detailed response! It does sound like a nice way to do it, however I have some doubts:

So as you say, if we create a CNAME called guest.company.com that resolves to two A records - psn01.whatever and psn02.whatever. Wouldn't there be a situation where we authenticate and get the redirect from psn01 but the DNS resolves guest.company.com to psn02, and vice-versa? This is the situation we are trying to avoid by using:

authz policy "network access ISE Host name psn01" = Static IP/Host name/FQDN 'guest1.company.com" = psn01 ip address

authz policy "network access ISE Host name psn02" = Static IP/Host name/FQDN "guest2.company.com" = psn02 ip address

right ?

Also regarding the CSR, does it matter if I select "allow wildcard certificates" option? If so, it doesn't allow me to select the node, but lists the node as the PAN once the CSR is generated. If I don't select this option, then I have to specify the nodes (which are my two dmz psn's), and two CSR's are generated, one for each node I selected. From what it sounds I could still use only one of those CSR's to get signed and import them into both psn's?

[Jason Kunst]

Why not just do a wildcard in the SAN so you don’t need to worry about IP or static FQDN

CN=guest.yourdomain.com
SAN=guest.yourdomain.com
*.yourdomain.com

Called out here
https://www.networkworld.com/article/2225032/what-are-wildcard-certificates-and-how-do-i-use-them-with-ciscos-ise.html
https://www.cisco.com/c/en/us/td/docs/security/ise/2-2/admin_guide/b_ise_admin_guide_22/b_ise_admin_guide_22_chapter_0110.html

[Madura Malwatte]

Hi Jason,

We already have a wildcard for *.subdomain.company.com, but don't want to give details of the subdomain to the public and also for security reasons we can't use a wildcard for company.com. But yeh otherwise it would have been a lot easier.

[Arne Bier]

Hi @Madura Malwatte 

You spotted my mistake.  I should have referred to an earlier posting where I laid this out more detailed and correctly.

First of all about wildcard certs.  They are not cheap.  If money is not an issue then get those and be done with it.  But wildcard certs are not recommended if security is a concern - breach one box (i.e. private key compromised) and you have breached every system that uses that same wildcard. Maybe an academic point, but it is reality.  

Let's say you choose the multi-domain cert (cheaper than wildcard cert) - If you create the CSR don't tick wildcard.  Just create the CSR on one node.  Make sure the SAN contains the FQDN of both ISE nodes.  Once you have the cert bound to that one ISE node, you can export it, with the Private key of course.  Then import that same cert into node #2.  This is a common trick.   

Now back to the intent of my message.  I was muddling up two things: Guest and Sponsor/BYOD portals.

I meant to say:

1) if you already have PSN's with FQDN of say, ise01.internal.net and ise02.internal.net, and you want to present a guest portal, then you cannot of course create a cert with .internal.net (public CA doesn't allow it).  So the trick is to create two new A records

guest1.company.com

guest2.company.com

And then the next step is to create two portals - ideally make them identially looking.  In each portal you set the static FQDN to the respective FQDN above (i.e. guest1.company.com).

In the MAB Authorization rules check which PSN is processing the URL redirect and then return the appropriate portal URL.  That ensures that the PSN that is processing the MAB request gets to tell the client to come back it its portal (e.g. psn02 node waiting for guest on guest2.company,com)

The cert must contain SAN guest1.company.com and guest2.company.com and install on both PSNs.

If you have a load balancer (F5/nginx etc) then none of the above is required.  You can have one portal, call it guest.company.com and let the LB do the magic.  BTW, nginx is a nice alternative to the big iron of a commercial LB.

Why did I mention CNAME?  Because that was for another trick.  Things like sponsor.company.com, or mydevices.company.com - that is a URL that users need to type in.  You need one URL.  That is where the CNAME solves the problem.  It will resolve to either one of the PSN's, while still hiding the internal.net FQDNs.

Hope that clarifies.

[Madura Malwatte]

@Arne Bier 

excellent, thanks, this clarifies what I need to do for the multi-domain certs.

In regards to the guest portal, you mentioned "create two portals - ideally make them identially looking" - I think just one guest portal can be used in both the authorization policies. For Hotspot/self-register/sponsor portals there is no option to set the FQDN in the portal settings.

[Arne Bier]

@Madura Malwatte  - right again.  I did this a long time ago and I thought something didn't feel right.  Again, I mixed up Sponsor portal with its FQDN and the Guest Portal with the Authorization Result Profile "Static IP/Hostname/FQDN". Sorry to cause confusion.  It only requires one portal.   DOH!!!

I should have provided screenshots - see below - create two AuthZ Result Profiles - one per PSN

And the test in the MAB policy would look like this

[Francesco Molino]

You got some of your answers in other replies.

Wildcard certificate can be the solution but as stated by @Arne, they're expensive and can be a security issue if used on multiple systems. I mean it's quite sure you'll use it on many systems otherwise why paying for a wildcard.

Then, you create 1 csr associated to 1 psn and when the cert is binded, just export it (with its private key) and re-import it on the other node.
If you want to use the certificate on other portals, don't forget to add the other san I'm saying it because of you use other public facing portals on the same port, they'll use this same certificate.

Now creating different authorization profile by setting specific static fqdn and pushing them depending on the psn isn't something i like for scalability for example.
I prefer leaving ise managing it dynamically but to control the returned fqdn, you will need to add the ip host command. If you portal is binded on gig0 then go with your solution.
Personally, i always recommend to bind guest portal to a specific interface and setting up an anycast design to redirect users to closest server and to avoid playing with dns when this is another team managing'em.

[Madura Malwatte]

Yep, makes sense now. Thanks @Francesco Molino 

[Francesco Molino]

You’re welcome