Upper case characters in given domain name over https causes SSL certificate error #6540
Comments
Hah, that's a curious error indeed. It turns out that because curl passes on the host name exactly as given in the URL in the SNI field, this server then returns back a certificate that doesn't contain a SAN that matches this domain name. If we instead pass on the same name in the SNI, only lowercased, it instead returns a different certfiicate with a SAN that matches and thus is OK. This server does not comply with RFC 6066 section 3 which clearly says about the SNI host names:
In other words: this is not a curl issue. This issue could possibly be worked around if for example curl always lower cased the host name, but it feels like the wrong way forward here. |
So it does. I'd only looked at the cert in a browser, but Chrome seems to lowercase it first, so it gets the correct cert. So it looks like the hosting provider here isn't doing a case-insensitive comparison. Thanks for spotting that, I'll pass it on to the originator. |
I've done a bit more digging. I tried a few other domain names with upper case. Most worked, including some I know to be serviced with Apache httpd. However, I hit one more that failed: https://Map.cam.ac.uk . This one I know to be serviced by a proxy, Pulse Traffic Manager https://www.pulsesecure.net/products/virtual-traffic-manager/ . I suspect, though I can't tell, that Weebly (whose certificate was returned for the original domain) uses the same product, and I suspect that is where the bug may be. However, browsers I've tried all manage to connect. I think they are pretty universally lower-casing the domain name that they put in the SNI Hostname (and indeed everywhere else). While I agree with you that lowercasing doesn't feel right from a purist point of view, if there is a widely used product out there that doesn't handle this properly and browsers work around that, it might be sensible for cURL to do the same just from a browser-compatibility viewpoint. Perhaps it could be an option? In any case, I've worked around this by lowercasing the domain name part of the URLs I am given before presenting them to cURL. |
... because it turns out several servers out there don't actually behave correctly otherwise. Reported-by: David Earl Fixes #6540
It feels wrong to give in to this, but if it makes it less likely to fail and you already in this quick check could find >1 example of wrong-doings, then I think it could be worth accepting that we are better off lowercasing the host name for SNI. |
I did this
curl -I "https://www.CambridgeEarlyMusic.org/"
I expected the following
HTTP/1.1 200 OK
etc
I got:
Presumably cURL is comparing the domain name given with the domain names in the certificate verbatim, rather than case-insensitively. Domain names are supposed to be case insensitive.
Oddly
curl -I "https://www.eXaMpLe.com/"
does work, but it is http/2 so maybe that makes a difference.curl/libcurl version
(also fails in the same way in the cURL PHP module)
operating system
Linux cameodev 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
(and others)
The text was updated successfully, but these errors were encountered: