Certificat SSL Proxmox cassé : restaurer rapidement l’accès à l’interface Web en toute sécurité

novembre 6, 2025 • février 3, 2026 • Lecture : 25 min • Views: 6

Cet article vous a aidé ?

L’interface Web de Proxmox est hors service, votre navigateur hurle au sujet du TLS, et quelqu’un demande déjà si vous « pouvez juste désactiver HTTPS ».
Pendant ce temps, vous avez des machines virtuelles à surveiller et un cluster qui n’appréciera pas l’improvisation.

C’est une de ces pannes qui semble plus grave qu’elle ne l’est — jusqu’à ce que vous l’aggraviez avec un « correctif rapide » précipité.
L’objectif est simple : retrouver un accès sécurisé et authentifié au port 8006 rapidement, sans transformer votre hyperviseur en exercice de confiance.

Feuille de route de diagnostic rapide (vérifiez ceci en premier)

Quand Proxmox « casse SSL », vous êtes généralement face à l’un des quatre cas :
(1) l’horloge est incorrecte, (2) le proxy ne peut pas charger clés/certificats, (3) le service n’écoute pas, ou (4) quelque chose en amont intercepte.
La feuille de route ci-dessous est optimisée pour la rapidité : trouvez le goulot d’étranglement en quelques minutes, pas lors d’une longue session SSH émotionnelle.

Première étape : l’interface est-elle vraiment hors service ou simplement non fiable ?

Si le port 8006 écoute et que vous pouvez récupérer un certificat, votre problème est probablement de type confiance/expiration/chaîne.
Si le port 8006 n’écoute pas ou si la poignée de main TLS échoue immédiatement, votre problème est probablement démarrage de pveproxy ou analyse du cert/key.

Deuxième étape : vérifiez l’heure, puis les services

Une heure incorrecte rend des certificats valides « pas encore valides » ou « expirés » instantanément. Corrigez l’heure avant de toucher aux fichiers de certificat.
pveproxy arrêté signifie que l’interface est indisponible, quelle que soit la validité du certificat.

Troisième étape : vérifiez l’intégrité du certificat et de la chaîne

Incompatibilité clé (la clé privée ne correspond pas au certificat) empêche pveproxy de démarrer.
PEM corrompu (mauvais format, en-têtes manquants, caractères CRLF indésirables) empêche pveproxy de fonctionner.
Chaîne incomplète casse les navigateurs et les reverse proxies mais peut laisser pveproxy fonctionner.

Quatrième étape : spécifique aux clusters : l’erreur est-elle sur un nœud ou sur tous ?

Dans un cluster, la gestion des certificats peut différer par nœud. N’assumez pas qu’une correction se propage à moins que vous l’ayez conçue ainsi.
Si vous utilisez un VIP/équilibreur de charge partagé, un seul nœud « mauvais » peut empoisonner l’expérience de façon imprévisible.

Une règle : n’activez pas TLS pour « entrer rapidement ». C’est comme ça que le « temporaire » devient « incident à déclarer ».

Qu’est-ce qui a réellement cassé quand « le certificat SSL a cassé »

Proxmox VE sert l’interface Web via pveproxy sur TCP/8006. Ce proxy attend un certificat et une clé privée qu’il peut lire et parser.
S’il ne peut pas, il ne démarrera souvent pas. S’il démarre mais que le certificat est expiré, non approuvé ou sans intermédiaires, les navigateurs et clients API peuvent refuser la connexion.

Causes racines fréquentes cachées derrière le même symptôme

Certificat expiré : vous obtenez un avertissement navigateur ; l’automatisation (Terraform, scripts) peut échouer complètement.
Dérive d’horloge ou mauvais fuseau : un certificat valide apparaît comme expiré ou pas encore valide.
Incompatibilité clé/certificat : pveproxy refuse de démarrer ; le port 8006 peut être fermé.
Permissions/propriété : la clé privée illisible par le service (ou trop permissive selon le durcissement) pose problème.
Mauvais copier/coller : format PEM ruiné ; lignes BEGIN/END manquantes ; retours Windows.
Mauvais certificat installé : certificat pour le nom du load balancer alors que vous accédez à l’IP du nœud (ou inversement).
Proxy en amont : le reverse proxy présente son propre certificat ; vous avez réparé Proxmox mais les utilisateurs voient toujours l’ancien certificat.
Confusion SNI : le navigateur demande un nom ; le proxy sert un autre certificat.

