One trick with configuring clients: You can configure the client with common name validation and then validate the root CA. When you have to renew the certificate, users *shouldn’t* receive any messages because the validation information in the supplicant remains the same.
The ideal solution is to move to EAP-TLS and move away from legacy protocols like PEAPv0 and EAP-TTLS that have known issues and security concerns. From: The EDUCAUSE Wireless Issues Constituent Group Listserv <[email protected]> on behalf of "Oakes, Carl W" <[email protected]> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv <[email protected]> Date: Monday, March 13, 2017 at 3:42 PM To: "[email protected]" <[email protected]> Subject: Re: [WIRELESS-LAN] Certificate for 802.1x This one hits home for me, going through this now on a certificate expiring and battling on what to do next. Most clients don't trust any certificate, even if the device is set to trust them OS wide (web browser, etc). The wireless / supplicant configuration needs to be setup to trust specific certs or CA's. Onboarding tools can be used like SecureW2, Aruba ????, Cloudpath, eduroam CAT to load and enable the RADIUS cert and set it active/trusted. If clients onboard themselves, just by manually attaching to the network, they trust the immediate certificate, and I think in some cases, just the digest of the cert, making future cert updates "eventful". Clients when authenticating can't check the CRL or OCSP for certificate revocation, since they aren't on the network yet while trying to authenticate. So, with all that, I really don't want to get another 3 or 4 year cert and deal with the expiring cert again. Not a pretty scenario. Last time this happened, it hit us by surprise since we couldn't get a new cert based on the previously trusted CA. Errrr I'm tempted to create a self-signed local CA just for the RADIUS server validation, and a then generate a single cert off that CA. Then have SecureW2 (what we have) provide that CA and mark it as trusted. Since it's our own CA, was going to make it good for 20 years (just shy of the 2038 unix time clock issue). Avoids the problem until after I retire. :) In testing, so far this seems to work great. But test is very different than thousands of random student devices. In theory it could be just a single self-signed cert, but I liked have the added bonus / flexibility / futures of the self-signed CA just in case. Either way, if the private key of the RAIDUS cert gets compromised (commercial or self-signed), it's a world of hurt to get folks moved over in a secure way. Has anyone done this? Good or bad? Am I missing anything key? Next up will be client based certs, but that doesn't fix/resolve the above issue. Carl Oakes California State University Sacramento From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Eric Glinsky Sent: Monday, March 13, 2017 12:11 PM To: [email protected] Subject: [WIRELESS-LAN] Certificate for 802.1x Hi everyone, I’m looking for thoughts/opinions/experiences on 802.1x and security certificates. I dug through the archives from a few years ago, and from what I gather it isn’t even possible to use a 3rd-party cert so devices (iOS, OS X, Windows, Android) trust it automatically, but maybe someone has succeeded with this by now? If so, which CA would you recommend? For us, our GoDaddy wildcard cert failed to authenticate clients, so we went with DigiCert. That isn’t trusted by clients by default, offering no benefit over our domain-generated cert, with which all Apple and Windows 8/10 devices must be told to “trust,” Windows 7 fails to authenticate entirely, and Android just works. We have a Cisco WLC and Windows NPS. Thanks for any pointers you can give! - Eric This e-mail message is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL or PRIVILEGED material. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communications through this medium, please so advise the sender immediately. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
