[IGBF-2008] IGB fails to connect to public CyVerse Data - JIRA UNCC

Details

Type: Connection Issue
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Affects Version/s: None
Fix Version/s: None
Labels:
None

Story Points:
1
Epic Link:
Connect Integrated Genome Browser and CyVerse
Sprint:
Fall 2019 Sprint 2, Fall 2019 Sprint 3

Description

Situation:
After maintenance to CyVerse systems, IGB stopped being able to connect and retrieve data from public CyVerse files from https://data.cyverse.org/dav-anon/iplant/home/.

When IGB tried to load data from the CyVerse URL, it would ask if the user trusts the certificate - 1.2.840.113549.1.9.1=#1620726f6f74407230336330387531382d6461762d312e637976657273652e6f7267,CN=r03c08u18-dav-1.cyverse.org,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--,

If the user consented, IGB would then fail to connect and would issue a warning to the user saying the URL failed to load.

Confusingly, the same URL would work correctly in a web browser (the data would be downloaded), and the certificates were considered valid.

Resolution:
After talking with the CyVerse team, they believe the issue had to do with Server Name Indication (SNI). The server is data.cyverse.org, however, the certificate that was being sent (as can be seen from the IGB message) was r03c08u18-dav-1.cyverse.org. Most likely IGB does not handle SNI and as the certificate did not match the server, considered it invalid.

CyVerse has updated their server configuration, and the new certificate reads as *.cyverse.org, which works correctly with IGB.

Attachments

Issue Links

relates to

IGBF-2009 Rework IGB Trust Certificate Dialog

Closed

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Ann Loraine added a comment - 13/Sep/19 10:05 AM

Yay!!

Show

Ann Loraine added a comment - 13/Sep/19 10:05 AM Yay!!

Hide

Permalink

Nowlan Freese added a comment - 13/Sep/19 10:08 AM - edited

From: Nowlan Freese
We noticed this week that when we try to connect to our public CyVerse data via our software (IGB) we are getting some exceptions related to the cyverse certificate.

The public data we are trying to reach is here: https://data.cyverse.org/dav-anon/iplant/home/nowlanf/Human/NSCLC-MUT-small.bedgraph

The url itself works fine in a web browser. It's only when we try to reach it in IGB that we see issues related to the certificate:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching data.cyverse.org found

I'm testing using a version of IGB that was released a year ago, so nothing that I'm aware of has changed on our end.

Any thoughts on what could be causing this?

The certificate IGB finds:
1.2.840.113549.1.9.1=#1620726f6f74407230336330387531382d6461762d312e637976657273652e6f7267,CN=r03c08u18-dav-1.cyverse.org,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--,

The stacktrace from IGB:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching data.cyverse.org found
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at com.affymetrix.genometry.util.LocalUrlCacher.isValidURI(LocalUrlCacher.java:728)
at com.affymetrix.igb.view.load.GeneralLoadUtils.openURI(GeneralLoadUtils.java:963)
at com.affymetrix.igb.IgbServiceImpl.openURI(IgbServiceImpl.java:347)
at com.affymetrix.igb.shared.OpenURIAction.openURI(OpenURIAction.java:89)
at com.affymetrix.igb.shared.LoadURLAction.loadURL(LoadURLAction.java:127)
at com.affymetrix.igb.shared.LoadURLAction.actionPerformed(LoadURLAction.java:60)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at com.apple.laf.ScreenMenuItem.actionPerformed(ScreenMenuItem.java:125)
at java.awt.MenuItem.processActionEvent(MenuItem.java:669)
at java.awt.MenuItem.processEvent(MenuItem.java:628)
at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:357)
at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:345)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:763)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
at java.awt.EventQueue$4.run(EventQueue.java:733)
at java.awt.EventQueue$4.run(EventQueue.java:731)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: java.security.cert.CertificateException: No name matching data.cyverse.org found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:231)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:96)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1026)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:993)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
... 46 more

From Sarah Roberts:
According to the browser when I connect, data.cyverse.org is using our wildcard certificate. I can’t seem to get openssl s_client -connect data.cyverse.org:443 to show wildcard name (*.cyverse.org) in the certificate information, though.

I wonder if the SSL library that IGB is using doesn’t support wildcard certificates.

I’m thoroughly confused now. The certificate shown by openssl s_client connect is different from the one shown by my browser.

From Nowlan Freese:
I'm pretty sure IGB can handle wildcard certificates.

