So last week I got a message from a collegue, saying that a production environment for a service provider was down. A temporary fix was for us to change our config and point to a backup site of the service provider. So we tried calling the backup site to make sure it was up, and everything looked fine. So we changed the config, but when our code made calls to the SP, we saw the following message in our logs:

javax.net.ssl.SSLPeerUnverifiedException: Host name 'foobar.azurewebsites.net' does not match the certificate subject provided by the peer (CN=*.azurewebsites.net)

Since everyone at our company knows that I'm the "security guy", this was naturally bounced to me. My first instict was to check if the TLS implementation our code used even had support for wildcard domains in certificates. After some googling and answers of variyng quality I landed on the JSSE (Java Secure Socket Extension) documentation page and saw that wildcards were in fact supported. So then I figured it could be something strange with the SANs (Subject Alternate Name) on the certificate, but quickly proved this wrong be running:

openssl s_client -connect foobar.azurewebsites.net:443

Then copying the certificate to a file and inspecting it with:

openssl x509 -text -noout -in cert.crt

But this showed that all seemed right with the cert at least. I got a message that the main production environment was up again so this was no longer an urgent matter, but it still eluded me as why the above message would be printed.
After going home and eating dinner I did some more googling and discussed the issue with another collegue, and finally I found this issue with the apache httpclient, that stated that something called Mozilla Public Suffix List. This is a list of domain suffixes for which wildcard certificates should be considered invalid, like *.com ,*.se or *.tumblr.com, since otherwise theses certs could be used on literally all .com domains without as much as a warning. So checking the libs showed that we used httpclient 4.4, which checks this list when validating wildcard certificates. And after a search in the list, lo and behold *azurewebsites.net.
To verify that this was in fact the issue, my collegue compiled some code with first httpclient 4.4, which showed the error, and then with httpclient 4.3, which connected with no issue.
So in my mind the question is not how can we disable the MPSL, but instead how was someone able to obtain a valid certificate with a wildcard domain for a domain on the list...