HPO ontology terms failing certificate validation in content negotiated access

[markwilkinson]

Hi all!

Not sure if this is the right place to report this, but...

Looks like the certificate at JAX isn't configured properly. Negotiation for text/turtle on http://purl.obolibrary.org/obo/HP_0001270 returns:

• Ignoring the response-body
• Connection #0 to host purl.obolibrary.org left intact
• Issue another request to this URL: 'https://hpo.jax.org/app/browse/term/HP:0001270'
• Trying 64.147.57.24:443...
• Connected to hpo.jax.org (64.147.57.24) port 443 (#1)
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /home/osboxes/Anaconda/ssl/cacert.pem CApath: none
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS handshake, Certificate (11):
• TLSv1.2 (OUT), TLS alert, unknown CA (560):
• SSL certificate problem: unable to get local issuer certificate
• Closing connection 1 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

Please tell me if I should report this elsewhere.

Cheers all!

[matentzn]

@drseb @gouttegd is this related to the issue we were discussing on slack yesterday? Cc @pnrobinson (btw this is not an OBO issue this is an HPO issue, but we can keep it open here for now).

[gouttegd]

@matentzn Yes, same problem: The web server at hpo.jax.org is only sending its own (leaf) certificate, without the chain of certificates needed to validate it. That’s what curl is saying with the error message “unable to get local issuer certificate”.

[gouttegd]

To visualise the problem, here’s what happens with www.jax.org (which is correctly configured):

$ openssl s_client -legacy_renegotiation -showcerts -connect www.jax.org:443 < /dev/null
[...]
Certificate chain
 0 s:C = US, ST = Maine, L = Bar Harbor, O = The Jackson Laboratory, CN = *.jax.org
   i:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 14 15:47:49 2022 GMT; NotAfter: Mar 13 15:47:49 2023 GMT
-----BEGIN CERTIFICATE-----
MIIGuzCCBaOgAwIBAgIQILuEPqAJbkqQUsef3lLZSzANBgkqhkiG9w0BAQsFADCB
[...]
xCT/MWb3lhVpI2W7stgGDuWCHeSL7oL1iBdIChFpQZFE2x3LYDVdFg4F71unac8=
-----END CERTIFICATE-----
 1 s:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
   i:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Oct  5 19:13:56 2015 GMT; NotAfter: Dec  5 19:43:56 2030 GMT
-----BEGIN CERTIFICATE-----
MIIFDjCCA/agAwIBAgIMDulMwwAAAABR03eFMA0GCSqGSIb3DQEBCwUAMIG+MQsw
[...]
Lcw=
-----END CERTIFICATE-----
 2 s:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2
   i:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul  7 17:25:54 2009 GMT; NotAfter: Dec  7 17:55:54 2030 GMT
-----BEGIN CERTIFICATE-----
MIIEPjCCAyagAwIBAgIESlOMKDANBgkqhkiG9w0BAQsFADCBvjELMAkGA1UEBhMC
[...]

I’ve removed ([...]) most of the output for clarity, but observe that the server has replied with a chain of 3 certificates: its own (certificate 0 s:C = US, ST = Maine, L = Bar Harbor, O = The Jackson Laboratory, CN = *.jax.org), the intermediate certificate that issued it (certificate 1 s:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K), and the root certificate of the certification authority (certificate 2 s:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2).

This gives the client all that is needed to check the validity of the first certificate.

Now here’s what happens with hpo.jax.org:

$ openssl s_client -legacy_renegotiation -showcerts -connect hpo.jax.org:443 < /dev/null
[...]
Certificate chain
 0 s:C = US, ST = Maine, L = Bar Harbor, O = The Jackson Laboratory, CN = *.jax.org
   i:C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 14 15:47:49 2022 GMT; NotAfter: Mar 13 15:47:49 2023 GMT
-----BEGIN CERTIFICATE-----
MIIGuzCCBaOgAwIBAgIQILuEPqAJbkqQUsef3lLZSzANBgkqhkiG9w0BAQsFADCB
[...]
xCT/MWb3lhVpI2W7stgGDuWCHeSL7oL1iBdIChFpQZFE2x3LYDVdFg4F71unac8=
-----END CERTIFICATE-----

The certificate “chain” sent by hpo.jax.org is not a chain at all, it contains only the first certificate. That is the problem.

[gouttegd]

You can still connect to hpo.jax.org with a web browser and not see the issue because this kind of misconfiguration (invalid or missing certificate chain) is so frequent that most (if not all) web browsers have incorporated a workaround for it.

Web browsers keep a local cache of all the intermediate certificates that they encounter when the user is surfing the web (intermediates certificates sent by correctly configured servers, such as www.jax.org). When they come across a server that only sends them their own certificate, the browsers try to look up in their local cache to see if they already have an intermediate certificate that they can use to verify the server’s certificate. Most of the time they do (there’s only a limited number of certification authorities, so it’s quite likely that the browser has already got the intermediate certificate from somewhere else), and so the problem is silently ignored.

But try to connect to hpo.jax.org with a “fresh” browser with a clean cache (e.g. on a newly installed machine), and you will run into the problem.

And of course you will also run into the problem every time you try to connect with non-browser clients such as curl, wget, etc., because they do not implement the workaround describe above.

[markwilkinson]

Also with client libraries in the various languages.

I just solved this exact problem for my own server a couple of days ago. A straightforward way to get the information you need is to surf to the site using a browser, and click on the "lock" icon, then ask the browser to show you the certificate chain that it knows about. That info can be copy/pasted into the ceretificate .pem file, and voila! (I'm sure that isn't the CANONICAL way to get the information, but for me it was the fastest! :-) )

