ISE and public certs for EAP

[BrianPersaud]

Hi All

Our current ISE node is registered as ise.xxx.local

Is it possible to use ise.xxx.com as the EAP certificate?  

I presently have the .com wildcard cert used for guest and sponsor portal but I don't think it is setup correctly for EAP.  So I wanted to generate a separate .com certificate for EAP.

Just to note when I tried to generate ise.xxx.com as the cname and SAN DNS name, it in ISE, I got the message:

Certificate must contain the FQDN 'ISE.xxx.local' or a matching wildcard as a DNS name in the SubjectAlternativeName (SAN) extension.

Currently on 2.4 patch 10

Thanks

[Damien Miller · Accepted solution]

You're going to want to change the domain name of the ISE deployment. No reputable public CA will sign a certificate with a local tld. Once you move off the local tld you can move past the certificate issues and use the public CA signed certs.

[nspasov · Accepted solution]

What Damien said. You basically should not be using ".local" domain for even internal domains. Instead, you should be using ".net" or something else. With that said, what is done is done :) So, what you need to do is change the hostname in CLI to a FQDN with the ".com" A few things to keep in mind before doing this:

• You will still be able to join your ISE nodes to your ".local" AD (Assuming you are using AD)
• You will have to re-issue your wildcard cert
• Some DNS changes will be required since your internal hosts will probably need to resolve to "ISE.local" vs guests/BYOD which have to resolve to "ISE.com"

I hope this helps!

Thank you for rating helpful posts!

[Arne Bier]

Hi

Your statement "You basically should not be using ".local" domain for even internal domains. Instead, you should be using ".net" or something else" is not true.

The FQDN that you assign to an ISE node during installation can be an internal (private) domain name. e.g. ise01.local, ise02.local - this is to allow an organisation to maintain whatever internal naming convention they have. And of course you don't want to expose this to the outside world (e.g. in web portal URLs or certificates)

The fact that you may want to present guest.mycompany.com has nothing at all to do with the FQDN of the PSN nodes. You should be using static FQDN overrides in Sponsor Portal and Authorization Profiles for URL redirection.

And also use CNAME DNS records to map guest.mycompany.com to ise01.local - the TCP connection is built on the IP address of the resolved FQDN. If you design this right, then you can separate the host's FQDN from the client presentation layer.

[Damien Miller]

At the end of the day it's been a best practice since about 2013+ to not use ".local" for your domain. You won't get public certs signed with it, and rfc6762 released in 2013 which began leveraging .local for mdns.

[Arne Bier]

oh I was not implying that your public certs contain a domain of .local - that will never work because a CA cannot create a cert for any private domains.

My point was that we need to separate the transport layer connectivity requirements (FQDN --> IP address) from the presentation layer requirements (cert matching to FQDN)

The easy (lazy) way out is to build ISE nodes using a public domain (e.g. myise01.mycompany.com) - it's convenient to do this because it means that everything else falls into place and you won't need to use static FQDNs for anything. But it's a simplistic design that doesn't always work for all customers. Large customers have complex DNS domains and they like to use internal domains for internal services.

[nspasov]

Hi Arne-

Can you elaborate on your "is not true" statement about the usage of .local? Because it has been best practices not to use .local for a many years now with plenty of info about it on the www.

Thank you for rating helpful posts!

[Arne Bier]

I will have to take back what i said. I misinterpreted what @Damien Miller  had written and I didn’t consider the distinction of the more recent .local usage. I was not aware the .local had gained a specific usage as a TLD. I don’t use it myself but I have mostly come across customers who use private domains. That was my main objection. And then I had lumped .net and .local into the same category :-(

[nspasov]

No worries and thank you for the clarification! I wanted to make sure I was not missing something here as well :)

Thank you for rating helpful posts!