cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

504
Views
5
Helpful
3
Replies
Beginner

Question: Public Root-CA vs private internal PKI for EAP-TLS from a security point of view

Hello,

we're currently migrating from ACS 5.8 to ISE 2.2 in a pure MS Windows environment with MS Active Directory and MS Windows Server PKI for internal purposes. Every domain joined endpoint gets provisioned with a client-certificate over group policy over which it authenticates to the ACS. Currently ACS is configured with this environment in mind, but now with ISE we want to expand that even further for "Eduroam" wireless clients, where we need a certificate from a publicly trusted certificate authority for roaming endpoints to be secured over EAP-TLS and for the ISE (currently FreeRadius) to establish an encrypted RADIUS (radsecproxy) connection to the federation server. But ISE can't handle more than one EAP-Certificate so we have to choose. Cost wise it is no option for us to set up another ISE-Cluster.

 

Now I'm standing here evaluating the security impacts switching our trusted internal PKI to a public trusted certificate authority might have... if that even has a impact. What do you think? Does switching from a purely internal PKI for EAP to a public trusted CA have an impact on security? The endpoints still get a client certificate for authentication, the only difference would be the EAP-Cert on the ISE and the trusted root ca change on the clients.

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: Question: Public Root-CA vs private internal PKI for EAP-TLS from a security point of view

Since you are using endpoint certificates, the risk is not as big compared to using passwords. Using certificates the endpoint is merely sending public certificate to the server for validation. However, you can still add more security by using supplicant trust settings (Preferably via GPO) on all the machines. When doing so use 'Connect to these servers (example...):' option to validate the CN matches the new ISE EAP certificate. This allows supplicant to only trust your certificate and not any other server certificate signed by specific public CA.

Screen Shot 2019-02-08 at 11.20.50 PM.png

View solution in original post

3 REPLIES 3
Highlighted
Cisco Employee

Re: Question: Public Root-CA vs private internal PKI for EAP-TLS from a security point of view

Since you are using endpoint certificates, the risk is not as big compared to using passwords. Using certificates the endpoint is merely sending public certificate to the server for validation. However, you can still add more security by using supplicant trust settings (Preferably via GPO) on all the machines. When doing so use 'Connect to these servers (example...):' option to validate the CN matches the new ISE EAP certificate. This allows supplicant to only trust your certificate and not any other server certificate signed by specific public CA.

Screen Shot 2019-02-08 at 11.20.50 PM.png

View solution in original post

Highlighted
Beginner

Re: Question: Public Root-CA vs private internal PKI for EAP-TLS from a security point of view

Thanks for the answer. I'm probably going to configure the option "Connect to these servers...". That should be sufficient for security. Is it a problem to use the same EAP-Certificate for all ISE servers in the deployment? eg. "radius.cisco.com" as CN (without other SANs) for ise1.cisco.local to ise4.cisco.local?
Highlighted
VIP Engager

Re: Question: Public Root-CA vs private internal PKI for EAP-TLS from a security point of view

You should use the same EAP cert on all the ISE PSNs that avoids the clients having to deal with different certs when authenticating.  This could especially a problem if you have any mobile device authentication use case that like to complain about certificates the first time they connect to an SSID.  If you have different certs on each PSN you could have multiple cert warnings.  Just make a CN cert with radius.cisco.com as you said.  You don't need to put the ISE PSN hostnames in the SAN field for the EAP authentication use case.