Blague n°1 : Les certificats, c’est comme le lait : l’étiquette a l’air correcte jusqu’à ce que vous l’ouvriez et regrettiez vos choix.

Faits intéressants et contexte historique

Un peu de contexte aide quand vous décidez de « régénérer » ou de « réparer chirurgicalement » :

TLS s’appelait autrefois SSL ; tout le monde dit encore « certificat SSL » parce que « certificat TLS cassé » sonne comme un panic kernel.
Les navigateurs ont durci les règles sur la validité des certificats, la correspondance des noms et la complétude de la chaîne ; un certificat qui « marche sur mon laptop » peut cesser de fonctionner après une mise à jour.
Let’s Encrypt a popularisé les certificats à courte durée (typiquement 90 jours), échangeant de longues expirations contre de l’automatisation. Si l’automatisation casse, l’expiration arrive vite.
Les clients modernes rejettent les signatures SHA-1 et les clés RSA faibles ; des habitudes de PKI interne anciennes peuvent devenir des pannes quand la politique crypto évolue.
L’heure est une dépendance pour la confiance : la validation X.509, c’est essentiellement « cryptographie + horloges ». Les échecs NTP ont causé de vraies pannes dans l’industrie.
Les certificats intermédiaires comptent : de nombreux émetteurs reposent sur des intermédiaires ; si vous installez seulement le certificat feuille, ça « marche sur certaines machines, échoue sur d’autres ».
SNI (Server Name Indication) permet plusieurs certificats sur une même IP:port. Sans ça, on brûlerait encore des adresses IP comme en 2005.
Les certificats auto-signés par défaut sont courants dans les UI d’infrastructure parce que secure-by-default vaut mieux que « livrer sans TLS ». Le compromis est la gestion de la confiance.

Tâches pratiques de récupération avec commandes (et comment décider)

Ci-dessous se trouvent des tâches réelles que vous pouvez exécuter en SSH sur un nœud Proxmox. Chacune inclut : la commande, la sortie importante, et la décision suivante.
Le thème : mesurer d’abord, puis modifier le minimum nécessaire.

Tâche 1 : Confirmez que le nœud est joignable et que vous ne poursuivez pas un fantôme réseau

cr0x@server:~$ ping -c 2 proxmox01
PING proxmox01 (10.20.0.11) 56(84) bytes of data.
64 bytes from 10.20.0.11: icmp_seq=1 ttl=64 time=0.310 ms
64 bytes from 10.20.0.11: icmp_seq=2 ttl=64 time=0.295 ms

--- proxmox01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1025ms

Décision : Si perte de paquets ou pas de route, corrigez le réseau/VLAN/routage avant de toucher TLS. Les certificats ne réparent pas l’ARP.

Tâche 2 : Le port 8006 écoute-t-il ?

cr0x@server:~$ sudo ss -lntp | grep 8006
LISTEN 0      4096               0.0.0.0:8006       0.0.0.0:*    users:(("pveproxy",pid=1324,fd=6))

Décision : Si vous voyez pveproxy à l’écoute, l’interface est up et votre problème est probablement de confiance/expiration/chaîne.
Si rien n’écoute, allez directement aux logs du service et à l’analyse du certificat.

Tâche 3 : Vérifiez rapidement l’état du service

cr0x@server:~$ sudo systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2025-12-24 09:41:12 UTC; 3min ago
    Process: 2041 ExecStart=/usr/bin/pveproxy (code=exited, status=1/FAILURE)

Décision : S’il est en échec, ne devinez pas. Récupérez ensuite le journal ; il indique souvent le fichier exact qu’il ne peut pas lire ou parser.

Tâche 4 : Lisez les logs pour la vraie raison (généralement cert/key)

cr0x@server:~$ sudo journalctl -u pveproxy -n 60 --no-pager
Dec 24 09:41:12 proxmox01 pveproxy[2041]: cannot load certificate '/etc/pve/local/pve-ssl.pem': PEM routines:get_name:no start line
Dec 24 09:41:12 proxmox01 systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 09:41:12 proxmox01 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Décision : « no start line » signifie que le format PEM est corrompu (mauvais copier/coller, mauvais fichier ou données binaires). Corrigez le contenu du fichier, pas le service.

