802.1X self signed certificates

[networker4424]

Hi,

We are testing ISE and so far we've successfully tried authentication using username and password but now we want to test certificate based authentication. Will self signed certificates be ok for dot1x authentication between a windows client and ISE.

The version of ISE i'm using is 2.4, any suggestion or documentation in this regard will help a lot.

Thanks,

[Francesco Molino]

Hi

What do you mean by self signed certificate between client and ise?
Who will sign the certificate of your clients?

[Colby LeMaire · Accepted solution]

Self-signed certificates would work just fine as long as each side trusts each other.  If you are using self-signed certificates on ISE for EAP Authentication, then you would need to ensure that the ISE certificate is loaded on the client side in the certificate trust list.  Just import the ISE certificate into the Root or Intermediate CA certificates list.

If the client's certificate will be self-signed, then you would need to install that certificate into the ISE certificate trust list and make sure to check the option "Trust for client authentication".

But this is only for testing!  I do not recommend self-signed certificates for production.

[networker4424]

Yes we are only testing and I dont have access to PKI certs at the moment so thats why I asked if I could give it a run with the 509 type certs.
And allow me to say this it was a pure joy reading your post, best post one could read to start their day, bless ya.

[Lynda_D]

Why are self-signed certificates for production not recommended? 

[Colby LeMaire]

A certificate is like an ID card.  It proves that you are who you say you are.  Some places check IDs and some places don't.  Some have strict requirements for ID's like in the US now where TSA at the airport won't accept a driver's license unless it has a gold star on it (Federal REAL ID Act).  Some places like bar may just want you to flash it in front of them but don't really verify the authenticity of the ID.  That is the same with server certificates.

The burden is on the client side to verify that the server is trusted and that it has a certificate (ID card) that was issued by a trusted third party such as Verisign.  If the client side detects a problem with the certificate, it presents a warning to the user but the user can choose to continue.  So for lab testing or internal-only systems, a self-signed certificate will work.  It would work in production as well but the user would be prompted each time saying the server is potentially unsafe.  So that is an impact to your organization's reputation or brand.

The other concern is that if you use self-signed certificates, you are conditioning your users to just click accept/continue when presented with a warning.  So when they actually do hit a rogue server, they will likely just click accept/continue and be compromised.  I personally don't want to condition any users to do that.  Users are already vulnerable enough.

[Lynda_D]

Thanks for the explanation!