Maybe not the exact same issue, but we had to deal with a similar thing with the InCommon-provided certs for a while since the common name of some of the intermediate certs were the same even though the certs themselves were not, and there were a couple possible chains back up to a root certificate. In our case it was the Macs that didn’t like whatever chain had been chosen by some of our server administrators, but once we standardized on what chain to use everyone was happy. And it was a learning experience for some people on how to analyze certificate chains. :)
-- Julian Y. Koh Associate Director, Telecommunications and Network Services Northwestern Information Technology 2020 Ridge Avenue #331 Evanston, IL 60208 +1-847-467-5780 Northwestern IT Web Site: <http://www.it.northwestern.edu/> PGP Public Key: <https://bt.ittns.northwestern.edu/julian/pgppubkey.html> On Sep 14, 2019, at 13:58, Johnson, Neil M <neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu>> wrote: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.sectigo.com_Com-5FKnowledgeDetailPage-3FId-3DkA01N000000rgSZ&d=DwMFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=ITCdJ8r7Mvmi4B5IfM-uUxBCe5N77i8k9OcsASk91Zg&m=GtNrtlYJqbnKTegFSNL8fXGCkM65KC4S0aY9pPB89NM&s=AiyMKfqeu3WCFI3OiqtSpDK4wc1yOXWi_1_n-3ECq1M&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_drawings_d_1P6-5FZbsbOMeRJEYwX-5F-5Fs9gJWC5IXgnr7LDUrc7ys8oDs_edit-3Fusp-3Dsharing&d=DwMFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=ITCdJ8r7Mvmi4B5IfM-uUxBCe5N77i8k9OcsASk91Zg&m=GtNrtlYJqbnKTegFSNL8fXGCkM65KC4S0aY9pPB89NM&s=Hf29UmsN5VKH_ALYSXuSyiUzp7Y8FfINwXPtV0kddUI&e=> ) 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.educause.edu_community&d=DwMFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=ITCdJ8r7Mvmi4B5IfM-uUxBCe5N77i8k9OcsASk91Zg&m=GtNrtlYJqbnKTegFSNL8fXGCkM65KC4S0aY9pPB89NM&s=N9YsyjiE1qiUdMM6jqBB0tS9BmrltT3fgeHPozuWbW8&e=> ********** 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
