Task #11566 (closed)
Bug: UpgradeCheck.java fails when using HTTPS
Reported by: | bpindelski | Owned by: | mtbcarroll |
---|---|---|---|
Priority: | minor | Milestone: | 5.0.0-rc1 |
Component: | Services | Version: | 5.0.0-beta1 |
Keywords: | n.a. | Cc: | jamoore, jburel |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | 0.0d |
Sprint: | OMERO 5 Beta 2 (1) |
Description
When an https:// URL is used as omero.upgrades.url, the class responsible for making the call throws this:
2013-10-23 14:01:58,348 ERROR [ ome.system.UpgradeCheck] ( main) Error reading from url: https://www.openmicroscopy.org/qa2-staging/registry/hit/?version=5.0.0-beta1-DEV-ice34;os.name=Linux;os.arch=amd64;os.version=3.11.0-12-generic;java.runtime.version=1.7.0_45-b18;java.vm.vendor=Oracle+Corporation "java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty"
It has to be fixed so that both HTTP and HTTPS protocols are supported.
Change History (13)
comment:1 Changed 10 years ago by mtbcarroll
- Owner set to mtbcarroll
comment:2 Changed 10 years ago by mtbcarroll
- Status changed from new to accepted
comment:3 Changed 10 years ago by mtbcarroll
- Sprint set to OMERO 5 Beta 2 (1)
comment:4 Changed 10 years ago by mtbcarroll
- Cc jburel added
comment:5 Changed 10 years ago by bpindelski
mtbcarroll: I'm currently using Oracle JDK 7. Indeed, what you mentioned is highly likely - https://www.openmicroscopy.org/qa2-staging uses TERENA SSL as the CA. I'm not sure if that CA is part of a trust chain that Oracle provides out of the box. If this is the source of the problem, then probably this ticket can be closed (unless we indeed decide to switch of host name verification).
comment:6 Changed 10 years ago by mtbcarroll
Let's get a policy verdict on the host name verification. I doubt we're very worried about people doing evil SSL trickery to fool the upgrade checker. Then it won't matter what people's JRE's come with. (Some installations come with no CAs set at all!)
comment:7 Changed 10 years ago by jamoore
I would think if we could A) always downgrade to HTTP for speed or failing that, B) be as accepting of weird certs as possible, that would be ideal.
comment:8 Changed 10 years ago by mtbcarroll
https://github.com/openmicroscopy/openmicroscopy/pull/1662 should achieve (B): bpindelski, perhaps you could try it out? (A) is interesting; I wonder if it's worth the extra complication of falling back to HTTPS if HTTP doesn't work out for some reason (maybe they picked HTTPS for good reason) (or, the other way around, depending on which we try first).
comment:9 Changed 10 years ago by mtbcarroll
bpindelski, how is the javax.net.ssl.trustStore property set in Java for you? Is it actually pointing to a file that has the TERENA SSL certificate?
comment:10 Changed 10 years ago by bpindelski
Executing System.out.println(System.getProperty("javax.net.ssl.trustStore")); returns null which is surprising (according to http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Customization). There are two cacerts files present on my OS - one in /etc/ssl/certs/java and another in /usr/lib/jvm/java-7-oracle/jre/lib/security/. Neither of those has the TERENA cert (checked with keytool). I guess we can close this ticket as this is indeed a highly-OS and configuration dependant issue. The root of the CA hierarchy for TERENA is Comodo, which is by default (AFAIU) not included in the trusted CAs list in Java.
comment:11 Changed 10 years ago by mtbcarroll
Thank you for checking that. Assuming that you've just gone for the default way your JRE gets installed, rather than pursuing something rather more idiosyncratic, this may well be an issue that affects and confuses other users if we leave it unaddressed: I'll spend a bit more time to try to see if we can get around this issue in the class itself.
comment:12 Changed 10 years ago by mtbcarroll
- Resolution set to fixed
- Status changed from accepted to closed
fixed by above PR
comment:13 Changed 10 years ago by Josh Moore <josh@…>
- Remaining Time set to 0
(In [dd5e29ac573dd62efdb5000805c63946c2ad828d/ome.git] on branch develop) Merge pull request #1662 from mtbc/trac-11566-disable-ssl-verify
fix #11566: disable host name verification for upgrade checks over HTTPS
From what kind of system are you trying this? By which I am really asking, does the JRE have the appropriate certificate authorities in the key store? My suspicion is that the host name just isn't verifying for you. I can disable this SSL host name verification altogether in UpgradeCheck if need be: is that a thing we want to do?