Tâche 5 : Vérifiez l’heure système et le statut NTP avant de toucher aux certificats

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-24 09:44:31 UTC
           Universal time: Wed 2025-12-24 09:44:31 UTC
                 RTC time: Wed 2025-12-24 09:44:30
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Décision : Si la synchronisation de l’horloge est no ou si l’heure est largement erronée, corrigez le NTP d’abord. Sinon, vous pourriez « réparer » un certificat qui n’était pas cassé.

Tâche 6 : Validez les dates du certificat (expiration et not-before)

cr0x@server:~$ sudo openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -dates -subject
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT
subject=CN = proxmox01.example.internal

Décision : Si notAfter est dans le passé, renouvelez/remplacez. Si notBefore est dans le futur, votre heure est erronée ou vous avez installé le mauvais certificat.

Tâche 7 : Confirmez que le certificat correspond à la clé privée (la non-correspondance tue pveproxy)

cr0x@server:~$ sudo openssl x509 -noout -modulus -in /etc/pve/local/pve-ssl.pem | openssl md5
MD5(stdin)= 8b2f6a8d7efbd33a1c3c7f2e4e2a1b51
cr0x@server:~$ sudo openssl rsa -noout -modulus -in /etc/pve/local/pve-ssl.key | openssl md5
MD5(stdin)= 8b2f6a8d7efbd33a1c3c7f2e4e2a1b51

Décision : Les hachages doivent correspondre. S’ils ne correspondent pas, vous avez installé un certificat qui n’appartient pas à cette clé. Réinstallez la paire correcte ou régénérez correctement.

Tâche 8 : Vérifiez permissions et propriété des fichiers (classique « ça marche jusqu’au reboot »)

cr0x@server:~$ sudo ls -l /etc/pve/local/pve-ssl.*
-rw-r----- 1 root www-data  1826 Dec 24 09:39 /etc/pve/local/pve-ssl.pem
-rw------- 1 root www-data  1704 Dec 24 09:39 /etc/pve/local/pve-ssl.key

Décision : Si la clé est lisible par tous, vous avez un problème de sécurité. Si elle est illisible par le contexte du service, vous avez un problème de disponibilité.
Proxmox attend typiquement des permissions sensées root-owned ; ne faites pas un « chmod 777 » pour entrer en production.

Tâche 9 : Vérifiez quel certificat le nœud présente réellement sur le port 8006

cr0x@server:~$ openssl s_client -connect 10.20.0.11:8006 -servername proxmox01.example.internal -showcerts

CONNECTED(00000003)
depth=0 CN = proxmox01.example.internal
verify error:num=20:unable to get local issuer certificate
verify return:1
---
Certificate chain
 0 s:CN = proxmox01.example.internal
   i:CN = Example Intermediate CA 01
---
SSL handshake has read 1657 bytes and written 407 bytes

Décision : Si vous voyez « unable to get local issuer certificate », vous avez probablement une chaîne incomplète.
Cela peut être acceptable pour des systèmes internes avec magasins de confiance d’entreprise, mais les navigateurs et l’automatisation peuvent quand même le rejeter.

Tâche 10 : Validez le contenu du fichier de chaîne de certificats (feuille + intermédiaires)

cr0x@server:~$ sudo awk 'BEGIN{c=0} /BEGIN CERTIFICATE/{c++} END{print c}' /etc/pve/local/pve-ssl.pem
1

Décision : Si vous vouliez installer une chaîne complète, mais que le fichier contient seulement 1 certificat, il vous manque des intermédiaires.
Corrigez en concaténant la feuille + l(es) intermédiaire(s) dans le bon ordre (feuille en premier).

Tâche 11 : Vérification rapide que vous n’avez pas cassé la correspondance DNS/nom

cr0x@server:~$ sudo openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -ext subjectAltName
X509v3 Subject Alternative Name:
    DNS:proxmox01.example.internal, DNS:pve.example.internal, IP Address:10.20.0.11

Décision : Si vous accédez via IP mais que le certificat n’a que des noms DNS (ou inversement), les utilisateurs auront une non-correspondance de nom.
Changez la façon dont les gens y accèdent (préféré) ou réémettez le certificat avec les SAN appropriés.

