Subdomains and parent domains

[Madura Malwatte]

We are planning to use wildcard certificates on ISE and instead of using *.company.local which could compromise the top level domain, we want to use a subdomain instead, example *.ise.company.local

If we issue the private certificate for *.ise.company.local should the ISE nodes "ip domain-name" be configured for the subdomain "ise.company.local" or the parent domain "company.local". We would like to just point it to the parent domain.

Is there any implications in using one of the other in the ip domain-name configuration?

[Arne Bier]

The node's ip-domain can be completely different from the SAN DNS entry in your certificates.  Of course, if you match the cert domain with what you have configured on the node's ip-domain, then you have a no-brainer solution.  The redirection just works out of the box.

In your case, you can make the ISE nodes (PSN's) ip-domain equal to ise01.company.local, ise02.company.local - and then have two MAB authorization results that return two different static FQDN's that you wish your guest client devices to resolve

if Network Access ISE Host Name EQUALS ISE01 then redirect using static FQDN ise01.ise.company.com

if Network Access ISE Host Name EQUALS ISE02 then redirect using static FQDN ise02.ise.company.com

[Madura Malwatte]

Hi Arne, thanks for your response.

You mentioned "The node's ip-domain can be completely different from the SAN DNS entry in your certificates.", but can the node's ip-domain be different from the CN in the certificate (for PSN's and PAN's)?

Example:

Subject

CN = ise.company.local

SAN

DNS Name = ise.company.local

DNS Name = *.ise.company.local

Can the PAN/MnT have "ip domain-name company.local" configured?

[Arne Bier]

Hhhm - I thought you were referring to the Guest redirection stuff.  My answer was specific to that use case.

If you're referring to the case where the ISE System certificate is used for Admin and/or EAP, then there is no static override.   I have never tried doing what you're asking here - I would say that the node's System certificate for EAP does not need to be resolvable in DNS - and therefore as long as the supplicant trusts ISE's EAP cert and its CA chain, then all is well.

As for the Admin role, when you browse to a node as ise01.ise.company.local (which needs to be specified in the cert SAN (as a wildcard, or as a FQDN)), then all you need to make sure is that you have a DNS logic that does the following

ise01.ise.company.local CNAME  ise01.company.local

ise02.ise.company.local CNAME  ise02.company.local

ise01.company.local  A  10.0.0.1

ise02.company.local  A  10.0.0.2

And your ISE01 node has:

hostname ise01
ip domain-name company.local
interface GigabitEthernet 0
 ip address 10.0.0.1 255.255.255.0

[howon]

Are you planning to use the *.ise.company.local certificate for all functions within ISE or just for certain functions? ISE relies heavily on proper setup of certificates and given the choice recommend using proper setup. If the wildcard certificate is just used for enduser facing functions such as enduser portal and EAP then I see no issues, but if using the same certificate for inter-ISE communications, I recommend changing domain suffix on ise nodes to include the sub domain to match the certificate.

Also, I recommend using domain suffix that conforms to standards such as .com or .org instead of .local.

[paul]

As others have said you have separate use cases for certs in ISE so you can do different things.  For Admin use case the FQDN of the ISE nodes must be in the cert or covered by a wildcard.  Your setup is how I have done some large customers:

CN= ise.company.local

SAN= ise.company.local and *.ise.company.local

This covers the Admin and potentially the EAP-TLS authentication use cases for your deployment assuming all the FQDNs for your ISE nodes are in the ise.company.local sub domain.  

For your guest certificate you are going to have to use public certs and you can structure those however you want.

[Madura Malwatte]

For wildcard (all functions, portal, eap, admin) it says to have a generic hostname in the prefix, then followed by sub/parent domain. So do I need to do something like this:

CN = access.ise.company.local

SAN = access.ise.company.local and *.ise.company.local

Or can I just generate CSR like this, where the CN only contains the sub/parent domain but no generic hostname?

CN= ise.company.local

SAN= ise.company.local and *.ise.company.local

[RichardAtkin · Accepted solution]

Use the sub-domain of ise.company.local, it will make your life much easier when it comes to using the various Portals in ISE.

Do not use Wildcard cerrs for EAP - it can cause problems. Instead have one cert called radius.ise.company.local and use that across the board for all PSNs.

[Damien Miller · Accepted solution]

Wildcard certs work find for EAP. The important part is to embed the wildcard in the SAN's and then it works fine. If you put the *.contoso.com as the CN, then yes, a world of hurt is coming your way.

We use wildcard certs in most of our ise deployments.

[RichardAtkin]

Agreed, but how many people put it in the SAN?  I'm currently 3/3 on people giving me a wildcard cert with the * in the CN and expecting it to work for RADIUS :(

[Cory Peterson · Accepted solution]

Everyone I work with and all my customers put it in the SAN, because I make sure to tell them that is how it has to be done. 

This is not something most people would know if they normally generate certs for web servers. You need to be sure you explain to them that the wildcard must be in the SAN. 

[paul]

Chrome dropped support for Common Name checking in version 58 I believe. I think they added it back in with a setting, but in my opinion the common name should be used for nothing if you generating new certs. You need to ensure the SAN fields are correct.