Use case: For an on-premises deployment, Let’s Encrypt may not be an option. You may want to use your own enterprise/corporate Certificate Authority (CA) or another 3rd party.
Thanks to recent enhancements by the Velociraptor developers, this is quite a simple task. The below is a simple test configuration used and may need adapting to your environment.
Prior to commencing we have a plaintext PEM private key, certificate for our Velociraptor server, and the certificate chain of our enterprise CA, including the root and multiple intermediaries.
Using Ubuntu we generated a stock standard “Self Signed SSL” configuration:
./velociraptor-v0.6.3-2-linux-amd64 config generate -i
Locate the frontend section and add the tls_certificate_filename
and tls_private_key_filename
parameters. Enter the absolute path to these files. For testing, we placed in /etc however there is better places for production use.
Frontend:
tls_certificate_filename: /etc/velociraptor.pem
tls_private_key_filename: /etc/velociraptor.key
In the client section modify use_self_signed_ssl
to be false, and add the CA root/intermediary certificates to be trusted by the client:
use_self_signed_ssl: false
Crypto:
root_certs: |
-----BEGIN CERTIFICATE-----
XXXXX
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
XXXXX
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
XXXXX
-----END CERTIFICATE-----
...
Launching the server we should be able to connect to the GUI using our new certificate. Note this must be trusted by browser/system to prevent errors.
Launching the client, it should connect securely without error, using the trusted CA chain and the new server certificate.
No changes need to be made to the pinned certificate name, nor do any certificates need to be modified in the configuration files.