ISE node FQDN domain different from certificate CN and SANs domain

[cherie13653]

Running ISE 3.3 with 2 nodes running all personas with Active Directory join

AD example = mycompany.com

The certificate for Admin/EAP/Radius DTLS is from their internal CA and contains DNS SANs fields using

isenode1.mycompany.com

isenode2.mycompany.com

guestportal1.notmyAD.com

guestportal2.notmyAD.com

Their Guest Portal certificate is from 3^rd party CA and has CN of *.notmyAD.com as well as the following DNS SANs

guestportal1.notmyAD.com

guestportal2.notmyAD.com

mydevices.notmyAD.com

*.notmyAD.com

The internal admin/eap certificate is on both nodes.

The guest certificate only resides on ise node 1.

When they export the guest certificate from node 1 and try to import it into node 2 they’ve run into issues related to ISE actual FQDN being in a different domain than the CN or SANs.

I’m not sure how it was ever installed into Node1

While their AD is mycompany.com, their email addresses are user@notmyAD.com

Looking for recommendations on resolution.  I think we need to change the domain on the ISE nodes from mycompany.com to notmyAD.com and regenerate certificates?  Is there a better alternative?

[Arne Bier]

Hi

How did you manage to create an Admin/EAP cert that contains two different DNS domains?  

The certificate for Admin/EAP/Radius DTLS is from their internal CA and contains DNS SANs fields using

isenode1.mycompany.com

isenode2.mycompany.com

guestportal1.notmyAD.com

guestportal2.notmyAD.com

That should be technically impossible to do.  Your Admin/EAP certificate should only contain mycompany.com SAN entries.

The portal cert should contain notmyAD.com SAN entries. If it's a re-used wildcard cert then it should be fine for Guest Portals. Else, customers usually create a multi-SAN cert that contains these in the DNS SAN fields

guestportal1.notmyAD.com
guestportal2.notmyAD.com

Please don't change your ISE deployment DNS domain from mycompany.com to notmyAD.com - that is not necessary.  

Guest Portals operate by using DNS to resolve guestportal1.notmyAD.com and guestportal2.notmyAD.com to the IP address of isenode1.mycompany.com and isenode2.mycompany.com respectively.  That's a job for the client's DNS resolver - the DHCP scope must provide a DNS server that can successfully resolve that.

[Scott Fella]

It is possible to submit a CSR and get a cert because we used to have the same a while back during some mergers.  We don't now, but our AD now has trust to all the other domains.
I did just test this in my home lab using openssl with a Windows CA and successfully installed the cert in my ISE 3.4 node.  I didn't apply it to my admin, but I may try to do that on a test node just to see.

[Arne Bier]

In openssl you can create whatever you like, but a public CA should not have the ability to create a certificate that represents an internal domain which has its own PKI, and for which the internal PKI should be issuing certs.

   
When you import a cert into ISE, it doesn't check the SAN to see if what you put there is sane.  Although, I think for guest portals, newer ISE versions try to be clever and reconcile the portal FQDN with one or more SAN entries - but it can't be sure whether any of this is valid and mostly gets it wrong (stating that a valid cert for a valid portal is 'Stale')

A trustworthy CA can/should only issue certs for a domain for which it has obtained proof that the CSR requester owns the public domain (e.g. public DNS TXT record).  If an organization is putting its internal domains on the internet to allow CAs to validate it, then that sounds like a terrible idea to me.

I can create a cert in my home lab with a SAN: www.google.com   - but it doesn't mean I can make your browser trust that, even if I could poison the DNS and send you to my rogue server, running that cert for that domain.

[Scott Fella]

You are right, I took the OP as stating that their internal cert provided a cert with the internal domain and another domain but not a public domain.