ISE 3.0 Sponsor Portal Certificate - Implementation w/ Public CA HSTS

[Ideal Networks]

Edit: Have found a short term workaround for HSTS error, ive installed windows certificate services and signed the following CSR generated in ISE.

CN: *.corp.local

SAN: sponsor.corp.com

Whilst this still presents a certifciate error for any client that doesnt have the CA in its trusted store, the HSTS error isnt present and i can get to the sponsor portal.

-----------------------------------------------------------------------------------------

Good afternoon, looking to gauge opinion.

We have a small ISE deployment and wish to do sponsored guest access, using a Cisco 9800, amongst other tasks.

FQDN of each server is (ise1.corp.local and ise2.corp.local)

We have procured a wildcard SAN certifciate signed by Digicert for all portals

CN: *.corp..com

SAN: *.corp.com

Guest workflow works without issue.

However HSTS certifcate error is shown when using Chrome to access sponsor portal.

Based on this thread, i understand what is happening, as we only have a self signed cert for admin access.

https://community.cisco.com/t5/network-access-control/ise-3-0-sponsor-portal-certificate-broken-after-all-these-years/td-p/4460190/page/2

What are people doing in this scenario?

• We dont have an internal CA to sign a cert to use for admin access w/ SAN entry for the sponsor portal.
• ISE servers are using internal/private FQDN .local, so we cant generate a multi-use cert and install that for both admin and portals.
• Procurement of individual certs for admin access and portals is not prefered

Is it feasible to change FQDN of ISE servers to use publically resolvable domain and generate multi-use certficiate to be used for admin access and portals?

ie: Change PSN FQDN from ise1.corp.local to ise1.corp.com?

CSR would look like this.

[hslai]

What are WildCard Certificates? And how do I use them with Cisco’s ISE > Wildcard Certificate Compatibility says,

> ...

> All Microsoft native supplicants tested (including Windows Mobile) do not support wildcards in the subject of the certificate.  The use of another supplicant, such as Cisco’s AnyConnect Network Access Manager (NAM), will allow the use of wildcard characters in the subject field.  Another option is to use special wildcard certificates like DigiCert’s Wildcard Plus that is designed to work on incompatible devices by including specific sub-domains in the Subject Alternative Name of the certificate.

> For more information on Microsoft’s support of wildcard certificates, see here: http://technet.microsoft.com/en-US/cc730460

Thus, it's better to have wildcard in Subject Alternative Name (SAN) but not in common name (CN).

> ... Is it feasible to change FQDN of ISE servers to use publically resolvable domain and generate multi-use certficiate to be used for admin access and portals?

If the sponsors' can trust your private PKI, you should not need to change the PSN's domain name. Any reason why the sponsors can not access the sponsor portal using the internal domain?

[Ideal Networks]

@hslai Thank you for your reply, unfortunaterly this is a multi tenant environment and there isnt a common PKI, the guest portal works fine with a certificate signed by Digicert and attached to the default portal group.

However when accessing the sponsor portal, a HSTS error is presented to the client due to the fact that the ISE Admin cert is presented first, and the SAN entry for the sponsor portal doesnt exist in the default self signed certififcate.

Hence, because there is no common CA or PKI, the only way i can see this working is to change the ISE FQDN to a public domain ie: corp.com and generate a CSR for a multi use cert that is attached to both the admin service and default portal group.

Does that make sense?

[ahollifield · Accepted solution]

It does, If I understand the issue, that is exactly what you should do.  Keep in mind that ISE is also not designed for multi-tenancy.