Update, The problem was I was using the wrong InCommon Intermediate CA cert (I was using an older SHA512 cert which had been upgraded to a SHA384). Once I straightened that out, the broken clients started working. But that leaves the question why most other clients were working with a broken cert chain.
-Neil -- Neil Johnson 319 384-0938 neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu> From: The EDUCAUSE Wireless Issues Community Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Neil Johnson <neil-john...@uiowa.edu> Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Date: Saturday, September 14, 2019 at 1:58 PM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: [External] [WIRELESS-LAN] InCommon certificate trust chain issues with upgraded Windows Systems This problem has been vexing us for a few weeks, so I’d thought I’d pass along my message to Microsoft and Sectigo in case others run into the same issue. Thanks. -Neil The authentication has been temporarily resolved, BUT only temporarily. The cause of the problem involved many factors: First, The server certificate issued by Sectigo utilizes cross-signed certificates: https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ This means that there are two trust chain paths that can be used to validate the server certificate: (see diagram at https://docs.google.com/drawings/d/1P6_ZbsbOMeRJEYwX__s9gJWC5IXgnr7LDUrc7ys8oDs/edit?usp=sharing ) Second, Since the ADDTrust Root CA certificate used in Path #1 expires May 30th of 2020, so I had the RADIUS Server (Aruba ClearPass) configured to send the server and intermediate cert for Path #2. This worked for the majority of systems on campus. Third, However, some customers upgrading from previous versions of Windows (7, 8, and Windows 10 versions previous to 1809) began having authentication issues because of this. It appears that the Windows systems are unable to validate the certificate chain in Path #2. This was confirmed by system traces and packet captures between the client and the RADIUS Server. Temporary solution: I reconfigured the RADIUS server to send the server and intermediate certs for Path #1. This seems to have resolved the issue for the majority of our customers. The long term problem: The AddTrust Root CA certificate expires May 30th, 2020. Customers systems will have to validate the server certificate using Path #2. My concern is that this will break certificate validation (and thus wireless authentication) for many of our customers after the ADDTrust Root CA certificate expires. Action Items: * Microsoft & Sectigo – Needs to find out what is preventing upgraded Windows systems from validating the server certificate via Path #2. * The University of Iowa – Needs to develop a risk mitigation plan prior to May 30th, 2020 (Including the possibility of moving to a private PKI over winter break). I’m happy to help collect additional information required to troubleshoot this issue. Thanks for everyone’s efforts in troubleshooting this issue. If you have any questions please feel free to contact me. -Neil Neil Johnson Network Engineer The University of Iowa +1 319 384-0938 ********** 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