[nlharris]

Since this isn't an OBO issue, can we move this to the HPO tracker? https://github.com/obophenotype/human-phenotype-ontology/issues

[matentzn]

Not easy to move accross orcs, unless you have access to both orgs and zenhub installed

[nlharris]

I could create a stub ticket there and point to this one for details

[pnrobinson]

@nlharris -- probably this one https://github.com/TheJacksonLaboratory/hpo-web

[nlharris]

Ok, I created a ticket there: https://github.com/TheJacksonLaboratory/hpo-web/issues/207 Will leave this one open for now

[iimpulse]

Hi @gouttegd, can you confirm this is working as expected now?

[gouttegd]

@iimpulse : No, it seems the problem is still there. The hpo.jax.org host is still sending only its own certificate without a proper certificate chain, so it still cannot be validated.

[iimpulse]

Hi @gouttegd,

Using the openssl stuff we had our IT do some certificate re-linking. I'm seeing the chain resolve on my end can you confirm?

[gouttegd]

@iimpulse : Indeed, I see it working from here as well. :)

[iimpulse]

Great @gouttegd thank you for your help :) and thank you @markwilkinson for the report much appreciated. This can be closed @matentzn .. related https://github.com/TheJacksonLaboratory/hpo-web/issues/207

[nlharris]

Thanks, all!

[matentzn]

Nice thank you!

[drseb]

Awesome!

[markwilkinson]

Thanks all! however, all that for naught... it seems that HPO terms don't respond to content-negotiation anyway LOL! It always comes back as HTML.

No worries - I'll just construct an ontobee URL to get what I need.

Cheers all! Thanks for all your time!

[cmungall]

Hi @markwilkinson! I don't think ontobee supports conneg. See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5210626/ for a discussion of the XSLT based method. But you do get RDF/XML back in the response regardless of accept parameters, which is what you want I expect.

Note there is currently no expectation that any OBO class PURL returns RDF/XML, conneg or otherwise. HPO is not alone in supporting only HTML. If you think there should be guidelines on this tracker: https://github.com/OBOFoundry/OBOFoundry.github.io/issues

You may also be interested in https://github.com/OntoZoo/ontobee/issues/122

[iimpulse]

@markwilkinson Is there something specific you are trying to accomplish? I maintain the site and the api.