Xen Orchestra from source with Let's Encrypt certificates
Using CA issued certificates on Xen Orchestra from source (xo) improves security and browser compatibility. Creating Let's Encrypt (LE) certificates for Xen Orchestra is simple using pfsense with the acme plugin. It is a two-step process controlled by the acme plugin on pfsense:
- request/renew LE certificates
- copy certificates to xo and restart the xo-server
The acme plugin offers several methods for step 1. I am using the Webroot FTP method because I do not want to expose services to the internet and my domain provider (Strato AG) does not offer DNS and/or API based LE support.
Step 2 is the same for all methods in this example. With key-based authentication a ssh user (e.g.
acme) will copy LE certificates from pfsense to xo and restart the xo-server
For this post I skip step 1 since it highly depends on your situation, but if acme has been setup correctly you end up with domain specific LE certificates in the
/conf/acme/folder on pfsense.
xo.myplaylab.netis my Xen Orchestra from source VM and xo.myplaylab.net.key and xo.myplaylab.net.crt are the LE certificates from step 1.
Step 2 needs some preparation before the acme plugin can automate this step.
Prepare Xen Orchestra from source to receive certificates from pfsense
- create user
acmemember of sudo
acmesudo rights to restart xo-server only
- create certificate folder on xo (e.g.
- change folder owner to acme
- optional: make xo-servers non-privileged user member of acme if not run as 'root'.
Prepare pfsense to send certificates to xo via ssh
- setup key-based ssh connection on pfsense to ssh into xo
- copy ssh-keys to xo for user
- ssh into xo with user
email@example.com complete process
- check that you can scp the certificates from pfsense to the certification folder on xo
- check that you can ssh into xo from pfsense and restart the xo-server
- these manual tasks will later be executed by the acme plugin.
Prepare Xen Orchestra to use the LE certificates
- make sure that the certificates have been copied to
/opt/xen-orchestra/packages/xo-server/.xo-server.toml(maybe not the right file )
- uncomment [[http.listen]] and port = 443 in the Basic HTTPS section
- uncomment and change cert to
cert = '/etc/acme/ssl/xo.myplaylab.net.crt'
- uncomment and change key to
key = '/etc/acme/ssl/xo.myplaylab.net.key'
- uncomment redirectToHttps = true
- restart xo-server and check the status
The final step is to add the shell commands to the
xo.myplaylab.netacme configuration. Edit the configuration on pfsense and add the shell commands to the action list.
scp /conf/acme/xo.myplaylab.net.crt /conf/acme/xo.myplaylab.net.key firstname.lastname@example.org:/etc/acme/ssl/
ssh email@example.com "sudo /bin/systemctl restart xo-server"
Did a complete rewrite to be more clear on the interaction between pfsense and xo.
Ping @julien-f about XO, if we can have this documented and if it's the best way
Regarding XCP-ng, I'm aware about some related work from XAPI developers. Pinging @psafont
I think when I last asked @julien-f about this he said it work work (just as you described), but the issue is xo-server will not reload certs without restarting the process. So the next time your let's encrypt instance updates those certs, xo-server will have no idea and you'll need to schedule a restart of that service after certs are updated
@fohdeesha just realized that I forgot to mention two steps (key- based ssh authentification from pfsense to
acmemember of sudo on
xowith limited sudo rights). The acme plugin configuration allows adding shell commands which are executed after the LE certification renewal (e.g.
ssh firstname.lastname@example.org "sudo /bin/systemctl restart xo-server"to force xo-server to reload the certififcates).
Wow, this now reads more complicated than it realy is
Did a complete rewrite with better structure and focus on the interaction between pfsense and Xen Orchestra. Skipped the part of setting up the acme plugin for Webroot FTP as well, because it is very specific to my setup.
@olivierlambert Regarding XCP-ng - just generated a Let's Encrypt certificate for one of my xcp-ng test hosts
xcp01.myplaylab.net(XCP-ng 8.2 beta fully patched), replaced the
/etc/xensource/xapi-ssl.pemwith the LE certificate
xcp01.myplaylab.net.all.pemwhile keeping the name
xapi-ssl.pemand did a
xe-toolstack-restart. That seems to work, since I get a valid LE certificate and secure connection when accessing
https://xcp01.myplaylab.net. Could it be that simple ? Do not have a pool and xo available right now, so just wondering...
I was just too curious - the xcp-ng test host can be added to Xen Orchestra with the LE certificate - no need to accept unauthorized certificates anymore
Now you can even replace the cert via XO web UI (see https://xen-orchestra.com/blog/xen-orchestra-5-52/#xcpngxenserverhostscertificatesmanager)
I'm testing using certbot to install SSL cert for XOCE using Lets Encrypt instructions but need to know what is the path for XOCE webroot?
@stevewest15 those instructions will not work as XOA is running on node and does not have a physical "web root" folder like you are thinking of. Also @gskger please be cautious about scheduling xo-server restarts, doing so interrupts and breaks any task xo-server is running at that time, like backups etc. I believe this is one of the main reasons we haven't implemented let's encrypt integration into XOA, it's not as simple as just firing off an xo-server restart everytime LE certs are updated - this would break a lot of important backups for the majority of our customers. We would need to add some type of sensing to see xo-server's current status, and schedule the restart for when there's no longer any tasks running
@fohdeesha good to know, thank you. Maybe setting some xo flag through cli telling xo-server to restart when convinient might be a way to automate the process of cert updates?