"Xray can connect to Artifactory, but Artifactory cannot connect to Xray"
This is the most common and dreaded message that can occur during an Xray installation. This article is intended to assist users who run into this particular problem, which has a surprising amount of possible causes and solutions.
Relevant Versions: Artifactory up to 6.X & Xray up to 2.Y
Xray requires a bi-directional connection with Artifactory. This means Xray can reach Artifactory, and Artifactory can reach back to Xray.
The connection is set up when Xray is first installed, and there are two major parameters used:
– The Artifactory URL: Used by Xray to reach out to Artifactory
These are some other settings that can come into play:
– Artifactory or Xray's Proxy Settings
– Firewall rules
– The host servers' network setup (Both Xray and Artifactory hosts)
These two curl tests can be used to fill out the URLs in Xray's setup menu:
Error usually reads: "Xray cannot connect to Artifactory"
curl -v http://artifactory.com:8081/artifactory/api/system/ping
Update the Artifactory URL in the Xray OnBoarding Wizard to use the one that passes the above curl command.
Error usually reads: "Xray can reach Artifactory but Artifactory cannot reach Xray"
#Perform from the Artifactory host
curl -v http://xray.com:8000/api/v1/system/ping
[Expected response from Xray]
Update the Xray Base URL with a URL that works. This can be done by choosing the "back" button in the Xray Onboarding Wizard. It can also be found under Xray's Admin -> Advanced -> General menu.
These curl commands should help diagnose most Xray <> Artifactory connection issues. However, there are additional parameters to consider in more specialized environments.
If the above curl tests succeed, but the Xray UI test still fails, this usually means there is a more specialized network present.
In many secure environments, Proxy Servers are needed in either Artifactory or Xray services. A common "Gotcha" that can happen is if Artifactory has a Default Proxy set up.
Artifactory will use its System Default proxy when connecting to Xray. There is an option to bypass this once the Xray <> Artifactory connection has been set up, but the test will always attempt to use the proxy server.
Try toggling the System Default proxy setting in Artifactory, and see if the test succeeds:
Note: Enabling the "System Default" option in the Artifactory Proxies menu will add the proxy to all remote repositories. Be cautious when turning on the System Default.
If you are planning to switch Xray or Artifactory to use the HTTPS protocol instead of the default HTTP protocol, this may cause a problem with the Xray <> Artifactory connection.
First, ensure SSL has been set up in Xray correctly. HTTPS is enabled in Xray by placing the SSL certificates under the $XRAY_HOME/data/ssl/serverCerts location. It is enabled by checking the "Use SSL" checkbox:
Xray must use a single SSL key / certificate pair.
If the SSL certificates are for a specific Common Name (E.G. xray.com), make sure the Xray Base URL matches this parameter. You should update this setting to ensure the URL uses HTTPS:
If necessary, you can modify the Artifactory host's /etc/hosts file so the URL matches the Xray IP address.
If you are using an internal or self-signed SSL certificate, you need to add the public certificate to Artifactory's JVM trust store. Otherwise you will see a "PKIX Path Building Failed" error message in Artifactory's logs:
If you are using a self-signed SSL certificate for Artifactory, you will need to import it into the Xray host Operating System keystore. Alternatively, you can also tick the "SSL insecure" checkbox in the Xray UI (Admin -> Advanced -> General).
One last thing that might cause an issue is the presence of a load balancer in front of Artifactory or Xray. If connection tests intermittently succeed, or all the above tests pass but Xray fails to scan binaries, it could be caused by a load balancer.
You might need to bypass the load balancer in front of Artifactory. Xray needs to connect to just one Artifactory node, as any scan results will be propagated to the rest of the cluster.
However, to ensure the system stays online, try using the load balancer URL first.