Upper case characters in given domain name over https causes SSL certificate error

[davidearl]

I did this

curl -I "https://www.CambridgeEarlyMusic.org/"

I expected the following

HTTP/1.1 200 OK
etc

I got:

curl: (60) SSL: no alternative certificate subject name matches target host name 'www.CambridgeEarlyMusic.org'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

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

curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

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

[bagder]

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:

"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte
string using ASCII encoding without a trailing dot. This allows the
support of internationalized domain names through the use of A-labels
defined in [RFC5890]. DNS hostnames are case-insensitive.

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.

[davidearl]

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.

[davidearl]

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.

[bagder]

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.