On Oct 31, 2012, at 8:55 AM, Brad Chapman wrote:
Hi all; I ran into SSL certification errors when using Java to connect to Galaxy main via the API. My knowledge of this stuff is minimal, but I did some searching and discovered that the certificate chain on Galaxy main is a problem:
https://www.ssllabs.com/ssltest/analyze.html?d=main.g2.bx.psu.edu
Looking at the chain with openssl shows a swap of the AddTrust and Internet2 certificates:
$ openssl s_client -connect main.g2.bx.psu.edu:443 CONNECTED(00000003) depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/postalCode=16802/ST=PA/L=University Park/O=The Pennsylvania State University/OU=Center for Comparative Genomics and Bioinformatics/CN=bigsky.bx.psu.edu i:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA 1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 2 s:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root ---
As a result, more picky verification mechanisms fail because of the self signed certificate in the middle of the chain instead of as the root.
It appears you can fix this by adjusting the order of certificates in nginx:
http://webmasters.stackexchange.com/questions/27842/how-to-prevent-ssl-certi... http://nginx.org/en/docs/http/configuring_https_servers.html#chains
Hope this helps, Brad
Hi Brad, Thanks for catching this. It's been fixed. --nate
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: