SSL certificate problem with pipeline

237 views
Skip to first unread message

Simon Doran

unread,
Dec 12, 2013, 6:59:20 AM12/12/13
to xnat_di...@googlegroups.com
Mohana,

  Can you help me with this one? I have a valid SSL certificate installed for one of my XNAT servers, but am getting the following when the AutoRun.xml pipeline executes:

FATAL main org.nrg.pipeline.client.XNATPipelineLauncher - Couldnt search for queued workflows
javax.net.ssl.SSLException: hostname in certificate didn't match: <localhost> != <XXXXXX> OR <XXXXXX> // I overwrote the real value.
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:227)
        at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:147)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
        at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
        at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
        at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
        at org.nrg.xnattools.SessionManager.createJSESSION(SessionManager.java:64)
        at org.nrg.xnattools.SessionManager.getJSESSION(SessionManager.java:112)
        at org.nrg.xnattools.service.WebServiceClient.connect(WebServiceClient.java:84)
        at org.nrg.pipeline.client.XNATPipelineLauncher.isPipelineQueuedOrAwaitingOrOnHold(XNATPipelineLauncher.java:355)
        at org.nrg.pipeline.client.XNATPipelineLauncher.isPipelineQueuedOrAwaitingOrOnHold(XNATPipelineLauncher.java:344)
        at org.nrg.pipeline.client.XNATPipelineLauncher.launch(XNATPipelineLauncher.java:76)
        at org.nrg.pipeline.client.XNATPipelineLauncher.run(XNATPipelineLauncher.java:290)
        at org.nrg.pipeline.client.XNATPipelineLauncher.main(XNATPipelineLauncher.java:255)

  Thanks in advance.

Simon

Mohana Ramaratnam

unread,
Dec 12, 2013, 10:57:32 AM12/12/13
to xnat_di...@googlegroups.com
Hi Simon,

It looks like the SSL certificate contains a hostnane which doesnt match the hostname (localhost) that you are using. If you are using localhost, I am assuming you can set the protocol to http instead of https. If not, then you will need the same hostname as in the SSL certificate. 

Mohana


--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/groups/opt_out.

Simon Doran

unread,
Dec 12, 2013, 2:01:24 PM12/12/13
to xnat_di...@googlegroups.com
Mohana,

  That may be the symptom, but localhost is the *same* machine as XXXXXX, which is what the certificate was generated for, i.e. the AutoRun process is executing on XXXXX. It is surely something in either the nrg or apache code that is not putting 2 and 2 together and figuring out that they are the same.

Simon

Herrick, Rick

unread,
Dec 12, 2013, 2:30:15 PM12/12/13
to xnat_di...@googlegroups.com

Doesn’t matter. The certs are matched against the hostname with no attempt to resolve any sort of aliases or anything.

 

Anyway, localhost really ISN’T the same as foo.school.edu or foo.school.ac.uk or whatever, since those are handled by different network interfaces. So your FQDN address goes through DNS resolution to get to the IP address using (usually) eth0 or en0, whereas localhost translates to 127.0.0.1 (IPv4) or ::1 (IPv6) and goes through the loopback interface lo0.

 

Which is a little bit of angels on the head of a pin, but has the very real effect that you’re seeing there…

 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 827-4250

--

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/groups/opt_out.




The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

Simon Doran

unread,
Dec 12, 2013, 2:50:11 PM12/12/13
to xnat_di...@googlegroups.com
Rick,

  Technically, yes, but my point is that it is the same bit of hardware! Our SSL certificate is necessarily generated for the DNS hostname foo.school.ac.uk so that external people can access it! How do I convince pipeline to run the task on foo.school.ac.uk and not localhost and so avoid this problem? What do other people do?

Simon

Herrick, Rick

unread,
Dec 12, 2013, 2:58:32 PM12/12/13
to xnat_di...@googlegroups.com

I agree with your basic point, but unfortunately the Java security libraries don’t J

 

There is, however, a workaround for this. In the file WEB-INF/conf/services.properties, there’s a setting:

 

security.channel=any

 

If that’s set to any (other options are http and https) you can address the server through http or https. That means you can use http://foo.school.ac.uk OR https://foo.school.ac.uk. Any enforcement of https at the Apache proxy level is of course outside the scope of that control (we have nothing to do with it), but the upshot is that you should also be able to do https://foo.school.ac.uk OR http://localhost (you can also get around any Apache front-end redirects to https by going straight to Tomcat, e.g. http://localhost:8080 or http://localhost:8080/xnat).

 

