Certificates and TLS

Why this matters in production

A web UI that triggers a “your connection is not private” warning trains users to click through certificate errors. That is the worst possible outcome. Production Proxmox should have trusted certificates — either from an internal CA or from ACME/Let’s Encrypt.

Certificate sources

Proxmox VE uses a single certificate for the web UI (pveproxy) and the API:

The certificate is stored in /etc/pve/local/pveproxy-ssl.pem (and the key separately). The cluster-wide certificate lives in /etc/pve/pveproxy-ssl.pem; per-node certificates are in /etc/pve/nodes/<node>/pveproxy-ssl.pem.

Inspecting the current certificate

openssl x509 -in /etc/pve/local/pveproxy-ssl.pem -noout -subject -dates -issuer

pvecm status | grep -i quor && for n in $(pvecm node list | awk '/^[a-z]/ {print $1}'); do echo "=== $n ==="; pvesh get /nodes/$n/certificates/info 2>/dev/null; done

ACME configuration

ACME (Automated Certificate Management Environment) is supported out of the box. Proxmox can use:

• Let’s Encrypt (public, requires DNS or HTTP validation).
• Any ACME v2-compatible CA (e.g., smallstep, internal ACME server).

sequenceDiagram
  participant P as pveproxy
  participant A as ACME client
  participant CA as ACME server
  P->>A: request certificate
  A->>CA: register account
  A->>CA: request cert for pve.example.com
  CA->>A: HTTP-01 / DNS-01 challenge
  A->>CA: complete challenge
  CA-->>A: signed certificate
  A->>P: install cert
  P->>CA: auto-renew before expiry

The ACME client can use either:

• HTTP-01 challenge: Proxmox answers the challenge on port 80. Requires the node to be reachable on port 80 from the CA.
• DNS-01 challenge: Proxmox updates DNS records via an API. Required when the node is not publicly reachable, or for wildcard certificates.

pvenode acme cert register

Internal CA

For internal PKI, generate a CSR and have it signed by your CA:

openssl req -new -newkey rsa:4096 -nodes -keyout /etc/pve/priv/pveproxy-ssl.key -out /tmp/pve.csr -subj '/CN=pve-01.lab.example.com'

Then have your CA sign the CSR, returning a certificate. Install it:

cp /path/to/signed.crt /etc/pve/local/pveproxy-ssl.pem && systemctl reload pveproxy

Certificate expiry monitoring

Expired certificates break:

• The web UI (browsers refuse to connect).
• The API (clients fail TLS validation).
• PBS-to-PVE backup transport if certificates don’t match.

Monitor expiry via the GUI (Datacenter → Certificates) or via a script:

for n in $(pvecm node list 2>/dev/null | awk '/^[a-z]/ {print $1}'); do
exp=$(pvesh get /nodes/$n/certificates/info 2>/dev/null | grep -oE 'notafter=[^,]+' | head -1 | cut -d= -f2)
echo "$n expires $exp"
done

Production considerations

Common mistakes

• Leaving the self-signed cert in production and training users to ignore the warning.
• Disabling port 80 and trying to use HTTP-01 ACME. Use DNS-01 instead.
• Relying on a certificate that no one monitors. Add expiry to your monitoring stack.
• Failing to back up the certificate + key. Lose them, and recovery is harder.

Key takeaways

• Replace self-signed certificates in production with internal CA or ACME.
• ACME supports HTTP-01 and DNS-01 challenges; DNS-01 works for firewalled nodes.
• Monitor expiry; auto-renewal can fail.

Knowledge check