ISE 3.3 Certificates

[DAVID]

I am currently building out a new ISE 3.3 deployment.  I am NOT upgrading my current ISE 2.7 environment. During the initial ISE setup and configuration I will need to create the certificates.  I used a wildcard cert with ISE 2.7 for Admin, portal, EAP Authentication, and Radius DTLS. but I'd rather follow the Cisco ISE best practices and create individual certs on ISE 3.3.

I know that I will need an admin cert for ISE-to-ISE communication. A portal ISE to use when logging into the GUI.  I'd like to know the minimum number of certs and what type to create CSRs for 4 node medium ISE deployment.

Are there certs that can still be used as a wildcard and other uses that should be specific as to its use?

[forthehorde97]

Portal certificate is not actually for admin GUI, but for Guest Portals. Admin certificate serves as the ISE web server certificate as well as for inter-node communication. You don't need to issue certificates per usage but I'd use specific ISE nodes/portals FQDNs as CN/SAN attributes instead of wildcard.

[DAVID]

my main goal right now is to just create the admin inter-server certificate. Since I will be having two nodes acting as the primary and secondary I would create two separate certs for each nodes FQDN? 

[Arne Bier]

There are caveats and questions.

For Admin cert, I would create individual certs from your PKI - unless you have no problem spending money on a public CA cert AND you ISE FQDN uses a domain that the CA can validate. If it's an internal domain, then you must use your internal PKI. If you are lazy and want to cheat, then use a wildcard for the Admin cert.

For EAP cert do not use wildcard. it breaks on Windows 802.1X supplicants. But I have seen folks create ONE EAP cert and then deploy that on all their PSNs that are used for 802.1X. I tend to make one EAP cert per server, because that is the only way of ensuring that the FQDN gets into the Subject CN, which can be used in Windows Supplicants to check which server they are connecting to (as an extra check). Most folks don't use that check in Windows. So if you don't care about that, then make one EAP cert with a Subject CN of some common value - you can still populate the SAN to include all the FQDNs of all the PSNs just to be sure - but I don't know if supplicants check or care about that.

As for portals, obviously get a public signed cert. And wildcards are fine because you might already have one for other uses.

But remember - re-using certs means that they share the same private key - if that private key is compromised, then the attacker has access to all those systems using the shared cert.  That must be borne in mind - most people don't take the chance, especially if the costs and efforts are not too much to implement this. 

[DAVID]

We currently do not have a PKI.  We use DigiCert to sign our CSRs. In the current 2.7 installation of ISE a wildcard certificate was created for admin, EAP, portal and DTLS radius but I'd rather not follow that same process in 3.3

[Arne Bier]

It's wiser and cheaper to get two individual certs for each ISE node. Wildcard certs are expensive (because they offer convenience where needed). But the hassle with public CA certs is the domain validation (which should be no hassle for you, since it sounds like the ISE FQDNs have a domain that can be publicly validated) and then the annual renewal. Renewing Admin certs is a pain because it restarts services. hence why PKI cert issuance is so nice - no cost and you're free to set the validity (e.g. 3 years). It's really no big deal to setup a CA in Windows Server - or even easier is XCA. Runs on Windows/MAC/Linux.

[DAVID]

I've thought about using openSSL on Linux and creating my own PKI and sign the ISE CSRs that I can and use Digi to sign the certs they need to.

[Arne Bier]

@DAVID - you can do it with openssl - but a nice graphical solution that allows anyone to use this without having to remember all the CLI gymnastics of openssl (I love openssl ... but in the heat of the battle I also appreciate a nice GUI) - XCA - check it out. There are some video tutorials on the net that show how easy and cool this is.

[DAVID]

I'll definitely look into this. 

[DAVID]

Going forward. What ISE certs can be signed by a local CA; OpenSSL, XCA,  or MS Certificate Authority Server and what certs must be signed by a public CA like Digi? 

[Arne Bier]

The only one that must be signed by a public CA is the Portal certificate (in a prod environment). You can install a private cert in portals too (ISE won’t prevent that) but the endpoints will get browser cert warnings which makes this a no-no. Good enough for a lab test though.
Some folks also install a public CA for EAP cert if (and only if) they use a single SSID for Employee and BYOD (again, to avoid cert warnings during onboarding).
You can also install a public CA very for admin if you’re keen to replace it every 1 years and pay the costs. Totally unnecessary