Certificate question with ISE - unable to get wildcard cert - options

[bberry]

Hello all,

I currently have a working ISE cluster and am supporting employee profiles using 802.1x and guest profiles using the redirect method. I have self signed certificates and have just delt with the messages about the guest users connecting to unsecured networks. Normally they can simply accept the warnings and continue on their way. 

With the release of the newer browsers and new operating systems like windows 10 we are pretty down to just one browser that still does this. I have to get most of my users connected using firefox so they do the the warnings and are able to get prompted for credentials to sign on. Other browsers such as IE no longer do this especially with newer flavors of windows 10.

I have been told I cannot get a wildcard cert for this implementation due to the fact our internal domain is a .corp. The .corp has now been set aside to only be an outside certificate. Since I can not get a registered certificate from a CA are there any other options? Can I stand up a completely independent environment to acquire a certificate for my ISE cluster? Do I have to completely rebuild the corporate domain from scratch so I do not have a .corp? I am in waters that are way over my head so not sure where to go or what options I may have. I just figure this may not be a simple solution and am trying to get ahead of the issue with a game plan.

Brent

[Mohammed al Baqari]

Why don't you get a certificate for ISE signed by CA and make ISE as CA
server for your clients to provision certificates during supplicant
installation.

[Arne Bier · Accepted solution]

Let's separate Guest and 802.1X for a minute.

Guest Network requires a public cert to be installed in ISE for the Portals that you are presenting to the guests.  There is no way around that.  No internal PKI or ISE self-signed cert is going to help you out there, because Joe Bloggs Guest user doesn't trust any of those CA's - but his device has Public Root CA certs - so therefore spend the couple of hundred bucks and get a public CA signed cert for your Guest portals.  You need a valid domain of course.  If your organisation does not own a public DNS domain then you need to get one first.  The most basic Certs are domain validated (DV) certs.  And the CA will need proof that you own the domain.  They send you an email or try to read a small file from one of your public facing web servers.  

Once you have a public domain, you can create internal DNS entries for www.mycorp.com to resolve to the ISE PSN node(s) hosting your web portals.  If you have more than one PSN, then there are tricks you can play before you need to pony up for a load balancer solution (3 or more PSNs requires a load balancer).

Now 802.1X - the wanrings that users get when they attempt an EAP connection to ISE is not the same as a browser cert warning. It's the operating system's supplicant warning the user that the Radius server is unknown.  But 802.1X is a different thing than Guest!!! You don't expect Joe Bloggs off the street to use your corp 802.1X network!  Therefore, you are in charge of pushing the ISE EAP cert to all those devices that expect to connect to ISE 802.1X.  In a Microsoft enterprise you can use Group Policy to distribute these ISE certs to your supplicants.  And then they should no longer get cert warnings,

BYOD is also another option.  Here you onboard via a Guest Portal and then ISE can be the Issuing CA that issues certs to the clients.  It handles the whole business of client certs for the 802.1X communications later on.  This requires an ISE Plus license.  And remember that BYOD is NOT strictly corporate 802.1X - you could however abuse BYOD (if you wanted) to onboard your corp devices.  This might make sense if you don't have a nice Enterprise PKI setup.  ISE can handle all that jazz for you.

I hope that helps a bit.  This topic does confuse a lot of people - you are not alone!

[bberry]

I am thinking what I may have to do is create a new internal .com domain. I can then register that with GoDaddy or Thawte and acquire a wild card cert. This way I would have a public certified CA. I can place all the ISE infrastructure in this domain and everything would be much happier?



At the moment the company does not want to do BYOD as that reduces the control of what devices we can and cannot allow on the network. Policy at the moment is that no personal devices are connected to the network. This includes call phones as well as laptops and tablets. I use tables with MAC addresses that are part of the authentication process to facilitate the device control.

[Arne Bier]

Yes you can use public CA cert for everything. Wildcard certs are more expensve upfront but worth it. Just don’t put wildcard in the Subject CN! That will break Windows supplicant. Put the wildcard in the SAN only.

[Jason Kunst]

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#concept_8ECCCAF1252E40DDB9A786C0AC7BC3B2

[bberry]

Thanks .. This is actually what I am working through. The conversation I am now having with my server group is having to rename the servers to march the certificate. Right now they are all {server_name}.abc.123.corp. I need to get the server names to match the cert info right? This would mean requesting say *.abc.123.com and then have to rename the servers to be {server_name}.abc.123.com. DNS would then also have these same {server_name}.abc.123.com listed among the rest of our corporate devices. The server guys are saying I can leave the things as {server_name}.abc.123.corp and simply specify the new {server_name}abc.123.com when I create the request and everything will install and work just fine. Not knowing much on details for how all these parts play together I have always had the system name in the cert not something else. I would thing the cert would not install. 

Brent

[Damien Miller]

Your server guy is correct, you can request a cert with the different names in the SAN fields and it will work. You can generate this CSR from the ISE admin node.
DNS is the one item here that is not flexible. DNS forward and reverse entries have to match the configured ISE hostnames and domain. The deployment won't work without it.

You can install any cert you want on the ISE deployment, doesn't mean it will do you any good though if the the names you need are missing. It all has to come together at some point so I would say make everything match and save the headache.

[Arne Bier]

The ise node FQDN that is configured on the node CLI does not have to match what is displayed in the certificate SAN.  You can have a DNS CNAME entry that points to the real A PRT record.

e.g.

Your ISE node CLI says:   ise01.internal.net

But the cert says:  ise01.mycompany.com

Then this is not a problem if your DNS is setup correctly.

DNS records:

ise01.mycompany.com   CNAME   ise01.internal.net

ise01.internal.net   A   192.168.1.2

Hostname resolution finally resolves to an IP address, which is then used for the TCP connection establishment.  You can abstract the ise node name from the FQDN in the certificate.

e.g. quick test below in the lab

[admin-biera@iptel-centos-01 ~]$ nslookup arneise.milton.iptel.com.au

arneise.milton.iptel.com.au     canonical name = ise01.net.local.
Name:   ise01.net.local
Address: 172.16.1.1

[bberry]

And there would be no issues with the server to server communications since I thought these same certs were used for that as well. The wild card cert would be installed on all 5 servers currently in my cluster.

[Arne Bier]

Hi @bberry

It's not an issue.  if you type https://ise-admin.corp.com into your browser because that is a host in your SAN's *.corp.com wildcard SAN field, then all will be well.  The FQDN doesn't re-write itself to ise01.net.local or whatever.  But at the network layer, DNS has figured out that you need to build a TCP connection to 172.16.1.1 (your ISE node) and that's what happens.  The FQDN entered into the browser is not directly related to the eventual IP address.

If that thought fills you with dread, then you can always create a self-signed ISE wildcard cert and then install that on each node for the Admin role.  I have done this for some customer too, while they wait for the Public CA cert for EAP and Guest Web Portals etc.  It means that your ISE admins get a browser warning when they connect to https://ise01.net.local but that's pretty acceptable these days for internal tools.