IGB will load this data from a public dropbox which uses a wildcard: https://dl.dropboxusercontent.com/s/2d6axo48h86lavx/HG002.GRCh38.2x250.bedgraph

The common name I'm getting from the CyVerse cert is: r03c08u18-dav-1.cyverse.org

From Sarah Roberts:
Ah, I think I figured it out. The web server on data.cyverse.org is using Server Name Indication (SNI). If the host name that it gets from SNI isn’t data.cyverse.org then you get a self-signed certificate. I wasn’t seeing it in the browser because browsers correctly handle SNI.

openssl without the SNI information:
$ echo | openssl s_client -connect data.cyverse.org:443 | openssl x509 -noout -subject
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = r03c08u18-dav-1.cyverse.org, emailAddress = root@r03c08u18-dav-1.cyverse.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = r03c08u18-dav-1.cyverse.org, emailAddress = root@r03c08u18-dav-1.cyverse.org
verify error:num=21:unable to verify the first certificate
verify return:1
DONE
subject= /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=r03c08u18-dav-1.cyverse.org/emailAddress=root@r03c08u18-dav-1.cyverse.org

openssl with the SNI information:
$ echo | openssl s_client -connect data.cyverse.org:443 -servername data.cyverse.org| openssl x509 -noout -subject
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.cyverse.org
verify return:1
DONE
subject= /OU=Domain Control Validated/CN=*.cyverse.org

Does your client library support SNI by any chance?

Hi Nowlan,

I pinged our data store team, and the team lead updated the server configuration. The problem appears to be fixed as far as I can tell. Could you try it with IGB again to see if it works now?

Thanks,
Sarah

From Nowlan:
Thank you so much, it is working now!

Show

Nowlan Freese added a comment - 13/Sep/19 10:08 AM - edited From: Nowlan Freese We noticed this week that when we try to connect to our public CyVerse data via our software (IGB) we are getting some exceptions related to the cyverse certificate. The public data we are trying to reach is here: https://data.cyverse.org/dav-anon/iplant/home/nowlanf/Human/NSCLC-MUT-small.bedgraph The url itself works fine in a web browser. It's only when we try to reach it in IGB that we see issues related to the certificate: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching data.cyverse.org found I'm testing using a version of IGB that was released a year ago, so nothing that I'm aware of has changed on our end. Any thoughts on what could be causing this? The certificate IGB finds: 1.2.840.113549.1.9.1=#1620726f6f74407230336330387531382d6461762d312e637976657273652e6f7267,CN=r03c08u18-dav-1.cyverse.org,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--, The stacktrace from IGB: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching data.cyverse.org found at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037) at sun.security.ssl.Handshaker.process_record(Handshaker.java:965) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) at com.affymetrix.genometry.util.LocalUrlCacher.isValidURI(LocalUrlCacher.java:728) at com.affymetrix.igb.view.load.GeneralLoadUtils.openURI(GeneralLoadUtils.java:963) at com.affymetrix.igb.IgbServiceImpl.openURI(IgbServiceImpl.java:347) at com.affymetrix.igb.shared.OpenURIAction.openURI(OpenURIAction.java:89) at com.affymetrix.igb.shared.LoadURLAction.loadURL(LoadURLAction.java:127) at com.affymetrix.igb.shared.LoadURLAction.actionPerformed(LoadURLAction.java:60) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) at com.apple.laf.ScreenMenuItem.actionPerformed(ScreenMenuItem.java:125) at java.awt.MenuItem.processActionEvent(MenuItem.java:669) at java.awt.MenuItem.processEvent(MenuItem.java:628) at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:357) at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:345) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:763) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84) at java.awt.EventQueue$4.run(EventQueue.java:733) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at java.awt.EventQueue.dispatchEvent(EventQueue.java:730) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) Caused by: java.security.cert.CertificateException: No name matching data.cyverse.org found at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:231) at sun.security.util.HostnameChecker.match(HostnameChecker.java:96) at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1026) at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:993) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621) ... 46 more From Sarah Roberts: According to the browser when I connect, data.cyverse.org is using our wildcard certificate. I can’t seem to get openssl s_client -connect data.cyverse.org:443 to show wildcard name (*.cyverse.org) in the certificate information, though. I wonder if the SSL library that IGB is using doesn’t support wildcard certificates. I’m thoroughly confused now. The certificate shown by openssl s_client connect is different from the one shown by my browser. From Nowlan Freese: I'm pretty sure IGB can handle wildcard certificates. IGB will load this data from a public dropbox which uses a wildcard: https://dl.dropboxusercontent.com/s/2d6axo48h86lavx/HG002.GRCh38.2x250.bedgraph The common name I'm getting from the CyVerse cert is: r03c08u18-dav-1.cyverse.org From Sarah Roberts: Ah, I think I figured it out. The web server on data.cyverse.org is using Server Name Indication (SNI). If the host name that it gets from SNI isn’t data.cyverse.org then you get a self-signed certificate. I wasn’t seeing it in the browser because browsers correctly handle SNI. openssl without the SNI information: $ echo | openssl s_client -connect data.cyverse.org:443 | openssl x509 -noout -subject depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = r03c08u18-dav-1.cyverse.org, emailAddress = root@r03c08u18-dav-1.cyverse.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = r03c08u18-dav-1.cyverse.org, emailAddress = root@r03c08u18-dav-1.cyverse.org verify error:num=21:unable to verify the first certificate verify return:1 DONE subject= /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=r03c08u18-dav-1.cyverse.org/emailAddress=root@r03c08u18-dav-1.cyverse.org openssl with the SNI information: $ echo | openssl s_client -connect data.cyverse.org:443 -servername data.cyverse.org| openssl x509 -noout -subject depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority verify return:1 depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2 verify return:1 depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/ , CN = Go Daddy Secure Certificate Authority - G2 verify return:1 depth=0 OU = Domain Control Validated, CN = *.cyverse.org verify return:1 DONE subject= /OU=Domain Control Validated/CN=*.cyverse.org Does your client library support SNI by any chance? Hi Nowlan, I pinged our data store team, and the team lead updated the server configuration. The problem appears to be fixed as far as I can tell. Could you try it with IGB again to see if it works now? Thanks, Sarah From Nowlan: Thank you so much, it is working now!