Tâche 12 : Redémarrez le bon service et vérifiez qu’il reste actif

cr0x@server:~$ sudo systemctl restart pveproxy
cr0x@server:~$ sudo systemctl is-active pveproxy
active

Décision : S’il retombe en échec, revérifiez immédiatement le journal ; les redémarrages répétés ne sont pas une stratégie, ce sont des symptômes.

Tâche 13 : Confirmez que l’API répond localement (évite le drame de la confiance du navigateur)

cr0x@server:~$ curl -k https://127.0.0.1:8006/api2/json/version
{"data":{"release":"8.2","repoid":"b2c3d4e5","version":"8.2.2"}}

Décision : Si curl local fonctionne, votre problème peut être la confiance du client, le reverse proxy ou une non-correspondance de nom — pas Proxmox lui-même.

Tâche 14 : Si vous utilisez un reverse proxy, prouvez quel certificat les utilisateurs voient

cr0x@server:~$ openssl s_client -connect pve.example.internal:443 -servername pve.example.internal 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = pve.example.internal
issuer=CN = Example Public CA R3
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT

Décision : Si le reverse proxy présente un certificat différent du nœud, corrigez la configuration du proxy/le magasin de certificats. N’essayez pas de « réparer Proxmox » pour un problème de proxy.

Tâche 15 : Vérifiez l’intégrité du système de fichiers du cluster (car les certificats peuvent être dans /etc/pve)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             labcluster
Config Version:   17
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Wed Dec 24 09:49:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Décision : Si le cluster n’est pas quoratique ou si /etc/pve est instable, vous pouvez observer des comportements étranges de type « fichier manquant ».
Corrigez le quorum/les communications du cluster avant d’effectuer d’importantes modifications de configuration.

Tâche 16 : Confirmez que vous éditez les bons fichiers (Proxmox a des opinions)

cr0x@server:~$ sudo grep -R "pve-ssl" -n /etc/pve/local | head
/etc/pve/local/pveproxy-ssl.pem:1:-----BEGIN CERTIFICATE-----

Décision : Les noms de fichiers varient selon la version et la configuration ; n’assumez pas. Si vous n’êtes pas sûr, suivez les logs de pveproxy — ils indiquent quel chemin est utilisé.

Voies de restauration sûres : choisissez votre stratégie de réparation

Une fois que vous avez identifié la catégorie — heure, service, contenu du certificat, ou proxy frontal — choisissez une stratégie adaptée.
Il n’y a pas de prix pour la solution la plus créative. Il y a un prix pour la solution qui tient après le prochain redémarrage.

Voie A : L’interface est up, le certificat est expiré/non approuvé → renouvelez ou remplacez, gardez le service en fonctionnement

Si ss montre pveproxy à l’écoute et que curl -k local renvoie du JSON de version, vous n’êtes pas en panne sévère.
Vous êtes en panne de confiance. C’est mieux.

Si vous avez déjà l’automatisation Let’s Encrypt : réparez l’automatisation, puis renouvelez.
Si vous utilisez une PKI interne : réémettez avec les SAN corrects, incluez la chaîne et déployez de façon cohérente.
Si vous utilisiez l’auto-signé par défaut : régénérez en toute sécurité et distribuez la confiance là où c’est nécessaire (navigateurs des admins, nœuds d’automatisation).

Voie B : pveproxy ne démarre pas → réparez d’abord parsing/permissions, puis envisagez la régénération

La récupération la plus rapide et sûre est généralement : restaurer une paire cert/key connue bonne depuis une sauvegarde ou régénérer le certificat proxy Proxmox avec les outils standards.
Évitez d’éditer à la main des fichiers PEM sous stress sans validation.

Si vous devez « entrer maintenant » pendant que vous réparez la confiance, la moins mauvaise approche est SSH + vérifications API locales.
N’élargissez pas l’exposition réseau du système parce que votre navigateur est impatient.

Voie C : Reverse proxy en amont → réparez d’abord le proxy ou contournez-le temporairement

Si les utilisateurs frappent pve.example.internal et que cela pointe vers Nginx/HAProxy/Traefik, le certificat que voit le navigateur peut ne pas être du tout celui de Proxmox.
Vous pouvez passer la journée à renouveler sur le nœud et échouer quand même la poignée de main à la périphérie.

