• In this case of this issue, HttpURLConnection is returning an HTTP status code of -1, which indicates that 'no code can be discerned from the response (i.e., the response is not valid HTTP).'
• The specific exception causing this is 'java.security.cert.CertificateException: No subject alternative DNS name matching {HOST}

  found.' This seems to be an SSL validation related issue, so we be able to avoid this error by altering the current HTTPS connection configuration.

• More useful info here.

Please see my changes here. They prevent the error described in this issue by reducing SSL handshake verification stringency.

Request:

I'd like to better understand why certain data files are causing this problem.

Can you please provide example(s) of where the server's certificate does not properly match the domain name mentioned in the data file URL, causing the SSL validation error?

Could you indicate the particular method call where the exception is thrown? (Show a stacktrace?)

This code seems risky because it appears to turn off all host verification:

HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
            public boolean verify(String hostname, SSLSession session) {
                return true;
            }
       });   

Is there a more targeted approach we can use instead?

Returning to "To-Do" for Philip Badzuh to investigate further..

Sample problematic file:
https://dashr2.lisanwanglab.org/tracks/hg38/DASHRv2.hg38.annot.pos.bigBed

Inspecting the server's x509 SSL certificate when making a request for the above resource, I noticed that the subject common name was not dashr2.lisanwanglab.org as expected, but advp.lisanwanglab.org. The same was true for the subject alternative name field. It seems that for some reason the server is returning a cert for the wrong subdomain. What is even more confusing is that this behavior is inconsistent across clients. For example this behavior occurs when IGB makes the requests as well as when the openssl tool is used to view the certificate e.g.

openssl s_client -showcerts -connect dashr2.lisanwanglab.org:443

Making the same request using the browser or CURL , however, results in the proper certificate being returned by the server - with a common and alternative name of dashr2.lisanwanglab.org. It may be that under the the browser and CURL experience the same error, but fix it under the hood by making some sort of secondary request to the server for a different certificate matching the correct subdomain, however, I am unsure of how to check this.

In any case, one potential solution to this issue could be to modify the HostnameVerifier I have implemented to allow all certificates that have the same domain and TLD, regardless of subdomain. I think this would both solve this issue and maintain security. Please let me know what you think [~aloraine].

Thank you for the very clear discussion.
I have a an additional questions regarding how the interaction between the server and client when the client is curl or a Web browser. How do you know that they are obtaining the correct certificate? Is it because the browser and curl accept the authenticity?

Using the browser, you can inspect the certificate being used by clicking on the lock to the left of the URL. When using CURL, the -v flag can be passed for verbose output, which includes basic updates of the SSL handshake steps, including details about the certificate being used.

I'm confused about there being multiple certificates returned by the site. My understanding from having requested and installed certificates is that you only get one! And you can often purchase a "star" certificate that will cover every subdomain, e.g., foo.bioviz.org or bar.bioviz.org would be validated the same "star" certificate.

However, looking at the above certificates mentioned in the previous comments, it looks like the site is using a public service ("let's encrypt") that provides certificates for free, in some kind of dynamic way. I wonder if the site's configuration is messed up or incorrect in a minor way that affects IGB and openssl, but not the other applications, explaining why the site maintainers perhaps never noticed the problem. For this latter task, let's make a new ticket to investigate "let's encrypt".

Maybe we ought to investigate how the "let's encrypt" configuration is done? Also, [~aloraine] is interested in how "let's encrypt" works in case we want to use for our Web applications, as well. Why? It's because the lab has multiple domains, for only a few of which do we currently purchase certificates, as they are costly. If we knew how to use "let's encrypt," we could provide SSL level security for every site, not just "bioviz" and the few others for which we purchase certificates.

To solve the immediate problem, I agree ([~aloraine]) that you should do this: "allow all certificates that have the same domain and TLD, regardless of subdomain".

Make new tickets for these new tasks.

I have made new tickets for these tasks in IGBF-3000 and IGBF-3001. Closing this issue.