Wireless Employee Dot1x User Authentication

[Abraham012]

Hey Folks,

I have integrated Wireless Employee SSID with Cisco ISE 2.7 for User Authentication against AD. Everything is working is working as expected only with PC/Laptop joined to domain. But same SSID is not working with Mobile Phones(Android, IOS). Customer provides me Internal root CA binded with ISE CSR. If i use Public Root CA, will my Mobile Phones work with same SSID? 

When am connecting same SSID with Mobile Phone, it says "CA Certificate must be selected".

[Karsten Iwen]

You should not use a public certificate with your 802.1X authentication. The right way is to use your private cert (from the internal CA or the ISE-CA, based on your needs) and distribute the root certificate to all your clients. If not using a MDM for this, the build-in BYOD-process of the ISE could help here.

[Abraham012]

Thanks Karsten,

So, it means that, every Mobile Phone must have a Client Internal Root CA installed before connecting to SSID.

Any good reference link to distribute CA cert on all the clients before connecting SSID. Can we achieve this BYOD single SSID???

[Karsten Iwen]

Your client devices need the root cert to be sure that they are authenticating against the right authentication server.

You should also think about the EAP-Methods you use. If you are using username/password, this is probably ok for your domain-users. But with mobile devices you could get in trouble after password-changes when the mobile devices try to authenticate with the old stored password and the account gets locked.

That is one reason we use EAP-TLS most of the times for mobile devices. The BYOD-process can enrol the devices with not only the root-certificate, but also with identity-certificates. Using single-SSID or dual-SSID is your choice. I like dual-SSID more as with single-SSID enrolment your users will *always* get a certificate warning which I do not like.

https://community.cisco.com/t5/security-documents/cisco-ise-amp-nac-resources/ta-p/3621621#BYOD

[Arne Bier · Accepted solution]

Hello @Karsten Iwen 

I used to be of the same opinion as you - i.e. use the organisation's PKI CA cert to sign the ISE EAP server certificate. However, I have been convinced that using a public CA cert to sign the ISE EAP cert is actually quite useful - and safe. The only downside is that it's not free. Assuming that cost is not an issue, the benefit of using a public cert (like DigiCert) to sign the ISE EAP certificate, is that supplicants won't have the issue of trusting your ISE server during the TLS establishment. This goes for EAP-PEAP and EAP-TLS client supplicant - and if you want to nail down the security a bit more, then you can configure the supplicant (e.g. Windows ) to trust only server that has the FQDN baked into the cert - like mycompany.org.com - since the cert is issued by a public CA, YOU will own the FQDN and therefore it's impossible for a hacker to get a cert from a public CA that has the same FQDN. You could even configure the supplicant to expect the CA cert to be from the exact CA that you have used (e.g. DigiCert CA 2 or whatever).

The other benefit of using public CA is that if you use EAP-PEAP for BYOD onboarding, then you avoid the cert warning on devices that don't know/trust your internal CA (chicken and egg problem - how could they know it ??)

As for the client's certificate, that should always be signed by an internal PKI/MDM - and all ISE needs to know, is the CA chain that was used in signing this client cert, and then import that chain into the trusted certs in ISE.  

[Karsten Iwen]

Hi Arne,

EDIT: I just realise that I completely misunderstood your post. What I tried was completely different.

For using a public Cert in EAP, I remember some restrictions here, but I think I have to lab that again.

a couple of years ago I also tried to go that way but abandoned it. The "problems/challenges" were

1. A cert signing certificate was ridiculously expensive
2. I had to look through my notes wich CA it was, I think it was Symantec, they did not want to offer a cert with a long enough path length constraint to support the ISEs sub-ca-hierachy.

Do you have a product to suggest? I definitely could change my mind on this.

[Abraham012]

Thanks Arne,

If i want to use Public CA then do i need to generate CSR from ISE and share with them to sign it with Public CA??? (OR)

If i get Public Root CA, Sub-ordinate CA and private key is enough for us??? please do share your comments.

[Karsten Iwen]

You should always generate the CSR on your own and provide this to the CA. The private key should never leave your environment. If the CA offers an option to generate the pub/priv key-pair and CSR, you should make sure that it is done in the browser and not server-side.

[Arne Bier]

There are many types of certificates that you can buy from a CA and I don’t personally endorse any of them. But let’s just say that if you wanted a single domain cert, then it should be around $100 US for a year. You don’t need anything more expensive than a DV cert (domain validated). This is a basic cert which requires the domain owner to prove via email or http (or DNS) that they own the domain. The more bells and whistles you add to the cert, the more expensive. Best to create the CSR on ISE and submit that to the CA. Alternatively, another safe method is to create the CSR via a tool like OpenSSL. You still retain the private key, but it’s just a lot more hassle. Do it in ISE!