XOA letsencrpyt module not setting acmeDomain

peb2

Hello,

I'm new to Xen and XOA (migrating from Vmware) and I was wondering if anyone could help me with a problem.

I'm trying to use the Letsencrypt module as specified in:

https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/mixins/docs/SslCertificate.md?ref=xen-orchestra.com

However, the XOA doesn't seem to be passing the variable for 'acmeDomain' so I get a certificate without a CN.

Has anyone else seen this problem or know what my mistake may be?

Here's my /etc/xo-server/config.toml:

#=====================================================================

# HTTP proxy configuration used by xo-server to fetch resources on the
# Internet.
#
# See: https://github.com/TooTallNate/node-proxy-agent#maps-proxy-protocols-to-httpagent-implementations
#httpProxy = 'http://jsmith:qwerty@proxy.lan:3128'

# Configuration of the embedded HTTP server.
[http]
# If set to true, all HTTP traffic will be redirected to the first
# HTTPs configuration.

redirectToHttps = true

# Basic HTTP.
[[http.listen]]
# Port on which the server is listening on.
port = 80


# Basic HTTPS.
[https]
#
# You can find the list of possible options there https://nodejs.org/docs/latest/api/tls.html#tls.createServer
#
# The only difference is the presence of the certificate and the
# key.

hostname = '0.0.0.0'

[[http.listen]]
port = 443

# Whether to autogenerate a self signed certificate if the `cert` and `file`
# entries could not be found.
#
# Default: true
#autoCert = false
autoCert = true

# File containing the certificate (PEM format).
#
# If a chain of certificates authorities is needed, you may bundle
# them directly in the certificate.
#
# Note: the order of certificates does matter, your certificate
# should come first followed by the certificate of the above
# certificate authority up to the root.
#cert = '/etc/ssl/cert.pem'
cert = '/etc/ssl/xoa.cert.pem'

# File containing the private key (PEM format).
#
# If the key is encrypted, the passphrase will be asked at
# server startup.
#key = '/etc/ssl/key.pem'
key = '/etc/ssl/xoa.key.pem'

# ACME (e.g. Let's Encrypt, ZeroSSL) CA directory
#
# Specifies the URL to the ACME CA's directory.
#
# A identifier `provider/directory` can be passed instead of a URL, see the
# list of supported directories here: https://www.npmjs.com/package/acme-client#directory-urls
#
# Note that the application cannot detect that this value has changed.
#
# In that case delete the certificate and the key files, and restart the
# application to generate new ones.
#
# Default is 'letsencrypt/production'
acmeCa = 'zerossl/production'

# Domain for which the certificate should be created.
#
# This entry is required.
acmeDomain = 'xoa.mydomain.com'

# Optional email address which will be used for the certificate creation.
#
# It will be notified of any issues.
acmeEmail = 'myemail@mydomain.com'

john.c

@peb2 said in XOA letsencrpyt module not setting acmeDomain:

Hello,

I'm new to Xen and XOA (migrating from Vmware) and I was wondering if anyone could help me with a problem.

I'm trying to use the Letsencrypt module as specified in:

https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/mixins/docs/SslCertificate.md?ref=xen-orchestra.com

However, the XOA doesn't seem to be passing the variable for 'acmeDomain' so I get a certificate without a CN.

Has anyone else seen this problem or know what my mistake may be?

Here's my /etc/xo-server/config.toml:

#=====================================================================

# HTTP proxy configuration used by xo-server to fetch resources on the
# Internet.
#
# See: https://github.com/TooTallNate/node-proxy-agent#maps-proxy-protocols-to-httpagent-implementations
#httpProxy = 'http://jsmith:qwerty@proxy.lan:3128'

# Configuration of the embedded HTTP server.
[http]
# If set to true, all HTTP traffic will be redirected to the first
# HTTPs configuration.

redirectToHttps = true

# Basic HTTP.
[[http.listen]]
# Port on which the server is listening on.
port = 80


# Basic HTTPS.
[https]
#
# You can find the list of possible options there https://nodejs.org/docs/latest/api/tls.html#tls.createServer
#
# The only difference is the presence of the certificate and the
# key.

hostname = '0.0.0.0'

[[http.listen]]
port = 443

# Whether to autogenerate a self signed certificate if the `cert` and `file`
# entries could not be found.
#
# Default: true
#autoCert = false
autoCert = true

# File containing the certificate (PEM format).
#
# If a chain of certificates authorities is needed, you may bundle
# them directly in the certificate.
#
# Note: the order of certificates does matter, your certificate
# should come first followed by the certificate of the above
# certificate authority up to the root.
#cert = '/etc/ssl/cert.pem'
cert = '/etc/ssl/xoa.cert.pem'

# File containing the private key (PEM format).
#
# If the key is encrypted, the passphrase will be asked at
# server startup.
#key = '/etc/ssl/key.pem'
key = '/etc/ssl/xoa.key.pem'

# ACME (e.g. Let's Encrypt, ZeroSSL) CA directory
#
# Specifies the URL to the ACME CA's directory.
#
# A identifier `provider/directory` can be passed instead of a URL, see the
# list of supported directories here: https://www.npmjs.com/package/acme-client#directory-urls
#
# Note that the application cannot detect that this value has changed.
#
# In that case delete the certificate and the key files, and restart the
# application to generate new ones.
#
# Default is 'letsencrypt/production'
acmeCa = 'zerossl/production'

# Domain for which the certificate should be created.
#
# This entry is required.
acmeDomain = 'xoa.mydomain.com'

# Optional email address which will be used for the certificate creation.
#
# It will be notified of any issues.
acmeEmail = 'myemail@mydomain.com'