En incident, je préfère un contournement contrôlé : accéder directement au nœud via le réseau de gestion, vérifier sa santé, puis réparer l’edge.
Cela empêche une mauvaise configuration du proxy de se faire passer pour une panne Proxmox.

Voie D : L’heure est incorrecte → corrigez l’heure, puis retestez avant de modifier quoi que ce soit

Les certificats sont liés au temps. Si l’heure est décalée, tout semble cassé :
validation des certificats, validité des tokens, parfois même interactions de cluster. Corriger l’heure est presque insultant d’efficacité.

Blague n°2 : NTP, c’est comme le dentifrice — on ne le remarque que quand il manque, et la situation devient vite salissante.

Trois mini-récits d’entreprise (comment ça tourne mal en vrai)

Mini-récit 1 : La panne causée par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un petit cluster Proxmox pour des services internes. Ils utilisaient le certificat Proxmox par défaut sur chaque nœud et avaient formé les admins à accepter l’avertissement du navigateur.
Ce n’était pas élégant, mais c’était stable — jusqu’à ce qu’une nouvelle équipe sécurité déploie une politique de navigateur d’entreprise.

Le lendemain matin, personne ne pouvait atteindre l’interface Web. L’hypothèse était : « Proxmox est en panne. » Il n’en était rien. Le port 8006 était up, les VM tournaient, le stockage était OK.
La politique du navigateur refusait simplement les certificats auto-signés sans mécanisme d’exception.

La première action de l’équipe fut de redémarrer les services et de « régénérer les certificats » sur tous les nœuds. Cela créa un deuxième problème : chaque nœud avait maintenant un certificat auto-signé différent de la veille,
donc même les admins qui avaient précédemment accepté les avertissements ne pouvaient plus passer les nouvelles alertes de non-correspondance dans leurs outils d’automatisation.

La solution fut ennuyeuse mais efficace : ils déployèrent un certificat signé par une CA interne avec des SAN corrects, puis poussèrent la CA interne vers les postes gérés.
Après cela, l’interface fonctionna « magiquement » à nouveau, et l’incident fut reclassé comme impact d’un changement de politique, pas une défaillance Proxmox.

La leçon : « Le navigateur dit non » n’est pas équivalent à « le service est en panne ». Considérez-le comme une défaillance de la chaîne de confiance jusqu’à preuve du contraire.

Mini-récit 2 : L’optimisation qui a échoué

Une autre organisation voulait « une URL propre » pour Proxmox : un nom unique derrière un reverse proxy avec un certificat public approuvé.
Ils ont fronté le cluster avec un proxy qui terminait le TLS, puis redirigeait vers chaque nœud sur 8006. Ça fonctionnait bien en démo.

Puis quelqu’un a optimisé : il a activé des checks de santé agressifs et un « routage intelligent » basé sur les réponses HTTP.
Proxmox, étant une UI de gestion avec authentification, n’appréciait pas d’être sondé incorrectement. Le proxy commença à marquer des nœuds sains comme malsains lors de brefs changements de redirection de connexion.

Lors d’un renouvellement de certificat, ils ont mis à jour le certificat du proxy mais oublié d’ajuster le comportement SNI/host en upstream.
Certains clients virent le nouveau certificat ; d’autres virent un ancien mis en cache ou servi via une route SNI différente. L’incident avait la délicieuse propriété d’être intermittent.

Ils simplifièrent finalement : séparer un check de santé TCP stable des hypothèses HTTP, et router de façon déterministe.
L’« optimisation » avait ajouté de la fragilité et obscurci l’endroit où TLS était réellement terminé.

La leçon : les reverse proxies peuvent cacher des problèmes et en créer de nouveaux. Si vous frontrez Proxmox, soyez explicite sur l’emplacement des certificats et le sens des checks de santé.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la situation

Un environnement réglementé exploitait Proxmox avec une PKI interne et des certificats à courte durée. Leur équipe ops faisait deux choses peu glamour :
(1) garder une sauvegarde chiffrée de cert/key avec historique des changements, et (2) tester le renouvellement sur un nœud de staging chaque mois.

