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.

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.

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.