PVE ACME client generating bad CSR for IP addresses

[Machine Manager]

I am using an ACME server other than Let's Encrypt, and I observe PVE is having issues creating the CSR for IP addresses.

Depending of the order of the domains (the actual domain and the IP) to be verified I add in the GUI to be verified it creates a bad CSR that is not accepted by the ACME server.

If I try a different order, then I may get the certificate. However, the IP comes in the certificate as a DNS entry, not as an IP entry. So, any HTTPS request is refused because the Subject Alternative Name does not match due to the wrong entry type. As reported by `curl`:

* Server certificate:
*  subject: CN=pve.host
*  start date: Apr 21 12:24:03 2023 GMT
*  expire date: Apr 22 12:25:03 2023 GMT
*  subjectAltName does not match 10.1.1.7
* SSL: no alternative certificate subject name matches target host name '10.1.1.7'
* Closing connection 0

Inspecting the certificate:

[...]
            X509v3 Subject Alternative Name:
                DNS:10.1.1.7, DNS:pve.host
[...]

Instead, the CSR should request:

[...]
            X509v3 Subject Alternative Name: 
                DNS:pve.host, IP Address:10.1.1.7
[...]

 

[Machine Manager]

Debugging further, I've found this message in the ACME server logs:

error="error finalizing order: CSR IPs do not match identifiers exactly: CSR IPs = [10.1.1.7], Order IPs = []"

In addition, there is this other piece of information logged, from the POST request sent to the ACME server:

"identifiers\":[{\"type\":\"dns\",\"value\":\"10.1.1.7\"}]

I have other clients passing the identifier type as "ip", and they get a valid certificate.

So, the issue is caused by the incorrect identifier type sent in the POST by PVE in the finalization step.

Then, I've opened this issue: https://bugzilla.proxmox.com/show_bug.cgi?id=4687

 

[UdoB]

I have other clients passing the identifier type as "ip", and they get a valid certificate.

Probably for a "real" address?

If letsencrypt (or any other CA) would sign this then you would have a valid certificate for a server inside of thousands of local networks. This can not be allowed...!

The only way to get a certificate for RFC1918 addresses is to run a local Certificate Authority which then has to be distributed to your clients.

AFAIK...

 

[Machine Manager]

Probably for a "real" address?

The addresses are real addresses, and they can be validated by the ACME server. That's why I can get a certificate, and I also tested with a different client hitting the ACME server from PVE itself.

In addition, the certificate I get with the IP address incorrectly set as a DNS record, and also the log messages, they both point to the actual error that is the identifier in the POST request being wrong.

 

[phauch]

For your reference (and for anyone else encountering this issue), there is an open bug at https://bugzilla.proxmox.com/show_bug.cgi?id=4687.