Javax Net Ssl Sslpeerunverifiedexception Peer Not Authenticated Httpclient

Problem with SSL subject matching in Apache's HttpClient

Let's say you are having a wonderful day at work as a Java developer, building some integration to Google or Amazon APIs, and when testing your integration you face one of the following errors:

          javax.net.ssl.SSLException: Certificate for <www.googleapis.com> doesn't match any of the subject alternative names: [*.googleapis.com, *.clients6.google.com, *.cloudendpointsapis.com, cloudendpointsapis.com, googleapis.com]          javax.net.ssl.SSLPeerUnverifiedException: Host name 's3.amazonaws.com' does not match the certificate subject provided by the peer (CN=s3.amazonaws.com, O=Amazon.com Inc., L=Seattle, ST=Washington, C=US)        

Wait a second! Have Google and Amazon some certificate problems? Why does my application not trust a very common API?

There is actually a problem on how the Apache HttpComponents HttpClient version 4.4 handles SSL wildcards in the SSL certificate identity matching process.

Wildcards in certificate subdomain subject names are only allowed as long as the suffix after the wildcard is not a public domain root. For example, you would not want to match an identity based on a subject name like *.com; since it would end up matching nearly any acquirable domain on the web.

For that purpose, there must be some kind of verification to calculate what suffixes are part of the public domain. One might assume that as soon as there are two points it is a private domain suffix; but there are plenty of public domain suffixes with more components such as .co.uk for companies in the United Kingdom or .ac.gov.br for the Governmental organizations in the Acre state of Brazil, .yamada.fukuoka.jp for the Yamada city in the Fukuoka prefecture of Japan.

Unfortunately there is no algorithmic way to calculate the longest domain public suffix from a hostname. That is why Mozilla started the Public Suffix List (PSL) initiative as a community resource. This was initially stated to avoid the use of supercookies, where a website would be able to create a cookie at the second level of subdomain, spreading them throughout all sites under for example .co.uk. Nowadays the Public Suffix List is used for way more cases; cookie-setting, domain highlighting, navigability and our culprit today: SSL wildcards.

          // ===BEGIN ICANN DOMAINS===
… co.uk
// ===END ICANN DOMAINS===
// ===BEGIN PRIVATE DOMAINS===
… googleapis.com
// ===END PRIVATE DOMAINS===        

The PSL is actually two different lists: one containing ICANN domains and one with private domains. Depending on the use case of the PSL, one should only consider the ICANN domains, or take all the registered suffixes (that is why companies submit what they themselves consider public company suffixes). For the SSL wildcard use case, the private domain suffixes should not be considered, since the same company will have control over the whole subdomain and they should be able to use certificates that apply throughout all their subdomains.

Apache's HttpComponents HttpClient version 4.4 did not make this difference, not matching identities based on the wildcard alternative names when they were listed on the private part of the PSL. This results in the HttpClient not accepting the signing on HTTPS traffic to domains such as: oauth2.googleapis.com (because googleapis.com is in the PSL, and the certificate has *.googleapis.com in its subject alternatives) or s3.amazonaws.com. These are just some very common domains for APIs that are called by HTTP(S) clients all over the world.

This issue was solved in Apache's HttpComponents HttpClient version 4.5 (Everything is somewhat narrated by the comments on the fix for the http client at Apache's Jira), so the solution is just a matter of upgrading your dependencies. And that is at the end of the day the most important takeaway, keep your dependencies fresh and updated.

Daniel Gómez Villanueva

Javax Net Ssl Sslpeerunverifiedexception Peer Not Authenticated Httpclient

Source: https://medium.com/pricerunner-tech/problem-with-ssl-subject-matching-in-apaches-httpclient-48b196931772

Share this post