Description
This issue is copy & pasted from haskell/wreq#84 and example modified for http-client-tls.
badssl.com tests have wildcard certificate with common name *.badssl.com and Subject Alternative Names badssl.com and *.badssl.com. http-client-tls misinterpretes how wildcard certificates should be handled:
*Main> :m Network.HTTP.Client Network.HTTP.Client.TLS
Prelude> manager <- newManager tlsManagerSettings
Prelude> request <- parseRequest "https://wrong.host.badssl.com"
Prelude> httpLbs request manager
Response {responseStatus = Status {statusCode = 200, statusMessage = "OK"}, responseVersion = HTTP/1.1, responseHeaders = <reponse removed>...
RFC2818 states that:
Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.
Chrome, Firefox and Safari don't allow connection to this test host.
This was found with TryTLS test tool: https://github.com/ouspg/trytls