ISE 2.3 Services - Cert Best Practices

[55cfffb534]

Implementing ISE 2.3. Is the best practice for certificates to create a certificate for each service or is it best to just use the Multi-Use and assign it to the various services?

admin

eap auth

pxGrid

SAML

Portal (probably use a public CA for this one)

The reason I ask is when I created a cert request for each service, had each request signed by our enterprise CA and tried to bind them, I got this error after binding the first one (admin) successfully:

"You are attempting to import or generate a certificate whose subject matches the subject of an existing certificate on the same node. This is only permitted when you are replacing a certificate of the same role. Note that the subject is the concatenation of several fields (for example, CN, O, OU, etc.) You can create a unique subject by varying the values in these fields."

Is the fix really just to modify the subject? Seems like kind of a hack but I must be missing something.

Thanks for any suggestions!

[Arne Bier · Accepted solution]

I tend to use the multi-use certificate for Admin/EAP because in all likelihood it will only be corporate users who need to access the Web GUI from their corp devices (who have the corp PKI cert chain).  I don't want browser cert warnings, and of course I want the EAP authentications to work.

I use a common public CA cert for all of the portals (e.g. same cert for Guest/Sponsor/MyDevices/Blacklist portals) because these portals are public facing.

For Admin/EAP,  the Subject CN can literally be anything and has no bearing on the real server's hostname.  We put the real FQDN's into the certificate SAN field.  This is where the browser looks to validate the hostname.  In your case you could avoid that error if you used the same cert for Admin&EAP.  But if you wanted to separate those two out, then just make the Subject CN unique for each cert.

[55cfffb534]

That honestly makes perfect sense. I think part of my issue is perhaps not understanding the use case of each service (yet).

Thank you very much for your insight!