pve-no-subscription CDN edge (de2) returns wrong TLS certificate / 401 for download.proxmox.com

L

lcerabolini

New Member
Sep 7, 2026
3
0
1
Since today (2026-09-07), apt update fails on the pve-no-subscription repository. I've ruled out local network/DNS/config issues on my end — repo file, GPG keyring, and internal DNS resolution all verified correct against public DNS behavior.


DNS chain (via internal resolver, matches expected public CDN chain):



download.proxmox.com → download.cdn.proxmox.com → it.eu.cdn.proxmox.com → de2.cdn.proxmox.com → 185.219.221.167

Behavior observed:


  • HTTP (port 80) to that IP: connection fails outright
  • HTTPS (port 443): TLS handshake succeeds but the server presents a certificate for CN=enterprise.proxmox.com (valid Aug 8 – Nov 6 2026), not download.proxmox.com → SSL: no alternative certificate subject name matches target hostname
  • With TLS verification disabled for this host (to isolate the issue and rule out cert as the only blocker): server responds 401 Unauthorized

Also reproduced on other IPs resolved for the same hostname during testing (51.91.38.34, 45.84.67.184) — same symptoms each time.


/etc/apt/sources.list.d/pve-no-subscription.sources:



Types: deb
URIs: https://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

pveversion -v:

proxmox-ve: 9.2.0 (running kernel: 7.0.2-6-pve)
pve-manager: 9.2.2 (running version: 9.2.2/b9984c6d90a4bd80)
proxmox-kernel-7.0: 7.0.2-6
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
....

Network location: Italy, routed via it.eu.cdn.proxmox.com → de2.cdn.proxmox.com.
 
Last edited:
fabian said:
download.proxmox.com is not available via TLS.
Click to expand...
And AFAIK never was:

S

Thread 'Repository update error'

Hi. Proxmox 9 cannot be updated from the pve-no-subscription repository by URI: https://download.proxmox.com/debian/pve because there is a certificate error. The certificate was issued for enterprise.proxmox.com
Code: 
Hit:1 http://security.debian.org/debian-security trixie-security InRelease
Hit:2 http://deb.debian.org/debian trixie InRelease                                                                             
Hit:3 http://deb.debian.org/debian trixie-updates InRelease                                     
Hit:4 http://download.proxmox.com/debian/ceph-squid trixie InRelease...
S

[SOLVED] Thread 'Cannot update fresh pve from pve-no-subscription repo'

Problem

Cannot get apt-update for pve-no-subscription

Reproduce
- Follow steps by https://proxmox.com/en/products/proxmox-virtual-environment/get-started
- Set repo according [Host System Administration](https://pve.proxmox.com/pve-docs/chapter-sysadmin.html)

Errors
Bash: 
root@pve:~# apt-get update

Ign:4 https://download.proxmox.com/debian/pve bookworm InRelease

Hit:2 https://security.debian.org/debian-security bookworm-security InRelease

Hit:1 https://deb.debian.org/debian bookworm InRelease

Hit:3 https://deb.debian.org/debian...
 
some CDN nodes are available over TLS for technical reasons, and they might present different contents over TLS (de2 is such a node ;)) - but that seems unrelated to OP's issue of not being able to access them without TLS.
 
  • Like
Reactions: leesteken
Thanks for the quick reply — here's the requested info.

ASN: AS30722 (Fastweb SpA, Italy)

curl -v http://download.proxmox.com (root):

* Connected to download.proxmox.com (212.224.123.70) port 80
> GET / HTTP/1.1
> Host: download.proxmox.com

< HTTP/1.1 200 OK
< Server: nginx
<html>
<head><title>Index of /</title></head>
...

This succeeded, and fetching the full InRelease path also succeeded (valid signed file, PGP signature present).