Un week-end, un CA intermédiaire fut tourné. Lundi matin, certaines automatisations qui parlaient à l’API Proxmox commencèrent à échouer avec « émetteur inconnu ».
L’interface Web était accessible pour les humains ayant le magasin de confiance mis à jour, mais les nœuds d’automatisation étaient en retard sur les MAJ de la CA.

Parce qu’ils avaient un historique propre de ce qui avait changé, ils confirmèrent immédiatement que les nœuds Proxmox servaient la nouvelle chaîne correctement.
La correction ne se fit pas sur Proxmox — il fallut pousser l’intermédiaire vers les magasins de confiance des nœuds d’automatisation.

Pas de réémissions paniquées. Pas de redémarrages aléatoires. Pas de suppositions.
L’incident fut clos rapidement parce que l’équipe pouvait prouver où la confiance était rompue et déployer un changement précis.

La leçon : la discipline ennuyeuse bat les actions héroïques. Quand les certificats cassent, votre capacité à comparer « avant/après » est précieuse.

Erreurs fréquentes : symptôme → cause racine → fix

C’est la section où votre futur-vous remercie discrètement votre passé-vous pour son honnêteté.
Ce sont des modes de défaillance communs et spécifiques que j’ai vus en production.

1) Le navigateur affiche « Votre connexion n’est pas privée » et refuse d’aller plus loin

Symptôme : L’interface est bloquée ; pas d’option « continuer quand même ».
Cause racine : La politique gérée du navigateur interdit les certificats auto-signés ou CA inconnues ; ou le certificat est réellement expiré.
Fix : Utilisez un certificat approuvé par une CA (PKI interne ou CA publique) avec des SAN corrects ; ou renouvelez le certificat expiré. Vérifiez avec openssl x509 -dates.

2) Le port 8006 est fermé ; `pveproxy` plante en continu

Symptôme : ss ne montre rien sur 8006 ; systemd indique échec.
Cause racine : Fichier PEM corrompu, mauvais format, ou incompatibilité clé/certificat.
Fix : Lisez journalctl -u pveproxy. Validez les en-têtes PEM, faites correspondre les modules de hachage, restaurez des fichiers connus bons, puis redémarrez.

3) « NET::ERR_CERT_COMMON_NAME_INVALID » ou avertissements de non-correspondance de nom

Symptôme : Le certificat est valide mais pour un autre hôte ; l’erreur mentionne CN/SAN mismatch.
Cause racine : Accès par IP ou par un DNS différent de ceux présents dans les SANs ; souvent après renommage d’un nœud ou introduction d’un VIP.
Fix : Standardisez l’accès (préféré : un nom DNS par nœud ou un nom VIP), réémettez le certificat avec des SAN couvrant les usages réels.

4) Ça marche depuis certaines machines, échoue depuis d’autres

Symptôme : Un admin peut se connecter ; un autre obtient des erreurs d’émetteur/chaîne.
Cause racine : Certificat intermédiaire manquant dans la chaîne servie ; ou magasins de confiance différents entre clients.
Fix : Servez la chaîne complète (feuille + intermédiaires) et assurez-vous que les clients font confiance au root/intermédiaire. Vérifiez avec openssl s_client -showcerts.

5) Le certificat « expiré » juste après renouvellement

Symptôme : Vous avez renouvelé, redémarré, et l’ancien affichage d’expiration persiste.
Cause racine : Vous avez mis à jour le mauvais chemin de certificat ; un reverse proxy sert l’ancien certificat ; cache navigateur ; ou plusieurs nœuds derrière un VIP et un seul a été mis à jour.
Fix : Confirmez le certificat présenté avec openssl s_client contre le nom exact que les utilisateurs contactent. Puis mettez à jour le point de terminaison réel.

6) Après « avoir corrigé les permissions », pveproxy démarre mais la sécurité est dégradée

Symptôme : Quelqu’un a appliqué des chmod permissifs ; la clé est lisible par trop d’utilisateurs.
Cause racine : Durcissement/assouplissement panique sans comprendre les besoins du service.
Fix : Restaurez les permissions minimales requises ; gardez la clé privée lisible uniquement par root et le compte de service si nécessaire. Documentez les modes attendus.

7) L’UI d’un nœud marche, mais la jonction/auth du cluster échoue

