How to tell the built-in ACME client to include more SANs?

[clsa]

Summary already says it. We have a self-hosted ACME server (step-ca) and would like to include the non-FQDN hostname and its IP address as SANs for compatibility reasons
How to accomplish that through native Proxmox features?

https://pve.proxmox.com/pve-docs/pvenode.1.html doesn't appear to include suitable config options.

Thank you.

 

[clsa]

Anyone?

 

[phauch]

It appears that utilizing IP addresses with ACME is currently experiencing issues, as Proxmox writes the IP addresses into the DNS SAN fields. You can find more information about this bug at https://bugzilla.proxmox.com/show_bug.cgi?id=4687.

 

[clsa]

Thank you for the hint.
But how did you make the built-in ACME client picking up SANs at all?

 

[phauch]

Thank you for the hint.
But how did you make the built-in ACME client picking up SANs at all?

At the beginning, I also had this question, and it wasn't entirely clear from the documentation. However, all you need to do is to add multiple domains under Node -> System -> Certificates -> ACME. Since only one challenge type can be used per node, Proxmox automatically combines all domain entries into a single certificate.
Of course, you can also set this up via the command line using pvenode config set --acme "account=my-acme-account,domains=proxmox01.example.com;proxmox.example.com;10.0.0.1" and query it using pvenode config get.

Hope this helps!

 

[clsa]

Unfortunately short/non-FQDN hostnames (just "proxmox" instead of "proxmox.example.com") are still rejected when using this method:

400 Parameter verification failed.
acme: invalid format - format error
acme.domains: invalid format - value 'proxmox-srv' does not look like a valid domain name!

Since the bug you mentioned doesn't appear to get much attention, digging into the source code to find a workaround might be worth the effort. Initially i thought i'm only missing some non-obvious CLI argument, but the problem probably goes deeper.

 

[VictorSTS]

Not sure, but this is probably due to PVE supporting only Let's Encrypt as ACME server [1]:

Currently, the two ACME endpoints implemented are the Let’s Encrypt (LE) production and its staging environment.

Given that LE requires an Internet resolvable names, makes sense that PVE doesn't support non-FQDN names.

[1] https://pve.proxmox.com/wiki/Certificate_Management#sysadmin_certs_get_trusted_acme_cert

 

[clsa]

Not sure, but this is probably due to PVE supporting only Let's Encrypt as ACME server

Exactly. acme.sh perfectly supports IPs as SANs. So why is Proxmox blocking this feature (or not implementing it correctly based on https://bugzilla.proxmox.com/show_bug.cgi?id=4687)?

Given that LE requires an Internet resolvable names, makes sense that PVE doesn't support non-FQDN names.

You must not confuse SANs with the requirements for validation. Finally there is already an RFC document for IP based validation: https://datatracker.ietf.org/doc/rfc8738/

 

[phauch]

Not sure, but this is probably due to PVE supporting only Let's Encrypt as ACME server [1]:


Given that LE requires an Internet resolvable names, makes sense that PVE doesn't support non-FQDN names.

[1] https://pve.proxmox.com/wiki/Certificate_Management#sysadmin_certs_get_trusted_acme_cert

Actually Proxmox does support other ACME servers. But they can only be added via cli:

pvenode acme account register default info@example.com --directory https://ca.example.com/acme/acme/directory