Problem Using GoDaddy Wildcard Certificate

Reimer Karlsen-Masur, DFN-CERT karlsen-masur at
Mon Mar 4 13:12:58 CET 2013

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

> 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

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 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



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,, 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the Freeradius-Users mailing list