Symptôme : Interface Web accessible ; mais opérations inter-nœuds échouent ou montrent des erreurs d’auth.
Cause racine : Confusion entre le certificat UI pveproxy et la communication/auth du cluster ; ou casse de la synchronisation /etc/pve/quorum pendant l’édition.
Fix : Vérifiez la santé du cluster avec pvecm status, confirmez que /etc/pve est monté et cohérent, puis appliquez les changements nœud par nœud soigneusement.

Listes de contrôle / plan étape par étape

Ces plans supposent que vous avez un accès SSH (ou console) à l’hôte. Si ce n’est pas le cas, rétablissez-le d’abord.
L’accès hors-bande n’est pas un luxe ; c’est la « ceinture de sécurité » des opérations d’hyperviseur.

Checklist 1 : Restauration rapide de l’interface Web quand pveproxy est down (nœud unique)

Confirmez l’heure : lancez timedatectl. Si elle est fausse, corrigez NTP/heure et retestez. Ne touchez pas aux certificats encore.
Vérifiez si 8006 écoute : ss -lntp | grep 8006. Si rien, poursuivez.
Inspectez les logs pveproxy : journalctl -u pveproxy -n 60. Identifiez l’erreur exacte (parse PEM, permission, fichier manquant).
Validez le format du fichier de certificat : ouvrez le fichier référencé et assurez-vous qu’il contient des blocs PEM corrects. Comptez les blocs cert avec awk.
Vérifiez la correspondance clé/cert : contrôle du modulus md5. Si mismatch, arrêtez et réinstallez la paire correcte.
Restaurez depuis une sauvegarde connue bonne si disponible. C’est généralement le moyen le plus rapide et sûr.
Redémarrez pveproxy : systemctl restart pveproxy, puis vérifiez systemctl is-active.
Vérifiez l’API locale : curl -k https://127.0.0.1:8006/api2/json/version.
Puis vérifiez à distance : testez avec openssl s_client depuis une machine admin pour confirmer le certificat servi.

Checklist 2 : L’UI fonctionne mais les navigateurs/clients rejettent le certificat (panne de confiance)

Prouvez que le service est up : ss -lntp et curl -k local.
Inspectez les dates du certificat : openssl x509 -dates. Si expiré, renouvelez/réémettez.
Vérifiez les SAN : openssl x509 -ext subjectAltName. Si non-conforme, réémettez avec les bons noms.
Vérifiez la complétude de la chaîne : openssl s_client -showcerts. Si intermédiaires manquants, servez la chaîne complète.
Décidez du modèle de confiance :
- CA interne : distribuez la CA aux clients, puis déployez feuille+intermédiaires.
- CA publique : assurez-vous que la méthode de validation fonctionne (challenge DNS/HTTP) et que l’automatisation de renouvellement est fiable.
- Auto-signé : acceptable seulement si vous contrôlez les magasins de confiance clients ; sinon, vous planifiez une douleur future.
Vérifiez depuis au moins deux types de clients : navigateur géré + outil CLI (curl/openssl). Les comportements de confiance différents attrapent des échecs différents.

Checklist 3 : Approche cluster (évitez de réparer un nœud et casser les autres)

Vérifiez le quorum : lancez pvecm status sur un nœud sain en premier.
Choisissez un nœud « or » pour valider la procédure de certificat avant de toucher aux autres.
Documentez le chemin d’accès : accès direct au nœud vs VIP vs reverse proxy. Votre certificat doit correspondre à cette réalité.
Appliquez les changements un nœud à la fois et vérifiez :
- pveproxy est actif
- 8006 écoute
- le certificat présenté correspond aux attentes
Si derrière un load balancer : évacuez temporairement un nœud avant de changer son certificat pour éviter la roulette utilisateur.
Après tous les nœuds : validez séparément le point de terminaison VIP/proxy.

FAQ

1) Puis-je simplement désactiver HTTPS sur Proxmox pour récupérer l’interface ?

Vous pouvez, mais vous ne devriez pas. L’interface est une interface d’administration d’un hyperviseur — les identifiants et tokens de session comptent.
Si vous avez besoin d’un accès d’urgence, utilisez SSH et les vérifications API locales pendant que vous restaurez correctement TLS.

2) Pourquoi Proxmox appelle-t-il ça « SSL » alors que c’est vraiment TLS ?

