The maximum for a public certificate is changing on 1 March 2018 to 27 months, with suggestions that it might drop down to 13 months later on:
https://www.digicert.com/shortening-validity-periods-for-ov-dv-certificates/ https://www.digicert.com/blog/cabforum-votes-shorten-certificate-lifetime-validity-periods-impacts/ One distinction about using a private CA is that you can have an extremely long root CA, and then have shorter lived certificates signed by that CA that are rotated. However, without onboarding to install the CA for the SSID vs just trusting the certificate (which I know is what macOS and iOS do) then it's not much of a distinction in practice. This also means I have the same certificate installed on all RADIUS servers. On EAP-TLS, we briefly tried enabling Windows Credential Guard last week on a few IT laptops, and immediately had to turn it off as it breaks MSCHAPv2 authentication: https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-considerations I had a meeting with Microsoft yesterday and they said that certificate auth is really the only secure answer. Since our devices are owned by the school, we'll probably look at setting up a private Windows CA first rather than going down the CloudPath or SecureW2 path. On 31/10/17 12:46, Craig Simons wrote: > These are very helpful and thoughtful points to consider. I think of > this issue using the angel and devil on the shoulder analogy. On one > shoulder, as a security conscious engineer (and technophile) I see why > shorter certificates (I believe the maximum is 39 months now?) with all > allowances made for security are the necessary evil. On the other, we > want the campus WiFi experience to be easy, simple and as painless for > the user (and Service Desk people) as possible. In many ways, a good > onboarding tool lets you have your cake and eat it too... but our recent > experience has shown us that even this has it’s limits. > > I suppose the “correct” answer is the one that is supportable. This > requires the Service Desk/Desktop Support people to be willing and able > to handle the hordes when they arrive in the interests of security > “tough love”. > > However, I still believe there is a large role to play for EAP-TLS in > the future. In the IoT world, the willingness of users to put their > personal credentials on low-end devices is a security threat before even > getting to the certificate conversation. > > Thanks to all that replied! > > *Craig Simons* > Network Operations Manager > > Simon Fraser University | Strand Hall > 8888 University Dr., Burnaby, B.C. V5A 1S6 > T: 778.782.8036 | M: 604.649.7977 > > > SFU SIMON FRASER UNIVERSITY > IT SERVICES > > >> On Oct 30, 2017, at 1:19 PM, Mike Atkins <[email protected] >> <mailto:[email protected]>> wrote: >> >> We are option 3 with 3 year certs. We were in the same boat as Craig >> just over a year ago. We moved to a different onboarding utility and >> different CA. It is a long story so feel free to hit me up offline. >> That said, in the future we will likely end up using both options 3 & >> 4 to be flexible with device/owner/use. >> >> >> >> >> >> >> >> */Mike Atkins /* >> Network Engineer >> Office of Information Technology >> University of Notre Dame >> Phone: 574-631-7210 >> >> >> >> >> >> ---- .__o >> ----- _-\_<, >> --- (*)/'(*) >> >> >> >> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv >> [mailto:[email protected] >> <mailto:[email protected]>] *On Behalf Of *Craig Simons >> *Sent:* Monday, October 30, 2017 2:22 PM >> *To:* [email protected] >> <mailto:[email protected]> >> *Subject:* [WIRELESS-LAN] Radius certificate length vs. onboarding >> opinions >> >> >> >> All, >> >> >> >> I know the subject has been broached on the list a few times before, >> but I’m looking for informal opinions/survey about how you are >> deploying your Radius EAP certificates for PEAP/TTLS users (non-TLS). >> We use Cloudpath to onboard users, but recently went through a >> difficult renewal period to replace our expiring certificate. As we >> had configured all of our clients to “verify the server certificate” >> (as you should from a security perspective), we found that iOS/MacOS >> and Android clients did not take kindly to a new certificate being >> presented. This resulted in quite a few disgruntled users who couldn’t >> connect to WiFi as well as a shell-shocked Service Desk. To help >> prevent this in the future (and because we are moving to a new Radius >> infrastructure), what is the consensus on the following strategies: >> >> >> >> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard >> with "verify server certificate" enabled >> >> >> >> Option 2: Removing all traces of “verify server certificate” from >> OnBoard configuration and use 2-year certs from CAs >> >> >> >> Option 3: Use 2-year CA certificates, enable “verify server >> certificates” and educate/prepare every two years for connection issues. >> >> >> >> Option 4 (probably the best long-term answer): Move to private PKI and >> EAP-TLS. >> >> >> >> Opinions? -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
