Hi Thomas, Thomas Simmons wrote on 03.03.2013 03:28:
> The certification path for my cert is: My Cert > GoDaddy Secure > Certification Authority > Go Daddy Class 2 Certification Authority > > I added my certificate to the beginning of the chain file provided by > GoDaddy (used cat to ensure no errors) and pointed certificate_file to this. > I then selected the "Go Daddy Class 2 Certification Authority" under the > network profile. When this did not work, I imported the chain file into my > Trusted Root CAs and selected "GoDaddy Secure Certification Authority" in > the wifi profile. This also did not work. Lastly, I cleaned up my > certificate store, split apart the chain file into separate files, imported > "GoDaddy Secure Certification Authority" into my Trusted Root CAs, selected > the same in the wifi profile, and pointed certificate_file to my cert ONLY. > Does anyone see a reason this should not work? newer Windows versions do a fair bit of automagic when they have to deal with certificates, ie. o they do /not/ carry /a complete list of all/ Root-CA certificates that the system will eventually trust, instead they automatically download specific "pre-trusted" Root-CA certificates from some trusted Microsoft update server, once the user - doing a bit of internet browsing - encounters a server certificate that will eventually be validating its trust path to that Root-CA certificate /for the first time/. o they use the AIA (Authority Information Access) extension in the certificates (if present) to automatically download missing intermediate CA certificates from the URLs specified in the said certificates to auto-complete trustpaths. o they use the CDP (CRL distribution point) extension in the certificates (if present) to automatically download CRLs from the URLs specified in the said certificates. o they use the AIA (Authority Information Access) extension in the certificates (if present) to automatically ask an OCSP-responder for an up-to-date status of the said certificates. o they cache/store those downloaded bits of information My guess is that your Windows system run into some hen-egg-problem trying to download these things from the internet while not having a full internet connection. > Ideas on what to try next? If you have that same wildcard certificate running on an SSL-web-server, get your Windows system connected to the Internet and browse to the HTTPS address of that web server *with IE*. Since the system has full Internet access it should download and store/cache all bits it is needing to successfully validate your wildcard certificate. You can check the Windows CRL and OCSP cache using C:\> certutil -URLCache CRL C:\> certutil -URLCache OCSP Then disconnect the system and try re-connecting it using the supplicant with eap-tls authentication. The system should hopefully use the validation info it collected when it was online before since it is then encountering the same wildcard certificate as before and accept your RADIUS-server certificate. This would at least proof my theory. I'm not sure if knowing why it is broken will still help you to use your wildcard cert...at least for freshly set-up Windows systems which were never connected to the Internet or which never have seen your wildcard certificate before when connected to the Internet it will be difficult. Just my 2 cents. Best Regards Reimer p.s. You can clear the Windows CRL and OCSP caches using C:\> certutil -URLCache CRL delete C:\> certutil -URLCache OCSP delete -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team) DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-580 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
smime.p7s
Description: S/MIME Cryptographic Signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html