This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
Does anyone have any experience with Publicly signed ID certificates for ISE.
We are going to be deploying Guest Services via CWA. When a user connects to the portal they get a certificate error as the current ID certificates are only signed by our internal CA and nobody but internal users will have that CA installed.
I went to an external provider (Geotrust) and wanted to get a Public CA signed Certificate with the CN = guestportal.company.com and SAN fields of internalserver.company.local.lcl, Private IP of BOX and External IP of Box. I get this Error from Geotrust.
Researching further into this it seems that all Certificates being issued by Public CA’s need to abide by the following new rules.
“What is an Internal Name?
An internal name is a domain or IP address that is part of a private network. Common examples of internal names are:
Any server name with a non-public domain name suffix. For example, www.contoso.local or server1.contoso.internal.
NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
Any IPv4 address in the RFC 1918 range.
Any IPv6 address in the RFC 4193 range.”
Has anyone got around this? Or will the guests just have to put up with the Certificate error? Also I'll have to change the PSN's hostname to the CN which has implications for it joining our internal active directory so not keen on that.
I've ready that LDAP might be my only solution which I am not really keen on see below.
Solved! Go to Solution.
This requirement by public providers is a pain but a reality I suppose. In terms of your concerns I have deployed this many times without drama (ISE 1.2)
Internal name refers to a private domain name eg internaldomain.local whereas public is your publicdomain.com.au
Joining AD - Never had a problem with the PSN been on a "different" domain ie public FQDN vs internal FQDN. Just join the box to AD as you would normally. For intents and purposes the FQDN of the policy node is pretty much portal related. If there is an internal standards issue then you could always use the host alias functionality on another NIC so you can leave the primary hostname of the PSN alone and make a specific interface serve up a portal on a host-alias:
The biggest issue I encounter with all of this is my clients having to resolve an "internal" host to a public FQDN. The issue is not technical generally but people generally seem to hate the idea of an internal ip inside the network resolving to a public name (I might add it does not need to resolve externally).
In summary the solution will work.
I've changed my deployment to company.com instead of company.local now because of this. We have split DNS setup and haven't encountered a problem as yet although my lab is not in production as yet.
Sent from Cisco Technical Support iPad App
I've already started rolling this out in deployments. Here's what I have been doing:
With that solution, clients accessing the HTTPS portals for guest authentication, sponsor portal, or CWA do not receive a certificate warning and your internal domain computers to not receive a certificate warning for PEAP or EAP-TLS authentications.
I am more so thinking of a case where the ISE deployment was deployed with a public domain (ex: mydomain.com), but the customer wants to use their internal CA for EAP. So i would be requesting EAP certificates with a CN of PSN1.mydomain.com but on a CA in the domain.local domain.
Based on the example you gave above, can the CN=ise.mydomain.com be a DNS Alias for PSN1 and PSN2 instead of an A record? Does it even need to exist in DNS?
The CN, in this example ise.domain.com, can exist in DNS or not. It's flexible and up to you, it can be a real node, it can just be an alias, it could be a guest portal, the option is yours there.
In most cases I have seen, the CN doesn't have a DNS record anymore because it is just an old legacy fqdn from a radius servers in the past. Nothing stopping a person from defining it though.
Thanks for responding, given that the post is old. Based on what you said, I guess that the CN would be relevant if a public cert with no SAN is used, which I’ve mostly seen used for guest portal, but for private domain, a DNS for a “generic” CN isn’t relevant.