10-14-2016 03:43 PM
In ClearPass training, I was told that I should use a public cert for HTTPS and a certificate from our internal CA for RADIUS which is what we currently have.
I have set up 802.1X EAP-PEAP so that users with non-corporate assets can connect using their AD credentials.
Some clients are able to connect after checking the certificate warning, but other clients always fail authentication. Those clients will never prompt to accept the non-trusted certificate even though the box to “Do not prompt” is not checked in the wireless settings. The only way I can get them to connect is to uncheck the “Validate server certificate” option which I do not want. It also means that the user would have to manually create the wireless profile rather than just clicking the wireless network to join.
My questions are:
1. Is there another way to make this work?
2. Is there any drawback to using a publicly trusted certificate for the RADIUS certificate over one from our internal CA other than the cost? (Note that we also do EAP-TLS with our corporate assets)
3. Can I use a wildcard certificate or do I need to purchase a SAN certificate that includes all of our my Clearpass servers?
Solved! Go to Solution.
10-14-2016 03:59 PM
If you're deploying a network with more than just corporate owned assets, generally you'll want to use a public RADIUS cert.
2) Some will argue that a privately signed or self-signed RADIUS server cert is more secure, but at the end of the day, most implementations of PEAPv0/EAP-MSCHAPv2 are incredibly insecure as it is.
3) Wildcard certificates should not be used for RADIUS. In terms of names. SAN certs are recommended when using the guest portal functionality in a cluster. If you're not using any end-user facing web services, a single generic common name can be used for the RADIUS server certificate (clearpass.domain.com, network-login.domain.xyz, etc)