How many 3-rd party signed SSL certificates is needed for ISE 4 node deployment?

[berik]

Hello, 

The restriction is according to agreement we have only  one wildcard (* in CN field) and x simple certificates (not multidomain).

How many 3-rd party signed simple SSL certificates is needed? In which combination?

Environment:

- ISE 2.7

- 4 node deployment (2 - Admin & Mnt, 2 - PSN)

- Sponsored Guest access

- dot1x

- no BYOD

- no Profiling/Posture

- only Base, Device Admin licenses 

On 2 PANs I plan to use Internal corporate CA signed multi-use, wildcard (* in SAN field) certificate. Without 3-party signed cert.

On 2 PSNs:

- for Admin function I plan to use Internal corporate CA signed cert (same cert as on PANs)

- for EAP Authentication one  3-party signed cert for every PSN (overall two simple 3-party signed certs with hostnames of PSN on CN field.)

- for Guest, Sponsor portals I plan to use one 3-party signed wildcard (* in CN field) cert

Are there any problems using certificates this way?

Thank you.

[Colby LeMaire · Accepted solution]

There is no requirement to use different certificates for different services.  So technically, you could use the same certificate for all services you listed.  With that said, following are thoughts on your individual points:

- ISE Admin Services:  Your idea of using internal CA-signed certificates is perfectly fine.  You do not need to use a wildcard certificate for this.  You can assign each ISE node its own certificate for administration.

- EAP Authentication:  If the only devices that will be authenticating via 802.1x onto your network are your own corporate-managed devices, then you can use an internal CA-signed certificate for this too.  If you will have devices that you do not manage connecting to the network using 802.1x, then you should use a third-party certificate.  For this, I would recommend using a wildcard certificate because Apple devices will prompt for the user to trust the Radius server certificate if the device roams to another PSN.  Using a wildcard certificate for this will prevent those issues.  Also, when doing a wildcard, make sure that you do NOT use the wildcard in the Subject/CN field.  Windows machines do not like that and will not authenticate properly.  Use a normal FQDN as the CN and then put the wildcard DNS name as a Subject Alternative Name (SAN).

- Guest/Sponsor Portals:  You can use the same wildcard certificate that you get for EAP authentication.  There is no need to use different certificates unless you just want to.  And as far as using the wildcard in the CN field, please see the notes for EAP authentication about Windows not liking the wildcard in the CN field.

[Mohammed al Baqari · Accepted solution]

+5 Colby. Just one catch, for EAP authentication with Windows Native
supplicant, wildcard is not supported. It has to be a host-based
certificate to work. This is a restriction from MS.

Otherwise, single cert can be used for all. This is simpler and easy to
manage instead of having different certs with different timelines (unless
it's a security requirement).

***** please remember to rate useful posts

[Colby LeMaire]

Wildcard is supported on Windows as long as the Subject/CN is not a wildcard.  That's what I was talking about in my post.  That you have to use a normal FQDN for the CN and put the wildcard in a SAN DNS field.

[Mohammed al Baqari]

Sorry didn't notice it in your post. Thanks for highlighting it.

[kaiyrkhan1]

Hi Colby,

Can I use certificate for eap auth only, where,

CN=eap.domain.country

SAN=eap.domain.country

For both PSN nodes?

*I can't use FQDN of psn nodes in CN field