Securing PostgreSQL with TLS Support on Xray
Copy these TLS parameters to
Verify that the certificates have the correct permissions.
Change the connection string in the /
Make sure you have an Xray user and group.
Assign permissions to the certificates.
Restart all the Xray services.
Securing RabbitMQ with TLS Support on Xray
openssl.cnffile and ensure that it contains the field,
subjectAltName, and all the other required fields.
The following example shows a sample
Run the following commands to generate certificates for RabbitMQ and Xray.
In the commands,
subjectAltName, is the used as an example and the value should be a resolvable DNS. and should be used in the system.yaml file when providing the shared.rabbitMq.url (see step 6 below).
Create Certificate Authority (CA) files.
Sign the CA private key, ca-key.pem, and create the related CA certificate.
Create the RabbitMQ private key (server-key.pem) and certificate signing request file(server.csr).
Create a signed RabbitMQ public key (server-cert.pem).
Create Xray client key (client-key.pem) and certificate signing request file (client.csr).
Create Xray client certificate file.
Copy the ca and server certificates to
For Self-signed Certificates Only
To ensure that the client trusts self-signed certificates (only), you will need to perform the following steps according to the OS you are using.
You will need to mount a root ca bundle into each Xray container:
For Linux Archive/Native OS: Debian 8/9/10, Ubuntu 16/18/20
Copy your root certificate into
/usr/local/share/ca-certificates/and then run the
For Linux Archive/Native OS: CentOS 6/7/8, RHEL 6/7/8
Copy your root certificate into /etc/pki/ca-trust/source/anchors/ and then run the update-ca-trust command.
Note that on CentOS 6/RHEL 6 you will have to run an additional command
- update-ca-trust force-enable.
After you add your own root certificate into the system bundle - you can verify the certificate with the following command:
Modify the certificate permissions for the RabbitMQ user.
Modify the certificate permissions for the Xray user.
/opt/jfrog/xray/var/etc/system.yaml(under the shared folder) according to your configuration. Do not overwrite existing lines in the system.yaml file.
The following sample system.yaml shows an example.
Configure the r
$XRAY_HOME/app/bin/rabbitmq/rabbitmq.conf) file to use the certs.
The following sample rabbitmq.conf shows an example.
Run the REST API call to enable the TLS connection to RabbitMQ in Xray.
Replace <username> and <password> with an admin user and password credentials for Artifactory and <artifactory_url> with the actual Artifactory URL.
Run the following steps to enable the TLS connection to RabbitMQ in Xray if you use Docker Compose.
Restart Xray services.
After Xray services are up and running, you can verify if RabbitMQ is accessible through
Troubleshooting RabbitMQ with TLS in Xray
If you encounter any errors or issues you might find the following troubleshooting tops helpful,
- Ensure that you have the proper certificates and that their location is correct. The
$JFROG_HOMEvariable refers to the directory in which Xray is installed. The default is
In some operating systems, the
openssl.cnffile may be located in a different location than
/etc/ssl/openssl.cnf. Use the find command to find it in your system.
- Check that all the certificates are owned by the user and group
xray. If you are using a different user and group to run Xray, ensure this user is the owner of the files.
- The YAML files must have proper indentation with the same amount of spaces across the entire file. Ensure the Xray
system.yamlfile is properly indented and that the syntax is correct. Also, check that the details are correct such as passwords, paths, and URLs are correct in the YAML file.
- A successful REST API call requires an Artifactory admin user.
- Check the logs to find additional information to help in further troubleshooting any issues. The logs directory is
$JFROG_HOME/xray/var/log. The recommended logs to look at are the
xray-server-service.log, and the RabbitMQ logs in the rabbitmq directory.
Trusting Self-Signed Certificates
When an Xray instance/node is configured to go through an SSL proxy that uses a self-signed certificate, you may encounter the following issue when performing tasks such as an online database sync:
- To overcome this issue, you will need to import the Proxy certificate into each Xray instance/pod by placing it under the following path within the Xray machine/container/pods:
- Next, you will need to restart Xray.
The path shown above is the default directory used by Go applications (such as Xray) when importing SSL certificates.