How come Apache HttpClient 4.4 rejects www.googleapis.com as a valid host name?

Question

I've recently switched to HttpClient 4.4 from 4.3 and I get the SSLPeerUnverifiedException saying:

Host name 'www.googleapis.com' does not match the certificate subject provided by the peer (CN=*.googleapis.com, O=Google Inc, L=Mountain View, ST=California, C=US)

The problem comes from the fact than HttpClient now uses the publicsuffix.org list for validation (see source code for SSLConnectionSocketFactory.java).

One way around this problem is to turn off the host name verification:

CloseableHttpClient httpClient = HttpClients.custom().
   setSSLHostnameVerifier(new NoopHostnameVerifier()).build();

...but I'm trying to understand why the wildcard is not matched by the client and why it's considered as too broad (reference).

The RFC2818 spec says:

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.

Does this mean that HttpClient 4.4 doesn't honor the spec?

Answer 1

This has nothing to do with wildcard matching per se. As of version 4.4 HttpClient checks certificate identity against the public domain suffix list maintained by Mozilla to ensure that wildcards in the certificate subject or alternative names apply to non-public domains only. For instance patterns as *.com or *.co.uk should be rejected as too broad to prevent their misuse.

For better or worse the PSL now also contains what the maintainers of the list refer to as 'private domains' (which is an awfully confusing term for a list of public domain suffixes). googleapis.com is one of such domains. HttpClient will handle 'private' domains correctly as of next feature release (4.5). For details see HTTPCLIENT-1613