ACME Certificates & Information disclosure

S

ShotokanZH

New Member
Mar 1, 2025
9
0
1
Hi everyone,

I'm holding off on using the built-in ACME/Let's Encrypt integration in Proxmox VE for a specific reason, and I wanted to get your thoughts on it.

The current implementation doesn't support wildcard certificates. This means I have to generate a specific certificate for each subdomain (e.g., proxmox.mydomain.com, nas.mydomain.com, etc.). The downside of this approach is that every subdomain gets publicly listed on Certificate Transparency logs like crt.sh. While this might be a minor issue for some, for others, it's an unnecessary information disclosure.

I've considered using an internal Certificate Authority (CA), but that's not a practical solution for my team. We don't operate in a domain environment, which would make the process of manually trusting the CA on all my colleagues' computers quite cumbersome.

This leads me to my main question: do I really need to spin up a dedicated container with something like Nginx Proxy Manager just to handle wildcard certificates and keep my subdomains private? It feels a bit redundant, as this is functionality that Proxmox could potentially handle directly.

It seems like a small oversight, but the lack of wildcard support essentially creates a minor, yet significant for many, information disclosure issue by default.

Am I missing something, or is a separate reverse proxy the only viable workaround for now?

Thanks for your input!
 

I guess you could use acme.sh or Certbot (certbot certonly / DNS challenge) directly from the command line, and then copy the certificates to the correct location.

To automate this, you could either write a bash script and execute it via cron, or use Certbot’s post hooks.

I’ve never set this up myself, so I can’t offer you a step-by-step guide.
 
Last edited:
  • Like
Reactions: ShotokanZH
I agree but it makes no sense that we can't request a wildcard directly from the UI, it already handles everything, why not handle the wildcard too?
 
ShotokanZH said:
I agree but it makes no sense that we can't request a wildcard directly from the UI, it already handles everything, why not handle the wildcard too?
Click to expand...
Unfortunately, I don’t know why it doesn’t work, and to be honest, I didn’t know it wasn’t possible in the first place. Could be a bug, or indeed a missing feature.

I found this in the PBS documentation: https://pbs.proxmox.com/docs/sysadmin.html#wildcard-certificates. Unfortunately, the same section doesn’t appear to be in the PVE documentation, so it might indeed not be implemented.

Maybe you could consider opening an issue/feature request here: https://bugzilla.proxmox.com/.
 
Last edited:
it's currently not implemented, and that dialogue is not where you enter the domains that go into the cert either..
 
Wildcard certificates are a huge risk in and of themselves. What is an attacker going to do with information they can probably get or guess some other way? DNS records aren’t secrets.

A wildcard certificate allows a single compromise to compromise everything, it allows subdomain abuse which you may not even notice. You also now need to distribute your private key to multiple systems.

You are choosing security through obscurity and in the process making your systems much less secure.
 
Last edited:
guruevi said:
Wildcard certificates are a huge risk in and of themselves. What is an attacker going to do with information they can probably get or guess some other way? DNS records aren’t secrets.

A wildcard certificate allows a single compromise to compromise everything, it allows subdomain abuse which you may not even notice. You also now need to distribute your private key to multiple systems.

You are choosing security through obscurity and in the process making your systems much less secure.
Click to expand...
I mean, if someone hacks the main proxmox server hosting everything the wildcard certificate on it is the last of my problems.
Furthermore, if someone is able to retrieve the wildcard certificate from the server it means that they can retrieve the letsencrypt configuration too, and that can be used to create a wildcard certificate so... Not really a problem?
 
But usage like that tends to spread. Can you say the same about security for your NAS? Your Plex server? Anything you've put actually online? It isn't always necessary to get root to be able to compromise these things.

The problem is also in transporting the certificate itself, Certbot doesn't do distribution, can you be certain the permissions are correct? Your transport isn't compromised etc? I've seen techs copy the certificate to their desktop, then copy it to another server, then leave the private key just laying around on a much less secure system or even "backup" or accidentally included it onto a more accessible system like a flash drive or even GitHub.
 