Your other option, of course, is to use the FQDN with https even for the pipeline REST calls, which is actually what is recommended by most security experts (e.g. EFF has a typically stern and finger-wagging post about the topic here: https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory), although there’s no real danger with localhost being hijacked for man-in-the-middle attacks…

 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 827-4250

 

From: xnat_di...@googlegroups.com [mailto:xnat_di...@googlegroups.com] On Behalf Of Simon Doran
Sent: Thursday, December 12, 2013 1:50 PM
To: xnat_di...@googlegroups.com
Subject: [XNAT Discussion] Re: SSL certificate problem with pipeline

 

Rick,

 

  Technically, yes, but my point is that it is the same bit of hardware! Our SSL certificate is necessarily generated for the DNS hostname foo.school.ac.uk so that external people can access it! How do I convince pipeline to run the task on foo.school.ac.uk and not localhost and so avoid this problem? What do other people do?

 

Simon

--

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/groups/opt_out.

Simon Doran

unread,
Dec 12, 2013, 3:13:44 PM12/12/13
to xnat_di...@googlegroups.com
Rick,

  Thanks for your rapid response.

  I did know at least about the first of your options, but was hoping to avoid this, because I am sure that the Institute will not want it to be possible to access the server via http from outside. But I guess we just need to make sure that port 8080 is blocked by the firewall.

  I'll take a look at all the possibilities.

  Best wishes,

Simon
Message has been deleted

Simon Doran

unread,
Dec 12, 2013, 7:19:02 PM12/12/13
to xnat_di...@googlegroups.com
Mohana,

   Sorry, I'm still stuck. I have security.channel=any and it definitely works. With a web browser externally, I have the desired behaviour, viz:

https://foo.school.ac.uk:8443/xnat   gets me to my login page.

From a browser launched on foo.school.ac.uk

http://localhost:8080/xnat                gets me to my login page.

BUT ... I still get my FATAL main org.nrg.pipeline.client.XNATPipelineLauncher - Couldnt search for queued workflows
javax.net.ssl.SSLException: hostname in certificate didn't match: <localhost> != <foo.school.ac.uk> OR <foo.school.ac.uk>

so, presumably, pipeline is trying to communicate with XNAT in a way that doesn't work, maybe a rest call usinghttps://localhost:8443/xnat.

  So, my basic question still remains. How do I set the URL pipeline uses to query the server? I think that if I knew this, it would be easy to set it to either of the versions that work.

  I thought I was onto something when I found the file $PIPELINE/config/PipelineJobSubmitter.config and I tried uncommenting the line there and changing it to PIPELINE_JOB_SUBMITTER_OPTS="-DaliasHost=https://foo.school.ac.uk", but this didn't seem to make any difference.

  Any ideas?

  Best wishes,

Simon

Mohana Ramaratnam

unread,
Dec 12, 2013, 8:35:03 PM12/12/13
to xnat_di...@googlegroups.com

Simon

Can you post the entire call to the failed pipeline. I suspect you have an argument called alias_host which is being used.

Mohana

--

Simon Doran

unread,
Dec 16, 2013, 4:24:53 AM12/16/13
to xnat_di...@googlegroups.com
Hi Mohana,

  Thanks. At least I have now tracked back one step further. It turns out I was looking in the wrong place. When I checked application.log, what I found was:

/home/xnat/XNAT/Home/code/Current/pipeline/bin/XnatPipelineLauncher -pipeline xnat_tools/AutoRun.xml -id XNAT_E00098 -host https://localhost:8443/XNAT ...

  Where does pipeline pick up the -host argument from? This command runs perfectly if I insert a fully qualified domain name, so all I need to do is get XNAT to replace localhost when it constructs this call to pipeline.

  Best wishes,

Simon

Mohana Ramaratnam

unread,
Dec 16, 2013, 5:32:41 AM12/16/13
to xnat_di...@googlegroups.com

The host argument is picked up from Xnat Site configuration setting. Login to your Xnat instance as admin and change the site url.

Simon Doran

unread,
Dec 16, 2013, 9:56:00 AM12/16/13
to xnat_di...@googlegroups.com
Oh dear, how embarrassing!

Well, I'm glad we have that one sorted out. Thanks, Mohana. I could have sworn that I hadn't set up the system like that, but there it is in build.properties, too ...

Simon
Reply all
Reply to author
Forward
0 new messages