ISE guest portal certficate query

[Brett Verney]

Hi all,

I have just rolled out ISE 2.0 in a distributed deployment with 2 nodes for a guest wireless network utilising the Sponsor Portal. I am about to generate a CSR for the client's public CA to sign and I want to use a single certificate for both nodes, however the client does not permit wildcard certificates. I believe ISE 2.0 requires a wildcard entry in the SAN field to deploy to both nodes, otherwise two CSRs are required. Is there any way around this? Two certs with multiple SAN entries can get pretty expensive.

Can I use a tool like OpenSSL to generate a single CSR and put both FQDNs in the SAN field? Will ISE allow me to import the one certificate to both nodes and assign to the 'Portal' function?

The environment contains the following:

ISE1.localdomain (primary admin, secondary monitoring, PSN)

ISE2.localdomain (secondary admin, primary monitoring, PSN)

guestportal.publicdomain (guest portal URL that clients are redirected to)

.

Is the CSR below correct for this deployment?

CN=ISE1.localdomain

SAN

DNS = ISE1.localdomain

DNS = ISE2.localdomain

DNS = guestportal.publicdomain

.

Unfortunately I need to get this right before the CSR is sent to the CA, so if somebody could help confirm all this it would be greatly appreciated!

-Brett

[Brett Verney]

I have been advised that the above is possible, and can also be done via the following;

CN=guestportal.publicdomain

SAN

DNS = ISE1.localdomain

DNS = ISE2.localdomain

DNS = guestportal.publicdomain

The certificate will be rejected upon import if each of the PSN nodes' FQDNs aren't present in either the SAN or CN. This makes it expensive when signing with certain public CAs. I would have thought a CSR could be generated with 'CN=guestportal.publicdomain' (no SAN entries) and installed on each node to make it cheaper, but this is not the case.

-Brett

[nspasov]

I believe the above example will only work for EAP based certificates but will NOT work for HTTPs based certificates. This was clearly outlined in ISE 1.2 documentation:

If you are going to use the CA-signed certificate for HTTPS, the subject Common Name value specified for the CSR must match the fully qualified domain name (FQDN) of the Cisco ISE node, or must match the wildcard domain name specified in the SAN/CN field of the certificate.

However, this restriction is not listed in 1.3,1.4 nor 2.0 so I wonder if the limitation has been removed. Have you actually tried this?

Thank you for rating helpful posts!

[Brett Verney]

Hi Neno,

The ISE 2.0 Admin guide states:

1 - Cisco ISE looks at the subject alternative name (SAN) extension of the certificate. If the SAN contains one or more DNS names, then one of the DNS names must match the FQDN of the Cisco ISE node. If a wildcard certificate is used, then the wildcard domain name must match the domain in the Cisco ISE node’s FQDN.

2 - If there are no DNS names in the SAN, or if the SAN is missing entirely, then the Common Name (CN) in the Subject field of the certificate or the wildcard domain in the Subject field of the certificate must match the FQDN of the node.

3 - If no match is found, the certificate is rejected.

From what I have been told, those requirements only applied up to v1.2. HTTPS requests will now look for a match in the SAN, before they look at the CN. However the value in the CN, also has to be present in the SAN.

I am yet to try this... The project has been put on hold until after the Christmas break. I will let you know how it goes.

Brett

[nspasov]

Hi Brett-

Yes, I saw this in the documentation but it is only referring to Wildcard type certificates and not just a standard SAN certificate. Perhaps it is just a documentation issue but still something that should be tested :)

I don't have any ISE work lined up in the near future so I can't test this immediately so please keep us posted. 

As you probably had already seen I posted the question in the "Ask the Expert Thread" :)

Thank you for rating helpful posts!

[Brett Verney]

Hi Neno,

I'm so sorry, I missed your reply to the 'Ask the Expert Thread'. I've just read it now... thanks for that!

