Wildcard certificate

no - wildcard support is not yet implemented.
 
Hmm, while one can use the PVE acme integration for such a thing, it may really be nicer to automate the setup for the VMs (with ansible or something similar) and use acme.sh directly in their, once setup it's all automatically anyway.. I mean, once can have a lot of VMs/CTs per node, and it's really not designed for this. Also ACME has various rate limiting knobs they enforce, e.g., 50 new certs ordered over the same IP per week, one would need to use SAN (subject alternative names) to be efficient enough for such a case...

I mean, some improvements to efficiency are planed anyway, but not sure if/how we can open this up for 10s to 100s of certificates per node..
 
It seems to me that what you are asking for is a bit more than just support for wildcard certs or multiple certs (either directly or via alternate names).

What the Proxmox team has delivered is a mechanism mainly targeted towards delivering and managing Acme certs for the Proxmox hosts themselves, including using DNS-based Acme to help when those hosts are not exposed to the internet and can't use the port-80/webserver method. And I would offer the Proxmox team a HUGE thank you for doing is.

What it appears you are looking for is a much more general certificate management tool to manage certs for VM and Container guests. While I think having Proxmox enable Acme wildcard certs and/or multiple certs/multiple SANs could help you improvise this it would be much better to look at something more comprehensive, to wit:
  • Need to identify guests (VM or container) that require certs
  • Automatically set up Acme cert requests for those VMs
  • Deliver the certs to the guest on initial start (possibly via Cloud-init or other mechanism)
  • Periodically request new certs, deliver those certs to the guest, and inform the guest of the update.
  • Perhaps more...
This would be a significant effort. Probably well worth it, BTW, and consistant with how Proxmox has been evolving to integrate tools to support efficient management of guests. But it is also well beyond the scope of the Acme integration they have delivered to date.
 
What I have set up is a VM using acme and the appropriate API for my domain registrar. I then have that machine automatically renew the certificates shortly before they expire and store then on that VM, which also has a samba server running on it that allows READ-ONLY access to specified IP addresses that also need to authenticate via a username and password. Then any machine that needs access to the SSL certs is grated access to this share. This allows for both wildcard certs as well as machines that are not exposed to the internet or don't have internet access to still have valid SSL certs, which are mostly Nginx reverse proxies. My next plan is to have the SSL updater to once the certs are updated trigger and reload of the Nginx server to intake the new SSL cert.
 
I have the same situation with wildcard certificates.

Aggregating the comments in this thread I suggest to implement wildcard certificates in PVE, make the certificate number limit user-configurable with a sensible default value and use file-sharing to provide the wildcard certs to other hosts/VMs.

SAN-certificates can contain up to 100 domain names. A wildcard domain needs 2 domain names: "example.org" and "*.example.org".
This means a single SAN-certificate can contain up to 50 wildcard domains.
 
Last edited:
  • Like
Reactions: Josua27176
This limit is per node, and it comes from us. Why do you need more than 5 domains per single node?
for clarity... is this 5 SANs per node? or 5 distinct domains?

this could easily be eaten up with (node storage face) (node pubic face) (node internal face) (cluster-wide public face) (cluster-wide storage face). any additional decorative blessing (say a backup-scoped face) would exceed the 5 SANs... but... admittedly, something of an advanced use-case
 
for clarity... is this 5 SANs per node? or 5 distinct domains?

this could easily be eaten up with (node storage face) (node pubic face) (node internal face) (cluster-wide public face) (cluster-wide storage face). any additional decorative blessing (say a backup-scoped face) would exceed the 5 SANs... but... admittedly, something of an advanced use-case
and all of those need to provide the PVE management API/web UI? ;)
 
and all of those need to provide the PVE management API/web UI? ;)
In a situation where you want to give multiple customers access to proxmox via their own (sub-)domains, yes.
If one wants PVE to provide certificates to e.g. virtual machines, no.
 
that was not the example given though (having more than five interfaces is not uncommon, but usually you have one of them scoped for API/UI access, and the others are for separating certain traffic (corosync, storage, ..).

if you want more SANs, there's always the option of using your own ACME/LE client and just handing the cert to PVE (pvenode cert set CHAIN.pem KEY.pem --force --restart)
 
I appreciate this is a bit old, but I fell over this issue today as well, proxmox does not work with wildcard certs, UNLESS it's a multi-domain SSL, in which case you can use a wildcard as a SAN - as long as the cert supports it.

The cert you need is a Multi-Domain Wildcard SSL.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!