The acmeDomain needs to be the actual Fully Qualified Domain Name (FQDN) which XOA uses. Also some verification and/or validation will need to be added either as a text file to the XOA appliance (in a web accessible directory) or as a DNS text record for XOA FQDN.

Also update the acmeEmail so its the actual email to be used for receiving the notification of issues. These don't look valid to me this is critical for them to be real, active and valid as the ACME Client uses these to send the certificate requests and renewals to the certificate authority!!

john.c

@peb2 Oh, last night I forget to mention you also need to set the https hostname, as well as redirect to https and then after making the alterations. The file must be saved, the editor exited and then the xo-server service (daemon) restarted. When the xo-server service (daemon) is restarted you will lose connection to XOA, but briefly not as long as it would be if the appliance itself was restarted.

peb2

@john-c Thanks for your help sofar! The FQDN and email fields were changed for the post online, they're corrected in the actual config.toml.

I tried adding the hostname line with the FQDN to both the #basic HTTP and #basic HTTPS sections but it still doesn't seem to be grabbing the acmeDomain correctly.

This is what the Certificate says when I view it:

Common Name (CN) <Not Part Of Certificate>
Organization (O) Internet Widgits Pty Ltd
Organizational Unit (OU) <Not Part Of Certificate>

There doesn't seem to be a manpage for xo-server, is there somewhere I can see the full set of configuration options?

edit: nevermind I found the journal entries and it looks like the problem is:

Jul 29 15:33:40 xoa xo-server[3893]: strict mode: required property "discoveryURL" is not defined at "#/anyOf/0" (strictRequired)

john.c

@peb2 said in XOA letsencrpyt module not setting acmeDomain:

@john-c Thanks for your help sofar! The FQDN and email fields were changed for the post online, they're corrected in the actual config.toml.

I tried adding the hostname line with the FQDN to both the #basic HTTP and #basic HTTPS sections but it still doesn't seem to be grabbing the acmeDomain correctly.

This is what the Certificate says when I view it:

Common Name (CN) <Not Part Of Certificate>
Organization (O) Internet Widgits Pty Ltd
Organizational Unit (OU) <Not Part Of Certificate>

There doesn't seem to be a manpage for xo-server, is there somewhere I can see the full set of configuration options?

edit: nevermind I found the journal entries and it looks like the problem is:

Jul 29 15:33:40 xoa xo-server[3893]: strict mode: required property "discoveryURL" is not defined at "#/anyOf/0" (strictRequired)

Did you install XO as an appliance or from the sources?
If from the sources what commit are you using?
If as an appliance what version of XOA are you using?
Also if as an appliance what update channel are you on?

@olivierlambert Could the journal entry above be evidence of a bug in the Xen Orchestra source code?

peb2

@john-c

I'm running the appliance, XOA version 5.95.1, stable release channel.

I'm also seeing this error in the journal:

Jul 29 15:33:59 xoa xo-server[3893]: 2024-07-29T19:33:59.287Z xo:mixins:sslCertificate WARN couldn't renew ssl certificate {
Jul 29 15:33:59 xoa xo-server[3893]:   acmeDomain: 'www.mydomain.com',
Jul 29 15:33:59 xoa xo-server[3893]:   error: Error: The request must include a value for the "externalAccountBinding" field

So it looks like there may be some letsencrypt account setup I need to do before this will work.

john.c

@peb2 said in XOA letsencrpyt module not setting acmeDomain:

@john-c

I'm running the appliance, XOA version 5.95.1, stable release channel.

I'm also seeing this error in the journal:
Jul 29 15:33:59 xoa xo-server[3893]: 2024-07-29T19:33:59.287Z xo:mixins:sslCertificate WARN couldn't renew ssl certificate {
Jul 29 15:33:59 xoa xo-server[3893]:   acmeDomain: 'www.mydomain.com',
Jul 29 15:33:59 xoa xo-server[3893]:   error: Error: The request must include a value for the "externalAccountBinding" field
So it looks like there may be some letsencrypt account setup I need to do before this will work.

The config file isn't for Let's Encrypt but for the ZeroSSL provider. However ZeroSSL has been recently requiring EAB for users of the ACME protocol. The Let's Encrypt provider doesn't require this currently, but only issues certificates for 90 days.

Till the EAB issue is fixed with the XOA module it may be best to use the Let's Encrypt provider as this will work.

@olivierlambert Can the acme-client nodejs package please be updated in Xen Orchestra and add extra config parameters in the Xen Orchestra integration plugin for ACME to support EAB? The most recent versions of acme-client nodejs npm software will support External Account Binding (EAB) this is required for ZeroSSL and/or other CA services which have separate systems for customer management.

olivierlambert

That's a question for @julien-f when he's back. Please create a GH issue

peb2

@john-c

Thank you!

I switched the provider over to 'letsencrypt/production' and now everything is working. The 90 day renewal isn't an issue for me since the server renews automatically.

john.c

@olivierlambert said in XOA letsencrpyt module not setting acmeDomain:

That's a question for @julien-f when he's back. Please create a GH issue

Would you classify it as a bug and/or feature request for the GitHub issue?

olivierlambert

Doesn't really matter, what matters is to explain in details the "why"

john.c

This post is deleted!

john.c

@olivierlambert I created the issue on GithHub. https://github.com/vatesfr/xen-orchestra/issues/7884

MrGrymReaper created this issue in vatesfr/xen-orchestra

XOA letsencrpyt module not setting acmeDomain

open xo-server fix: Update acme-client npm and introduce support for External Account Binding (EAB) #7884