I'm still trying to understand why this is not recommended. In fact it has just created more confusion. A colleague of mine has suggested that he always generates a single cert via OpenSSL in order to get around the two cert (or wildcard cert) limitation.

We'll just have to wait and see!

Thanks again

[Antonio Macia]

Very interesting post Brett and thanks for sharing your solution.

There is something I don't understand then because, if we use a certificate where the CN and the SAN matches the public URL, when the PSN replies using its internal FQDN, the browser will show a warning since it does not match the public CN or SAN of the certificate. 

What I'm missing?

[Brett Verney]

Hi Antonio,

You can modify the URL that the client is redirected to in the Authorization Profile specified in your Authorization policies. This is under CWA - Static IP/FQDN within the profile (off the top of my head). You will also need a matching DNS entry so clients redirect to the correct IP address. Otherwise ISE will redirect clients to the FQDN that you used to build the appliance on by default.

However If you have multiple PSNs, modifying the URL does not work without putting the appliances behind a load balancer of some kind. Long story short, the dynamic redirection mechanism is broken

I only modify the FQDNs in the Authorization Profile when using a single PSN. Otherwise with multiple PSNs most of my customers are happy to redirect clients to the default FQDN (sometimes it is a public domain anyway).

Please let me know if you need any more info.

-Brett

[Antonio Macia]

Thanks for the quick response.

In my case the deployment will have multiple PSN and it's load balanced. 

The idea is to keep the hostnames using internal domains and let the guests reach the PSN directly for CWA. 

I've read another alternatives using the "ip host" command to map FQDN to IP addresses on different interfaces other than Gi0, but in my deployment I will have a single bond for all the services. Moreover, this looks more a workaround than a final solution.

Any ideas?

[Brett Verney]

I see your documentation bug has finally been opened. Nice work :)

https://tools.cisco.com/bugsearch/bug/CSCux66343/?reffering_site=dumpcr

[nspasov]

did you get around to test this?

[Brett Verney]

Hi Neno,

I finally got to test this today. Although the client's public CA didn't allow the '.localdomain' in the SAN field. They instead chose to use a get a SAN certificate signed with the following details for the guestportal;

CN=guestportal.publicdomain

SAN

DNS = guestportal.publicdomain

This CSR was generated by OpenSSL and was able to be imported to both ISE nodes.

The Admin and Sponsor Portals on the 'localdomain' used a certificate and was signed by the internal CA.

So it seems OpenSSL is a suitable solution in cases where wildcard certificates are not available or supported. This includes HTTPS/portal purposes.

-Brett

[nspasov]

Hi Brett! Thank you for the update here (+5 from me). A couple of questions:

1. The above certificate is attached to the HTTPs/Portal on your ISE deployment?

2. Were you able to install it on all of your ISE nodes

3. Do you have a wildcard value in any of your SAN fields

Thanks in advance!

Thank you for rating helpful posts!

[Brett Verney]

Hi Neno,

1. The above cert was attached to the Guest Portal only (using 'group tags'). Certiticates for Admin/Sponsor Portals were signed by the client's internal CA.

2. Yes. ISE allowed me to install the same cert on both nodes. It does not know that the same certificate is being uploaded twice.

3. No wildcard (*) characters in the SAN field in this deployment, however I have since deployed ISE at another client site, and successfully uploaded a SAN cert (with wildcard character in one of the SAN entries). All OK.

So it seems the only way to get around a CA signing multiple CSRs (additional cost) without using a wlidcard cert is to use OpenSSL. Be sure to generate a 2048 bit key file with a SHA-256 signature at a minimum.

-Brett

[Pranav Mhatre]

Hi Brett,

Did u come across any Cisco document. Which I can refer to configure guest policy in ise with below requirement -

1. 2 psns will be used for guest settings for redundancy.

2. 1 to many nat - 1 public IP to 2 private iOS.

3. Public CA 

4. DNS changes