You just finished installing Proxmox VE. You type https://192.168.1.50:8006 into your browser, hit enter, and instead of the login screen you get a wall of red text. Chrome calls it "Your connection is not private." Firefox calls it "Warning: Potential Security Risk Ahead." Either way, your stomach drops a little — did the install fail? Did something hijack your network?
Nothing is wrong. This is completely normal, and it happens on every single fresh Proxmox VE install, every time, on every network. The warning is about a self-signed certificate, not a broken server. By the end of this guide you'll know exactly why it shows up, when it's fine to click through it, and how to make it disappear for good on the machines you actually trust.
What You Will Learn
- Why Proxmox VE ships with a certificate your browser doesn't already trust
- What "self-signed" actually means, and why it isn't the same as "insecure"
- How to tell a normal first-login warning from an actual problem
- How to pull the Proxmox root CA off your server and import it into Windows, macOS, and Linux
- How to fix certificate errors that show up after you rejoin a node or change its IP address
- When it's actually worth switching to a real, publicly trusted certificate instead
What Is This Feature?
Every HTTPS connection needs a certificate to prove the server is who it claims to be, and to encrypt the traffic between your browser and that server. Certificates are normally signed by a Certificate Authority, or CA — an organization your browser already trusts, like Let's Encrypt or DigiCert. When a cert is signed by a CA your browser recognizes, you get the quiet padlock icon and no warnings.
Proxmox VE doesn't wait for you to set any of that up. During installation, each Proxmox VE node creates its own private CA and uses it to sign a certificate for itself. That's what "self-signed" means here — the cluster is vouching for its own certificate instead of a third party doing it. The CA certificate lives at /etc/pve/pve-root-ca.pem, the CA's private key at /etc/pve/priv/pve-root-ca.key, and the actual certificate your browser receives sits at /etc/pve/nodes/<nodename>/pve-ssl.pem with its key alongside it as pve-ssl.key. All of this is managed by pveproxy, the service that serves the web interface and REST API on port 8006, and it's stored inside pmxcfs — Proxmox's own cluster filesystem that keeps configuration in sync across every node in a cluster.
Your browser has no idea who Proxmox's private CA is, so it can't verify the chain of trust on its own. It falls back to the only honest thing it can do: warn you.
Why Would You Use It?
You might wonder why Proxmox doesn't just ship with a trusted certificate baked in. It can't — a publicly trusted CA has to verify that you actually control the domain name a certificate is issued for, and Proxmox has no way to know your domain, your IP, or whether you even have one at install time. Most Proxmox hosts also live on private IP addresses inside a home network or a data center rack, with no public DNS name at all. A public CA won't issue a certificate for 192.168.1.50.
So Proxmox does the next best thing: it encrypts everything immediately with a self-signed cert, so your traffic is never sent in plaintext, and leaves trust verification up to you. The connection is encrypted from the first second you install it. What's missing is third-party proof of identity, not encryption itself.
If your Proxmox node does have a real domain name and is reachable on port 80 from the internet, you can swap this out for a Let's Encrypt certificate through Proxmox's built-in ACME client under Datacenter → Certificates. That's a different setup with its own prerequisites (a domain, DNS or port 80 access) and it's worth doing if your host is internet-facing. For a homelab box sitting behind your router on a private IP, though, it's usually not worth the hassle — you'd be trading a two-minute browser warning for ongoing DNS or port-forwarding maintenance.
Prerequisites
- A working Proxmox VE install (this applies the same way on 8.x and 9.x)
- SSH access to the node, or access to its local console
- Admin rights on whichever computer you're browsing from, since importing a certificate into the system trust store needs elevated permissions
- The node's hostname or IP address as you actually type it into the browser
Step-by-Step Tutorial
Step 1: Recognize what you're actually looking at
Open the Proxmox web interface at https://your-server-ip:8006. Chrome, Edge, and most Chromium-based browsers show "Your connection is not private" with an error code like NET::ERR_CERT_AUTHORITY_INVALID. Firefox shows "Warning: Potential Security Risk Ahead" with a code like SEC_ERROR_UNKNOWN_ISSUER. Both mean the same thing: the browser reached the server fine, the connection is encrypted fine, but it can't verify who signed the certificate. That's expected. It is not the same as a man-in-the-middle warning where the certificate details have actually changed unexpectedly — we'll cover how to tell those apart later.
Step 2: Proceed for now (if this is your own server)
Assuming you're connecting directly to a Proxmox host you just installed yourself, on your own network, it's fine to click through. In Chrome, click Advanced, then Proceed to [ip] (unsafe). In Firefox, click Advanced, then Accept the Risk and Continue. You'll land on the normal Proxmox login page. This gets you in the door, but the warning will come back every time you open a new browser or clear your cache — clicking through isn't a permanent fix, just a way to confirm the server itself is fine.
Step 3: Copy the CA certificate off the node
To make the warning go away for good, your computer needs to trust the CA that signed the certificate, not just the certificate itself. There's no download link in the web UI for this — Proxmox doesn't expose the root CA over the API or the GUI on purpose, since that file identifies your cluster's trust anchor. You have to pull it via SSH or SCP.
From a terminal on your own computer, run:
scp root@your-server-ip:/etc/pve/pve-root-ca.pem .This copies the CA certificate into your current directory. It's just the public certificate, not the private key, so it's safe to move around — you're only handing out proof of what the CA looks like, not the ability to sign new certificates with it.
Step 4: Import the CA into your trust store
Where you import it depends on your operating system and browser.
Windows: Open Internet Options from the Start menu search, go to the Content tab, and click Certificates. Switch to the Trusted Root Certification Authorities tab and click Import. Browse to pve-root-ca.pem — you'll likely need to change the file filter to "All Files" since Windows doesn't recognize the .pem extension by default. Finish the wizard and confirm you trust the certificate when prompted.
macOS: The simplest route is through Safari. Navigate to your Proxmox interface, and when the warning appears, click Show Certificate, then check Always trust, then Continue. This adds it to Keychain Access and applies system-wide, which covers Chrome and Edge too since they use the macOS trust store.
Linux: On Debian or Ubuntu-based systems, copy the file into the trust anchors directory and refresh the store:
sudo cp pve-root-ca.pem /usr/local/share/ca-certificates/pve-root-ca.crt
sudo update-ca-certificatesFirefox, on any OS: Firefox ignores the operating system's certificate store entirely and keeps its own. When you load the Proxmox interface in Firefox after the CA is trusted elsewhere, it'll still warn you the first time — you need to explicitly accept the certificate exception inside Firefox itself, or import the CA under Settings → Privacy & Security → Certificates → View Certificates → Import.
Once the CA is trusted, reload the Proxmox login page. The warning should be gone and you'll see a normal padlock, even though the certificate is still technically self-signed — your browser now recognizes the authority that signed it.
Step 5: Regenerate the certificate if the hostname or IP changed
If you rejoined a node to a cluster with the same hostname it had before, changed its IP address, or restored a node from an old backup, you might get a fresh certificate mismatch even after doing all of the above. Proxmox includes a command specifically for this. Run it on the affected node:
pvecm updatecerts --forceThis regenerates the node's certificate and merges SSH keys and known-hosts entries across the cluster. Follow it with a restart of the proxy service so it actually picks up the new certificate:
systemctl restart pveproxyYou won't need to re-import the root CA after this — the CA itself doesn't change, only the node certificate it signs. If your browser still complains, that's usually a caching issue rather than a real problem; more on that in the troubleshooting section below.
Commands Explained
| Command | What it does |
|---|---|
scp root@ip:/etc/pve/pve-root-ca.pem . | Copies the cluster's CA certificate from the Proxmox node to your current directory over SSH. |
update-ca-certificates | Rebuilds the Linux system trust store after you drop a new certificate into /usr/local/share/ca-certificates/. |
pvecm updatecerts --force | Regenerates the node's SSL certificate (signed by the existing cluster CA) and refreshes cluster-wide SSH key and host data. The -f shorthand works too. |
systemctl restart pveproxy | Restarts the service that serves the Proxmox web interface and API, forcing it to load whatever certificate is currently on disk. |
openssl x509 -in pve-ssl.pem -noout -text | Prints the details of a certificate — issuer, expiry date, and which hostnames or IPs it covers — useful for confirming what you're actually looking at. |
Common Errors
NET::ERR_CERT_AUTHORITY_INVALID (Chrome/Edge) — the normal first-login warning described above. Expected on any un-imported self-signed cert.
SEC_ERROR_UNKNOWN_ISSUER (Firefox) — Firefox's version of the same warning. Same cause, same fix.
Certificate error after re-adding a node with the same IP — old cluster data pointed at a certificate fingerprint that no longer matches. Running pvecm updatecerts --force on the node clears this up.
Warning appears even though you already imported the CA — you likely imported the certificate into the wrong store (say, only the OS trust store while browsing in Firefox), or you're now accessing the node by an IP or hostname the certificate doesn't cover. Proxmox certificates are typically issued for the node's hostname; browsing by raw IP address when the cert was issued for a hostname (or vice versa) triggers a name-mismatch warning even with a trusted CA.
"The certificate has expired" or wildly wrong dates — this is almost never an actual expired Proxmox certificate. It's clock drift. Proxmox certs are typically issued with a multi-year validity window, so if your browser insists it's expired, check the clock on the client machine first.
Troubleshooting
If you've imported the CA and you're still seeing warnings, work through these in order:
- Confirm you imported
pve-root-ca.pem, notpve-ssl.pem. Importing the node certificate instead of the CA will look like it worked but won't hold up once the node certificate is ever regenerated. - Check that the hostname or IP in your address bar matches what's actually in the certificate. Run
openssl x509 -in /etc/pve/nodes/<nodename>/pve-ssl.pem -noout -texton the server and look at the Subject Alternative Name field. - Restart the browser completely, not just the tab. Chrome in particular caches certificate trust decisions per-session.
- If you're on Firefox, remember it keeps a separate certificate store from the OS — go back and import the CA inside Firefox's own settings.
- Double-check the system clock on the client machine. A laptop that's been asleep for a week with a dead CMOS battery is a surprisingly common cause of certificate date errors.
Best Practices
Don't get in the habit of globally disabling certificate warnings in your browser as a shortcut — you'd lose the ability to notice a real problem if one ever showed up. Importing the specific Proxmox CA is targeted and reversible; disabling verification browser-wide is neither.
Treat /etc/pve/priv/pve-root-ca.key as sensitive. You never need to copy this one anywhere — only the public pve-root-ca.pem needs to leave the server. If that private key ever leaked, someone could sign a certificate your browser would trust for anything.
If you manage more than one Proxmox cluster, keep track of which root CA belongs to which cluster before importing several into the same browser. It's not dangerous, just confusing, since your browser won't tell you which cluster a given certificate came from.
Only bother setting up Let's Encrypt if the host is genuinely reachable from the internet on a real domain. For an internal, private-IP homelab node, the self-signed setup plus a one-time CA import gets you the same practical security with a lot less maintenance.
Frequently Asked Questions
Is it actually safe to click "Proceed anyway" on my own Proxmox server?
Yes, as long as you're connecting to a server you set up yourself and reaching it directly (not through some untrusted network path). The connection is still fully encrypted — the warning is only about identity verification, not about the traffic being exposed.
Do I need to do this on every device I use to manage Proxmox?
Yes. Trust is per-device and often per-browser, so you'll need to repeat the CA import on your laptop, your phone, and any other machine you regularly use to log in.
Will this certificate ever expire?
Proxmox self-signed certificates are issued with a long validity period, so you're unlikely to hit expiry in normal use. If you ever do, the fix is the same pvecm updatecerts --force command described above.
What's the difference between this and setting up Let's Encrypt?
This method makes your browser trust Proxmox's own private CA. Let's Encrypt replaces the certificate entirely with one signed by a public CA that every browser already trusts out of the box, so nobody needs to import anything — but it requires a real domain name and a way to prove you control it.
I imported the CA but a coworker on a different laptop still sees the warning. Why?
Because trust is local to each device. You'll need to copy pve-root-ca.pem to their machine and have them import it too — there's no way to push this out from the server side automatically.
Can I just use a self-signed certificate forever and never bother with a real one?
For a homelab or internal server, plenty of admins do exactly that for years without issue. It's a legitimate long-term choice, not just a temporary workaround.
Conclusion
That red warning screen trips up nearly everyone the first time they open Proxmox VE, and it's one of the most-searched "is my server broken" moments for new users — it isn't. Your traffic was encrypted from the first click; the only thing missing was a familiar name vouching for the certificate. Pull the CA off the node, import it once per device, and you'll never see that warning on your own hardware again. If a node's certificate ever gets out of sync after a rejoin or an IP change, you already know the two commands that fix it.