Hide

Permalink

Nowlan Freese added a comment - 13/Sep/19 10:42 AM - edited

I'm not sure how useful it would be for us to consider SNI or if it makes sense in this situation. CyVerse is already using wildcards for their certificates (*.cyverse.org). See this StackExchange for further discussion.

I'm a little confused why IGB asks the user if they trust the certificate, but then fails to honor their decision. Even if the user decides to trust the certificate, IGB will still fail to connect if the certificate is not valid. Either IGB needs to honor the user's decision or not ask the user to validate the certificate (~~IGBF-1362~~).

Show

Nowlan Freese added a comment - 13/Sep/19 10:42 AM - edited I'm not sure how useful it would be for us to consider SNI or if it makes sense in this situation. CyVerse is already using wildcards for their certificates (*.cyverse.org). See this StackExchange for further discussion. I'm a little confused why IGB asks the user if they trust the certificate, but then fails to honor their decision. Even if the user decides to trust the certificate, IGB will still fail to connect if the certificate is not valid. Either IGB needs to honor the user's decision or not ask the user to validate the certificate ( IGBF-1362 ).

Hide

Permalink

Ann Loraine added a comment - 13/Sep/19 10:46 AM

I agree - that seems weird.
Do you want to make a ticket to investigate the workflow?

Show

Ann Loraine added a comment - 13/Sep/19 10:46 AM I agree - that seems weird. Do you want to make a ticket to investigate the workflow?

Hide

Permalink

Nowlan Freese added a comment - 13/Sep/19 11:01 AM

I have created ~~IGBF-2009~~ as a new ticket.

Show

Nowlan Freese added a comment - 13/Sep/19 11:01 AM I have created IGBF-2009 as a new ticket.

Hide

Permalink

Ann Loraine added a comment - 16/Sep/19 12:30 AM

Issue was resolved with CyVerse reconfiguration of server. We will investigate IGB end of things as part of new ticket ~~IGBF-2009~~.

Show

Ann Loraine added a comment - 16/Sep/19 12:30 AM Issue was resolved with CyVerse reconfiguration of server. We will investigate IGB end of things as part of new ticket IGBF-2009 .

People

Assignee:

Nowlan Freese

Reporter:

Nowlan Freese

Votes:

0 Vote for this issue

Watchers:

2 Start watching this issue

Dates

Created:

13/Sep/19 10:00 AM

Updated:

17/Sep/19 10:10 AM