ACME Certificates & Information disclosure

[proxuser77]

I would just go with running acme.sh directly from the CLI — or Certbot, like I suggested in my first answer.

I mean, sure, it would be great if Proxmox could do wildcard certs natively, but unfortunately it can’t (yet).

Of course, there are many other possibilities, but since you seem to rule out all alternatives categorically and have decided that Wildcard certificates are necessary and that the Proxmox host itself must obtain them, the only real option is to use an ACME client from the command line. As Proxmox is based on Debian, which is a standard Linux system, it shouldn't be too difficult to write a short script to move the certificates to the correct location and restart the relevant PVE services.

If you have another physical host, you could install the ACME client there. Then you might be able to upload the certificates via the PVE API (haven't tested this), so you don’t have to give that host root permissions on your PVE host: https://forum.proxmox.com/threads/upload-custom-cert-via-proxmox-api.101300/
However, this would only make things more complicated, and if your PVE hosts go down, it won't help if your ACME client is still up, unless these wildcard certs are also used elsewhere.

@janus57 Bastion Hosts is a completely different topic, although it can of course make sense to have something like that, because exposing management interfaces to a client network in a larger company is almost as bad as exposing them to the internet. In a home lab or small business however, it would proabably be overkill ;-)

 

[janus57]

Hi,

@janus57 Bastion Hosts is a completely different topic, although it can of course make sense to have something like that, because exposing management interfaces to a client network in a larger company is almost as bad as exposing them to the internet. In a home lab or small business however, it would proabably be overkill ;-)

Agree.
But other solution than public wildcard exists to use in envrionnement when the PVE are not expected to be reachable from the internet and are in a closed network.

If the "fear" is only the browser warning because it's a self-signed versus giving OSINT data for bad actors (the point made by the OP), well just trust the self-signed => done.

Public certificates are subject to Certificate Transparency (CT), and the initial goal of CT if I'm not mistaken is to audit all certificated that are emitted by public CA and can help with "rogue" certificate emitted by a bad actor with a public CA.

So yeah I don't understand why wildcard should be more secure than not using public CA if you want to hide your data and your isolated hypervisor.

Best regards,

 

[proxuser77]

I am a little ambivalent about this, but I must also admit that I am not an expert when it comes to certificates.

On the one hand, I agree with you that a certificate that only has one name in the certificate for a specific server is likely more secure.

On the other hand, I can understand that people don’t want all their hostnames in a public directory, but I don’t personally see that as a really big problem. It’s just another security-by-obscurity thing that can be minimally useful if someone gets acces to your network, so that they can’t draw conclusions about what else might be running there based on the hostnames. But as I said, it’s a minimal security gain, if any.

What I definitely understand, however, is that people want to have trusted certificates, because browser warnings are annoying. With Chrome-based browsers, you have to approve them every time. Firefox at least remembers the certificates once you’ve accepted them. And no, running your own CA and loading the certificates on all devices is too much effort in a homelab, in my opinion.

And I'll admit that I also use a wildcard certificate in my home lab for certain services that are only accessible locally, not so much because of the security-through-obscurity aspect, but rather out of convenience.

 

[guruevi]

Here's my hook script for certbot on PVE and PBS:

#!/usr/bin/env sh
LE_DIR=/etc/letsencrypt/live/"$(hostname -f)"

# If pvenode exists, we're on PVE
if [ -f /usr/bin/pvenode ]; then
/usr/bin/pvenode cert set "$LE_DIR"/fullchain.pem "$LE_DIR"/privkey.pem -force
systemctl reload pveproxy.service
# If proxmox-backup exists, we're on PBS
elif [ -d /etc/proxmox-backup ]; then
# Copy to proxy.key and proxy.pem
cp "$LE_DIR"/fullchain.pem /etc/proxmox-backup/proxy.pem
cp "$LE_DIR"/privkey.pem /etc/proxmox-backup/proxy.key
chmod 640 /etc/proxmox-backup/proxy.key /etc/proxmox-backup/proxy.pem
chgrp backup /etc/proxmox-backup/proxy.key /etc/proxmox-backup/proxy.pem
# Reload the service
systemctl reload proxmox-backup-proxy.service
fi