fabian said:
it's currently not implemented, and that dialogue is not where you enter the domains that go into the cert either..
Click to expand...
It's literally the only dialogue that you can interact with before pressing "Order certificate now".
1755008533968.png
Am I missing something? I am literally in Host -> System -> Certificate
 
guruevi said:
But usage like that tends to spread. Can you say the same about security for your NAS? Your Plex server? Anything you've put actually online? It isn't always necessary to get root to be able to compromise these things.

The problem is also in transporting the certificate itself, Certbot doesn't do distribution, can you be certain the permissions are correct? Your transport isn't compromised etc? I've seen techs copy the certificate to their desktop, then copy it to another server, then leave the private key just laying around on a much less secure system or even "backup" or accidentally included it onto a more accessible system like a flash drive or even GitHub.
Click to expand...
I agree with you, you have my point there, that's literally why I would love proxmox to be able to manage the certificate by itself.
I don't want to move / copy certificates as I find it stupid.
And if I can avoid screaming to the world where my proxmox hosts are that would be way better.
 
ShotokanZH said:
It's literally the only dialogue that you can interact with before pressing "Order certificate now".
Click to expand...

sorry, yes, I mistook it for the DNS configuration dialogue. the point still stands though - wildcard certificates are not yet implemented, see the referenced bug report.
 
ShotokanZH said:
And if I can avoid screaming to the world where my proxmox hosts are
Click to expand...
crt.sh does not expose any IP information. So, if you are using the DNS challenge and the servers are only accessible locally on your LAN with no public DNS records, nobody can see where the servers are.
 
proxuser77 said:
crt.sh does not expose any IP information. So, if you are using the DNS challenge and the servers are only accessible locally on your LAN with no public DNS records, nobody can see where the servers are.
Click to expand...
Sure, but I'm still exposing a useless information. As you correctly stated, why should I give the internet a LAN-Only information?
Even if it's small and probably insignificant, it's still something a bad actor could use.
 
Hi,

ShotokanZH said:
Even if it's small and probably insignificant, it's still something a bad actor could use.
Click to expand...
In that case, why use public CA, it's better to use internal CA which are not known from the internet.

If you don't want to publicly "leak" data, why using public infrastructure ?

Best regards,
 
Hi,

ShotokanZH said:
Just read the first message :)
Click to expand...
Sorry I don't see the issue.

Many tools/Ways exist to do this even in non-domain network.

Few examples :
- Bastion VM -> Only this VM can access hypervisor infrastructure (and session can be monitored/registered) and has the certificate trusted
- Software to manage computers, like WAPT

Using public CA is just the easy way, not the only way event more if you don't to be tracked by certificate transparency.

Best regards,
 
janus57 said:
Hi,


Sorry I don't see the issue.

Many tools/Ways exist to do this even in non-domain network.

Few examples :
- Bastion VM -> Only this VM can access hypervisor infrastructure (and session can be monitored/registered) and has the certificate trusted
- Software to manage computers, like WAPT

Using public CA is just the easy way, not the only way event more if you don't to be tracked by certificate transparency.

Best regards,
Click to expand...
Bastion VM is useless if you only have vms in those servers, as how can you reach the hypervisor if the vm is not starting due to something happening in the proxmox vm itself?
(Maybe the vm got "fenced" over another host or you are having issues with the intercommunication link between the two servers)
Again, I already said that I considered a thing like that already in the first message, it just sounds stupid that wildcard automatic deployment is not supported, as it's literally in the acme specifications.
"It's dangerous"? Sure, but even allowing shell access it's dangerous, should we remove the root web shell from proxmox next?
 
Hi,

ShotokanZH said:
Bastion VM is useless if you only have vms in those servers, as how can you reach the hypervisor if the vm is not starting due to something happening in the proxmox vm itself?
Click to expand...
Never said this VM should be on the hypervisor, just put this on separate hardware (just common sense at this point).

ShotokanZH said:
"It's dangerous"? Sure, but even allowing shell access it's dangerous, should we remove the root web shell from proxmox next?
Click to expand...
i never said it's dangerous.
My point it's just dumb to use public providers to generate a certificate to use it on lan-only infra.

On our infra we use, the certificate generated by proxmox and trust him and that it.

Best regards,
 
You must log in or register to reply here.
Top Bottom