However, running apt update repeatedly right after (5x in a row, a few seconds apart) consistently resolves to a different IP and consistently fails there:
Err:1 http://download.proxmox.com/debian/pve trixie InRelease
Connection failed [IP: 45.84.67.184 80]
All 5/5 attempts failed identically against 45.84.67.184 on port 80.

So it looks like it's not one specific broken node (de2), but some nodes in the CDN pool refuse HTTP connections on port 80 while others work fine — which node you land on depends on DNS resolution at that moment. Over the course of troubleshooting today I've seen these IPs behave inconsistently for the same hostname: 185.219.221.167, 51.91.38.34, 45.84.67.184 (all failing/mismatched), vs 212.224.123.70 (working).

Happy to run any further tests if useful.
 
lcerabolini said:
ASN: AS30722 (Fastweb SpA, Italy)

curl -v http://download.proxmox.com (root):
Click to expand...
Thanks for the information.

from a look through the logs and rate-limit-lists of 45.84.67.184 - I did not see any IP that looks like it's belonging to AS30722

a) could you share (the first part of) your public ip-address - this makes searching for potential issues easier (I might have missed a prefix that belongs to AS30722)
b) a traceroute to the node that does not work
c) does `apt-get update` work if you point download.proxmox.com to `212.224.123.70` via /etc/hosts?

The nodes themselves (neither the one that works for you, not the ones that don't work for you) don't seem to have a general issue (based on their logs, the lack of other reporters)) - on port 80.

Finally - please check if you have any kind of firewall between your node and the CDN/internet - it could be that the firewall resolved download.proxmox.com once itself, and now only allows connections to that single ip...
 
in particular, if plain curl works but APT doesn't, check whether there is a proxy setup in APT's configuration..
 
  • Like
Reactions: Stoiko Ivanov
Here's the requested info:


a) Public IP (partial): 188.152.219.x/24


b) Traceroute to 45.84.67.184:



traceroute to 45.84.67.184 (45.84.67.184), 30 hops max, 60 byte packets
1 10.0.0.2 0.229 ms
2 188.152.219.217 1.823 ms
3 192.168.51.6 3.532 ms
4 * * *
5 * * *
6 217.29.67.27 4.094 ms
7 217.29.67.221 2.977 ms
8 94.103.180.93 12.478 ms
9 94.103.180.6 11.898 ms
10 45.153.82.21 12.136 ms
11 45.84.66.3 13.688 ms
12-30 * * * (no further responses)

Reaches 45.84.66.3 (same /24 as the target) with normal latency (~13ms), then no more ICMP replies — consistent either with the destination/firewall dropping ICMP past that point, or with something going wrong right at that edge.


c) /etc/hosts pinned to 212.224.123.70 (the IP that worked fine for me via curl a couple hours ago):



apt update
...
Err:1 http://download.proxmox.com/debian/pve trixie InRelease
Connection failed [IP: 212.224.123.70 80]

This is the interesting part: the same IP that gave me a clean 200 OK earlier today now refuses the connection entirely. So it doesn't look like a stable split between "good" and "bad" nodes — availability on port 80 seems to be flapping over time on the same node, which might explain why it's hard to spot from server-side logs/rate-limit lists.


No proxy in APT (confirmed via env | grep -i proxy and /etc/apt/apt.conf.d/, both clean — only the default 76pveproxy disabling proxy explicitly).
 
Thanks for the further tests - the only logline on 212.224.123.70 matching 188.152.219 is the curl you did at 12:19 (CEST)

my current guess would be some kind of firewall/mitm box (I remember some of those which had an issue with APT's user agent (matching HTTP/1.3)) blocking connections to our cdn nodes - if you don't have any such thing deployed - maybe ask your ISP

lcerabolini said:
then no more ICMP replies — consistent either with the destination/firewall dropping ICMP past that point, or with something going wrong right at that edge.
Click to expand...
yes - ICMP is not allowed in general on our CDN nodes
 
You must log in or register to reply here.
Top Bottom
Back