C’est un héritage de nommage. L’industrie continue de dire « certificat SSL » longtemps après que TLS ait remplacé SSL en pratique. Votre navigateur parle TLS ; vos collègues disent SSL ; tout le monde continue d’utiliser l’expression.

3) Mon certificat est valide mais les navigateurs se plaignent d’erreurs d’« émetteur ». Pourquoi ?

Généralement une chaîne incomplète : vous avez installé seulement le certificat feuille, mais les clients ont besoin des intermédiaires pour construire la confiance jusqu’à une CA racine.
Confirmez avec openssl s_client -showcerts et corrigez en servant la chaîne complète.

4) Pourquoi cela s’est produit juste après un redémarrage ?

Deux causes fréquentes : dérive horaire (NTP ne s’est pas lancé correctement et l’horloge est fausse) ou permissions/chemins modifiés et pveproxy ne peut pas lire la clé au démarrage.
Vérifiez timedatectl et journalctl -u pveproxy.

5) Est-il sûr d’utiliser le certificat auto-signé par défaut de Proxmox ?

C’est sûr dans le sens où le trafic est chiffré, mais pas automatiquement approuvé.
Dans des environnements gérés, les certificats auto-signés deviennent souvent une dette opérationnelle parce que la politique et les outils les rejettent de plus en plus.

6) J’ai mis à jour les fichiers de certificat mais le navigateur affiche toujours l’ancien. Pourquoi ?

Vous ne regardez probablement pas le nœud que vous avez édité (VIP/load balancer), ou un reverse proxy termine TLS.
Prouvez ce qui est servi avec openssl s_client contre le nom d’hôte et le port exacts que les utilisateurs frappent.

7) Quel est le « correctif rapide » le plus sûr si pveproxy ne démarre pas et que je suis sous pression ?

Restaurez une paire cert/key connue bonne depuis une sauvegarde sécurisée, redémarrez pveproxy, et confirmez la réponse API locale.
Régénérer est acceptable aussi, mais restaurer réduit le risque d’introduire une non-correspondance ou une chaîne manquante sous stress.

8) Corriger le certificat de l’interface Web affecte-t-il le trafic des VM ou le stockage ?

Pas directement. Ce certificat concerne le plan de gestion (interface Web/API) via pveproxy.
Le réseau des VM et l’accès stockage continuent généralement de fonctionner même si l’interface est inaccessible — sauf si vous cassez d’autres services en cherchant la solution.

9) Comment savoir si c’est un problème Proxmox ou un problème de reverse proxy ?

Testez les deux points de terminaison. Si l’accès direct au nœud sur 8006 présente le bon certificat et fonctionne, mais que le nom public échoue, votre proxy/périphérie est en faute.

10) Quelle est la cause la plus courante que vous voyez ?

L’expiration combinée à « on croyait que l’auto-renouvellement fonctionnait », suivie de la découverte qu’un job de renouvellement dépendait d’un token DNS expiré depuis des mois.
En deuxième position : chaînes incomplètes.

Étapes suivantes pour éviter une récidive

Voici la vérité sur la fiabilité : les pannes TLS sont rarement « difficiles ». Elles sont simplement prévisibles, et la prévisibilité est vexante quand vous êtes d’astreinte.
La solution n’est pas le heroïsme ; c’est d’intégrer les certificats au même cycle de vie que tout le reste qui vous importe.

Faites ceci ensuite, tant que l’incident est encore frais

Notez le point de terminaison réel : Proxmox direct, reverse proxy, ou load balancer. Une phrase. Pas d’ambiguïté.
Standardisez les noms d’accès : choisissez des noms DNS que les gens doivent utiliser, et réémettez les certificats avec des SAN qui reflètent la réalité.
Automatisez le renouvellement avec alertes : si le renouvellement échoue, vous devez le savoir bien avant les utilisateurs. Suivez les dates d’expiration et l’état des jobs.
Conservez un paquet de rollback connu bon : sauvegarde chiffrée de cert/key/chaîne (et notes sur leur emplacement), plus une procédure de restauration testée.
Testez depuis deux perspectives client : un navigateur géré et un outil CLI. Cela capture tôt les problèmes de chaîne et de politique.

Idée paraphrasée de John Allspaw : la fiabilité vient des systèmes et des boucles de rétroaction, pas des actions individuelles héroïques. Construisez la boucle ; vos futurs week-ends s’amélioreront.