I've watched this thread with interest, but it went on rather a divergent course so I'll just reply to this initial one (somewhat belatedly).
So Andrew's original below is about https://support.apple.com/en-gb/HT211025, and true enough that's applicable for pre-installed root CAs, so those using commercial CAs for their Radius server cert need to pay attention as per the rest of this discussion. The recommendations, such as I've always understood them, and I think have come out during this thread, are: 1. create a private CA root cert with a very long life (lots of years) 2. use that to sign a server cert for your radius server with a shorter life (some handful number of years) 3. as a consequence, therefore, you don't obtain a cert from a commercial CA 4. use an onboarding tool (we use CAT) to enforce server-name pinning in the eduroam config and to deliver the private CA root cert to device 5. once the private CA root cert is installed on the client, we can change the radius server cert seamlessly at will, just so long as its subject is the pinned server-name and it is signed by the same installed private root cert [in theory] This is the arrangement we've had for nearly 5 years, a ~30 year private CA root cert, which issued a 5 year radius server cert. That expires at the start of next year so I am looking at changing now. Here's a good set of certificate recommendations from Geant: https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations, and while reviewing those I noticed something new at the end since the previous time I'd looked, which references this article: https://support.apple.com/en-us/HT210176 This claims that in iOS13/macOS 10.15, "all TLS certs .... (various conditions about 2048 bits, SHA-2, subject alt name) ... TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).". Which seems to suggest that even certs issued by a private CA root also fall under this restriction, and hence "Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail". Here's the curious bit. After my enquiries about that, engineers at JISC tried some experiments by setting the clock forward etc to see how these operating systems behaved, and couldn't discern any evidence that they would fail to auth even with a long certificate expiry. So now for the new radius cert I need to issue, I need to decide if I go with another 5 year one, with the possibility that an iOS upgrade might start to reject it at some point in the future, or stick with 2 years and the (relatively minor, if point 5 above holds) pain of changing the cert every other summer? You can probably read the whole discussion here: https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?A2=ind2007&L=EDUROAM-UK&O=D&P=835 Interested to see if anyone has any further insight, apologies if I missed it in the thread or elsewhere. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ________________________________ From: The EDUCAUSE Wireless Issues Community Group Listserv on behalf of Andrew Gallo Sent: Wednesday, August 19, 2020 14:28 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] New certificate expiration for certificates affecting 802.1X? Does anyone know if the new, shorter certificate expiration for TLS that Apple announced (and Google is following) will affect 802.1X authentication? Thanks -- ________________________________ Andrew Gallo The George Washington University ********** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community ********** Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community
