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.

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-06-23