Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
davidearl opened this issue Jan 27, 2021 · 4 comments
Closed
Labels

Comments

@davidearl
Copy link

@davidearl davidearl commented Jan 27, 2021

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 bagder added the SSL/TLS label Jan 27, 2021
@bagder
Copy link
Member

@bagder bagder commented Jan 27, 2021

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
Copy link
Author

@davidearl davidearl commented Jan 27, 2021

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
Copy link
Author

@davidearl davidearl commented Jan 28, 2021

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 added a commit that referenced this issue Jan 28, 2021
... because it turns out several servers out there don't actually behave
correctly otherwise.

Reported-by: David Earl
Fixes #6540
@bagder
Copy link
Member

@bagder bagder commented Jan 28, 2021

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.

@bagder bagder closed this in 60de76e Jan 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants