On 6/23/2015 5:30 PM, Dan Fandrich wrote:
> Thanks to a bug report from Stefan Kanthak about the download page robot
> failing to find some updated curl version, I stumbled onto a problem in how
> curl handles wildcard certificates (maybe). Stefan reported that curl using
> SChannel validates the certificate at https://skanthak.homepage.t-online.de/
> just fine, whereas when I built curl with recent versions of OpenSSL, GnuTLS,
> PolarSSL, wolfSSL and axTLS, it turns up validation failures (error codes
> 51, 60 and 77). curl with any one of the listed backends validates
> https://www.t-online.de/ without issue, which is a different (non-wildcard)
> certificate but signed by the same CA. Among browsers, Firefox, Opera and
> Chromium had no problem with any of them, but Konqueror, w3m and Chrome for
> Android didn't like the wildcard one.
>
> The report from https://www.ssllabs.com/ssltest/ shows no issues with the
> certificate itself, but it does show that the wildcard cert is supplied
> *without* a necessary intermediate cert, whereas the working site *does* supply
> the necessary intermediate cert. So, the problem that I originally thought was
> with wildcard cert handling may actually be due to the "missing" intermediate
> cert.
>
> However, some browsers handle this missing cert themselves. I haven't seen how
> they do that, though. Do they download the missing cert from the CA unprompted?
> Do they have the intermediate cert already in their trusted cert store? I'm not
> sure, but is this something that curl should be handling like the browsers or
> not? I always though a missing intermediate cert was a giant configuration
> problem, but that maybe that's a simplistic view.

I think you are right about the missing intermediate certificate being
the cause of his problems. Windows certificate store contains the
intermediate 'VeriSign Class 3 International Server CA - G3'. Even if it
didn't, the end certificate contains an AIA Certification Authority
Issuer URL that points to the intermediate. Windows in some cases (I
really don't recall all the specifics on this or whether it may relate
to curl and a quick search isn't helping) will automatically download a
missing certificate from the URL to do the verification. From what I can
see Firefox doesn't have that intermediate in its cert store and also
doesn't download it, and I can't connect to that website in Firefox
without first confronting the security exception dialog.

I put the root and intermediate in a bundle and then curl with OpenSSL
backend I can connect. Using OpenSSL directly then verifies ok as well:
openssl s_client -connect skanthak.homepage.t-online.de:443 -CAfile
t-online_ca_bundle.crt

Where the blame lies is a matter of opinion depending on who you think
is responsible for AIA issuer retrieval if anyone. In my opinion the
bottom line though is they should send the intermediate.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html