Xsync configuration

[Jose Villamizar]

Hello,

We are trying to configure the Xsync plugin on a brand new XNAT instance running 1.8.6.1. However, when configuring the plugin on the source XNAT we are getting an error that reads: ERROR: Could not get alias token. Please check username and password. The login credentials are correct. Do you or anyone in the group has any advice? Any documentation besides this link :  https://bitbucket.org/xnatdev/xsync/src/master/

I followed these steps on the readme.md

Thank you.

[Alex]

Hi Jose,

I recently encountered this issue and in my case there were two reasons: firewalls needed to be adjusted to allow the connection and SSL certificates needed to be properly set up on the destination system. 
Once this was done XSync started working.

Thanks,

Alex

[Jose Villamizar]

Hi Alex,

Can you elaborate on what was adjusted on the firewalls? I got proper SSL certificates not self-signed.

Thanks.

[Alex Kogan]

Jose,

In my case, we didn't have the firewall open between the subnet of the source instance application server and the destination instance web server. To test this, from your source application server command line you can try to make a telnet connection to the destination and see if you can connect or the connection times out. For example:

telnet <server hostname> <port#>

Alex

--
You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/B8lPTw7r3jg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/003a9ba0-c1e4-4ab3-98ba-ad358fa2c5c1n%40googlegroups.com.

[Jose Villamizar]

HI Alex,

We do not have open telnet port. However, we can ssh from source xnat to destination xnat or from destination to source without any issues. This tells me that the XNAT servers are communicating properly. These are the ports that I've currently opened on both tests systems:

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
5432/tcp                   ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
8104/tcp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
5432/tcp (v6)              ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)
8104/tcp (v6)              ALLOW       Anywhere (v6)

I am thinking to run wireshark to see what happens during the SSL handshake. I wish we have more documentation on this plugin.

Thanks.

[Rick Herrick]

Documentation on the plugin wouldn't help at all with this issue: XSync uses standard HTTP protocol for communication, meaning port 80 or port 443 depending on the URL of the system you’re trying to access. There’s really not much else to say about that from the XNAT/XSync perspective there.

Also, there is a standard telnet port (23) but telnet itself isn’t restricted to using that port. Alex’s suggestion is a good one: you can specify the URL along with the appropriate port with telnet and at least make sure you can reach that destination. For example, I can verify that I can reach the HTTPS port for my dev server but not the SSH port:

# telnet <server> 443

Trying x.x.x.x…

Connected to <server>.

Escape character is '^]’.

^]

telnet> \q

Connection closed.

# telnet <server> 22

Trying x.x.x.x…

telnet: connect to address x.x.x.x: Connection refused

telnet: Unable to connect to remote host

You can try this same thing: telnet to port 80/443 (http/https) at the target server address.

Rick Herrick

Senior Software Developer

rickh...@flywheel.io

------ Original Message ------

From "Jose Villamizar" <mcv...@gmail.com>

To "xnat_discussion" <xnat_di...@googlegroups.com>

Date 3/3/2023 4:57:28 PM

Subject Re: [XNAT Discussion] Re: Xsync configuration

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 view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/c01c612c-fc75-485a-9ccd-24552ec40001n%40googlegroups.com.

[Jose Villamizar]

Hi Rick,

Thank you for your suggestions. We can indeed telnet to the destination XNAT using tcp port 22, 23, 80, and 443 using the IP address or FQDN. We are still getting the same ERROR: Could not get alias token. Please check username and password.

Any other suggestions?

Sincerely,

JV

[Alex Kogan]

Hi Jose,

What is the actual error in xsync.log? Any other relevant messages in the logs?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/c01c612c-fc75-485a-9ccd-24552ec40001n%40googlegroups.com.

[Jose Villamizar]

Alex,

Nothing really helpful. 

│2023-03-08 09:47:07,512 [ajp-nio-127.0.0.1-8009-exec-10] DEBUG org.nrg.xsync.xapi.XsyncOperationsController - Attempting to GET https://FQDN/data/services/tokens/│

[Alex Kogan]

Anything in the logs of the destination system?

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/ad57a24f-5fd7-4677-a35d-34a1d4ab313an%40googlegroups.com.

[Jose Villamizar]

Alex,

Destination XNAT xsync.log does not show anything helpful either.

│

