XO-Lite and Let's Encrypt certificate

hellst0rm

Hi,

I have a setup for Let's encrypt certificates and automated renewal setup more or like this:

Xen Orchestra from source with Let's Encrypt certificates

for my XCP-NG hosts and XO-CE via ACME service on my pfSense router.

Accessing my XCP-NG XO LITE instance via FQDN tell me to accept the certficates for each hosts IP address.

I suspect this has to do with the fact of the following statements:

@pdonias

That was the problem, but I do not think that it should be.

I am browsing to XO Lite using the FQDN of the XCP-ng host and the certificate had been accepted for that. But the console connection being made by XO Lite is to the XCP-ng host IP address.

@olivierlambert said in Xen Orchestra Lite:

Yes, Xen API (XAPI) is returning IP addresses only.

And traces back to the following to issues for XO and XenServer (XAPI):

Let's encrypt certificates does not and cannot contain private range IP addresses in the Subject Alternative Name field, and thereby cannot be used with XO LITE and/or XAPI.

To be able to have a self-signed certificate for my FQDN and IP addresses I used the following script and config and installed this certificate onto XO-CE, my three XCP-NG hosts, and my web browser.

#!/bin/sh
openssl req -nodes -new -x509 -days 3650 -keyout /opt/ssl/xcp-ng.key -out /opt/ssl/xcp-ng.crt -config /opt/ssl/san.conf

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
x509_extensions = v3_req
prompt = no

[ req_distinguished_name ]
organizationName = Self-signed certificate
commonName = Self-signed certificate

[ req_ext ]
subjectAltName = @alt_names

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1=xo-ce.domain.tld
IP.1=192.168.1.2
DNS.2=xcp-ng-01.domain.tld
IP.2=192.168.1.3
DNS.3=xcp-ng-02.domain.tld
IP.3=192.168.1.4
DNS.4=xcp-ng-03.domain.tld
IP.4=192.168.1.5

In XO I need now to "Allow Unauthorized Certificates" which comes with the following warning:

"Enable it if your certificate is rejected, but it's not recommended because your connection will not be secured."

Like this I can both access XO, XO LITE, and XO and XCP-NG communicates with eachother.
This makes it so that I can use XO LITE as a backup in case my XO-CE is down for some reason.

But, I do not like this way and would really prefer to be able to have the Let's encrypt certificates as I initially setup, is there any way to be able to use Let's encrypt certificates and to work around this?

bigdweeb

I run my own CA internally and ran into the same issue when I tried using XO Lite for the first time. The cert worked for connecting to the pool master, but I think the consoles wouldn't work and definitely connecting to VMs on different members of the pool didn't work without accepting the cert error my browser was reporting. I figured out that those calls seem to be happening by IP instead of name, so I just regenerated my certs with the hostname and ip as SANs on the certs of all my hosts and it resolved the issue for me too. The way to work around it would be for XO Lite to make those calls to other resources by hostname instead of IP from what I can tell without digging into it any further than I did.

hellst0rm

@bigdweeb, I saw the same issue with console as you describe too when using only the self-signed certificates without the IP field added to the SAN field.

I could use spin up my own CA and add that to my trusted cert store in OS and browser, and make certificates for a local (sub)domain.

Will experiment if it is possible to use that with a reverse proxy to access XO, XCP, and XO LITE.

xcp01.domain.ltd -> reverse proxy -> xcp01.sub.domain.ltd

bigdweeb

@hellst0rm I don't see why it wouldn't work as long as everything is set to trust your internal CA root. It's pretty trivial to create a CA. I did it years ago because I can't stand cert errors and as a learning exercise. The only annoying part is it's just one more thing to keep track of and update, but if you're running a homelab it just becomes another part of the exercise.