PVE ACME client generating bad CSR for IP addresses

M

Machine Manager

Member
Oct 10, 2022
48
2
13
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`:

Code: 
* 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:

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

Instead, the CSR should request:

Code: 
[...]
            X509v3 Subject Alternative Name: 
                DNS:pve.host, IP Address:10.1.1.7
[...]
 
Debugging further, I've found this message in the ACME server logs:

Code: 
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:

Code: 
"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
 
Machine Manager said:
I have other clients passing the identifier type as "ip", and they get a valid certificate.
Click to expand...
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...
 
UdoB said:
Probably for a "real" address?
Click to expand...

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.
 
You must log in or register to reply here.
Top Bottom