│2023-03-08 10:30:00,007 [taskScheduler-1] INFO  org.nrg.xsync.services.local.AbstractSyncService - Hourly Sync Completed - Wed Mar 08 10:30:00 CST 2023                     │
│2023-03-08 11:30:00,004 [taskScheduler-2] INFO  org.nrg.xsync.services.local.AbstractSyncService - Hourly Sync Triggered - Wed Mar 08 11:30:00 CST 2023                     │
│2023-03-08 11:30:00,005 [taskScheduler-2] INFO  org.nrg.xsync.services.local.AbstractSyncService - Hourly Sync Completed - Wed Mar 08 11:30:00 CST 2023

[Jose Villamizar]

Good morning,

Here is a my latest tests. From source xnat via CLI issue curl 'https://my_fully_qualified_domain_name' -v and we get this error:

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.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

if we use -k flag the communication is successful via CLI. 

So our conclusion of this issue appears to be related to the SSL certificates not being able to verify their issuer and legitimacy of the server while using the XNAT portal. 

Are we in the right track here? 

Are any additional configuration changes to be made to tell the source XNAT to use these certificates?

Sincerely,

JV

[Alex Kogan]

Jose,

This looks like you are moving in the right direction. Do you see any errors in the security.log?

This command helped me narrow down the certificate issue:

openssl s_client -showcerts -connect <destination web proxy host>:443

On the web proxy check if you have the correct certificate, chain certificate and key defined. Which web server are you using?

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/d058dedc-4eab-44ec-90d4-8e29a805a02en%40googlegroups.com.

[Jose Villamizar]

Hi Alex,

Thank you for the encouraging. 

Thank you for providing the command, the error that came out after running is as follows:

Verification error: unable to verify the first certificate

Verify return code: 21 (unable to verify the first certificate)

Also we are seeing this:

HTTP/1.1 400 bad request

We are running Apache 2.4.54 running Debian 11.6. We are not using proxy at all. These servers have access out to specific ports in our firewalls.

the /etc/apache2/sites-available/ssl.conf has the correct entries for the .CRT and .KEY pointing the correct certificates located in /etc/ssl/certs directory

[Alex Kogan]

Are both SSLCertificateFile and SSLCertificateChainFile directives defined in the Apache configuration?

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/674e1020-1928-43a5-9115-d00f1cea3e2an%40googlegroups.com.

[Jose Villamizar]

Alex,

We do not have SSLCertificateChainFile defined. The SSLCertificateFile and KeyFile are defined.

[Rick Herrick]

When Alex asks about your proxy, he actually means the front-end proxy for XNAT, which is your Apache HTTPD server: requests come into Apache HTTPD from outside, are routed to the Tomcat server on which your XNAT is deployed, which responds back to the front-end proxy, which then relays the response back to the client.

Re: your questions:

• Are we in the right track here? Yes, absolutely. This is the problem.
• Are any additional configuration changes to be made to tell the source XNAT to use these certificates? No. XNAT doesn’t know anything about certificates. You can do SSL termination (i.e. the encrypt/decrypt operations) in Tomcat or a front-end proxy like nginx or (in your case) Apache HTTPD, but XNAT has nothing to do with that.

The reason your curl call worked with the -k option is because that option tells curl explicitly to ignore verification issues with SSL certificates. 

You mentioned that your Apache configuration "has the correct entries for the .CRT and .KEY pointing the correct certificates located in /etc/ssl/certs directory”. That may well be, but the certificate and private key stored in those files seem to be invalid as far as any of the requesting clients is concerned.

It’s possible that it's not the certificate and private key themselves, but maybe the root CA certificates on the server or on the client. Try updating the CA certificates on your systems with something like this:

sudo apt --only-upgrade install ca-certificates ca-certificates-java

Rick Herrick

Senior Software Developer

rickh...@flywheel.io

------ Original Message ------

From "Jose Villamizar" <mcv...@gmail.com>

To "xnat_discussion" <xnat_di...@googlegroups.com>

Date 3/9/2023 11:38:01 AM

Subject Re: [XNAT Discussion] Re: Xsync configuration

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 view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/674e1020-1928-43a5-9115-d00f1cea3e2an%40googlegroups.com.

[Jose Villamizar]

Hi Rick,

Thank you for your reply. 

We already have the latest ca-certificate installed on the servers.

[Jose Villamizar]

In case someone else run into this situation. The resolution of our problem was to append the intermediate and root certificates at the end of the source XNAT certificate. Once we did, the Xsync finally was able to connect to the destination XNAT.

Many thanks for your ideas and thoughts. 

Sincerely,

Jose Villamizar