Certificado SSL de Proxmox falló: formas rápidas de restaurar el acceso Web UI de forma segura

noviembre 6, 2025 • febrero 3, 2026 • Lectura: 24 min • Views: 13

¿Te fue útil?

La interfaz Web de Proxmox está caída, tu navegador alerta sobre TLS y alguien ya pregunta si “podemos simplemente desactivar HTTPS”.
Mientras tanto, tienes máquinas virtuales que supervisar y un clúster que no apreciará ninguna improvisación.

Este es uno de esos incidentes que parece más grande de lo que es—hasta que lo alimentas con un “arreglo rápido” apresurado.
El objetivo es simple: recuperar acceso autenticado y seguro al puerto 8006 rápido, sin convertir tu hipervisor en un ejercicio de confianza.

Guía de diagnóstico rápido (verifica esto primero)

Cuando Proxmox “rompe SSL”, normalmente estás frente a uno de cuatro grupos:
(1) la hora es incorrecta, (2) el proxy no puede cargar claves/certificados, (3) el servicio no está escuchando, o (4) algo en el frente está interceptando.
La guía a continuación está ajustada para velocidad: encuentra el cuello de botella en minutos, no en una larga y emocional sesión SSH.

Primero: ¿la UI está realmente caída o solo no es de confianza?

Si el puerto 8006 está escuchando y puedes obtener un certificado, tu problema probablemente sea de confianza/expiración/cadena.
Si el puerto 8006 no está escuchando o el handshake TLS falla inmediatamente, tu problema probablemente sea arranque de pveproxy o parseo de cert/clave.

Segundo: verifica la hora, luego los servicios

Hora incorrecta hace que certificados válidos aparezcan “aún no válidos” o “expirados” al instante. Arregla la hora antes de tocar los archivos de certificado.
pveproxy caído significa que la UI está inalcanzable independientemente de la validez del certificado.

Tercero: verifica la integridad del certificado y la cadena

Desajuste de clave (la clave privada no coincide con el certificado) hace que pveproxy falle.
PEM corrupto (formato incorrecto, encabezados faltantes, fin de línea CRLF) provoca fallos en pveproxy.
Cadena incompleta rompe navegadores y proxies inversos pero puede permitir que pveproxy siga funcionando.

Cuarto: específico de clúster: ¿lo rompiste en un nodo o en todos?

En un clúster, el manejo de certificados puede diferir por nodo. No asumas que una corrección se propaga a menos que lo hayas diseñado así.
Si usas un VIP/balanceador, un nodo “malo” puede envenenar la experiencia de forma impredecible.

Una regla: no desactives TLS para “entrar rápido”. Ahí es donde lo “temporal” se vuelve “debemos abrir un informe de incidente”.

Qué falló realmente cuando “el certificado SSL falló”

Proxmox VE sirve la UI web a través de pveproxy en TCP/8006. Ese proxy espera un certificado y una clave privada que pueda leer y parsear.
Si no puede, a menudo no arranca. Si puede arrancar pero el certificado está expirado, no es de confianza o faltan intermedios, los navegadores y clientes API pueden negarse a conectarse.

Causas raíz comunes que se esconden tras el mismo síntoma

Certificado expirado: recibes una advertencia en el navegador; la automatización (Terraform, scripts) puede fallar rotundamente.
Deriva del reloj o zona horaria incorrecta: un certificado válido parece expirado o aún no válido.
Desajuste clave/certificado: pveproxy falla al iniciar; el puerto 8006 puede estar cerrado.
Permisos/propiedad: la clave privada no es legible por el servicio (o demasiado accesible, según el endurecimiento).
Copiar/pegar defectuoso: formato PEM arruinado; faltan líneas BEGIN/END; finales de línea Windows.
Certificado equivocado instalado: certificado para el hostname del balanceador, pero accedes por la IP del nodo (o viceversa).
Proxy delante: el proxy inverso presenta su propio certificado; arreglaste Proxmox pero los usuarios siguen viendo el certificado antiguo.
Confusión SNI: el navegador solicita un nombre; el proxy sirve otro certificado.

Broma #1: Los certificados son como la leche: la etiqueta se ve bien hasta que lo abres y te arrepientes de tus decisiones.

Datos interesantes y contexto histórico

Un poco de contexto ayuda cuando decides si “regenerar” o “arreglar quirúrgicamente”:

TLS solía llamarse SSL; todo el mundo sigue diciendo “certificado SSL” porque “certificado TLS roto” suena a pánico del kernel.
Los navegadores han endurecido reglas sobre validez, coincidencia de nombres y completitud de la cadena; un certificado que “funcionaba en mi portátil” puede dejar de hacerlo tras una actualización del navegador.
Let’s Encrypt popularizó certificados de corta duración (típicamente 90 días), cambiando expiraciones largas por automatización. Si la automatización falla, la expiración aparece rápido.
Clientes modernos rechazan firmas SHA-1 y claves RSA débiles; prácticas internas de PKI heredadas pueden volverse fallos cuando la política criptográfica avanza.
La hora es una dependencia para la confianza: la validación X.509 es básicamente “criptografía + relojes”. Fallos de NTP han causado incidentes reales en la industria.
Los certificados intermedios importan: muchos emisores dependen de intermedios; si instalas solo el certificado leaf, obtendrás “funciona en algunas máquinas, falla en otras”.
SNI (Server Name Indication) permite múltiples certificados en una IP:puerto. Sin él, seguiríamos quemando direcciones IP como en 2005.
Los self-signed por defecto son comunes en UIs de infraestructura porque seguridad-por-defecto es mejor que “enviar sin TLS”. El intercambio es la gestión de confianza.

Tareas prácticas de recuperación con comandos (y cómo decidir)

A continuación hay tareas reales que puedes ejecutar por SSH en un nodo Proxmox. Cada una incluye: el comando, la salida que importa y la decisión que tomas después.
El tema: mide primero, luego cambia lo mínimo necesario.

Tarea 1: Confirma que el nodo es accesible y no estás persiguiendo un fantasma de red

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

Decisión: Si hay pérdida de paquetes o no hay ruta, arregla red/VLAN/routing antes de tocar TLS. Los certificados no arreglan ARP.

Tarea 2: ¿Está escuchando el puerto 8006?

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))

Decisión: Si ves pveproxy escuchando, la UI está arriba y tu problema probablemente sea confianza/expiración/cadena.
Si no hay nada escuchando, ve directamente a los logs del servicio y al parseo del certificado.

Tarea 3: Verifica la salud del servicio rápidamente

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)

Decisión: Si está fallando, no adivines. Extrae el journal a continuación; a menudo indica el archivo exacto que no puede leer o parsear.

Tarea 4: Lee los logs para la razón real (usualmente cert/clave)

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'.

Decisión: “no start line” significa que el formato PEM está roto (copiar/pegar malo, archivo equivocado o datos binarios). Arregla el contenido del archivo, no el servicio.

Tarea 5: Verifica la hora del sistema y el estado de NTP antes de tocar certificados

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

Decisión: Si la sincronización del reloj es no o la hora está muy desviada, arregla NTP primero. Si no, podrías “arreglar” un certificado que no estaba roto.

Tarea 6: Valida las fechas del certificado (expiración y 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

Decisión: Si notAfter está en el pasado, renueva/reemplaza. Si notBefore está en el futuro, tu hora está mal o instalaste el certificado equivocado.

Tarea 7: Confirma que el certificado coincide con la clave privada (el desajuste mata 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

Decisión: Los hashes deben coincidir. Si no lo hacen, instalaste un certificado que no corresponde a esa clave. Reinstala el par correcto o regenera apropiadamente.

Tarea 8: Verifica permisos y propiedad de archivos (el clásico “funciona hasta reiniciar”)

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

Decisión: Si la clave es legible por todos, tienes un problema de seguridad. Si es ilegible por el contexto del servicio, tienes un problema de disponibilidad.
Proxmox normalmente espera permisos sensatos y propiedad root; no hagas chmod 777 para “arreglar” producción.

Tarea 9: Comprueba qué certificado está presentando el nodo realmente en 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

Decisión: Si ves “unable to get local issuer certificate”, probablemente tienes una cadena incompleta.
Eso puede ser aceptable en sistemas internos con stores de confianza empresariales, pero navegadores y automatización aún pueden rechazarlo.

Tarea 10: Valida el contenido del archivo de cadena de certificados (leaf + intermedios)

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

Decisión: Si pretendías instalar una cadena completa pero el archivo contiene solo 1 certificado, te faltan intermedios.
Arregla concatenando leaf + intermediate(s) en el orden correcto (leaf primero).

Tarea 11: Verificación rápida de que no rompiste DNS/coincidencia de nombre

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

Decisión: Si accedes por IP pero el certificado tiene solo nombres DNS (o viceversa), los usuarios verán un desajuste de nombre.
Cambia cómo la gente accede (preferido) o reemite el certificado con los SANs correctos.

Tarea 12: Reinicia el servicio correcto y verifica que permanezca activo

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

Decisión: Si vuelve a fallar, revisa inmediatamente el journal; reinicios repetidos no son una estrategia, son negación.

Tarea 13: Confirma que la API responde localmente (evita el drama de confianza del navegador)

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

Decisión: Si curl local funciona, tu problema podría ser confianza del cliente, proxy inverso o desajuste de nombre—no Proxmox en sí.

Tarea 14: Si usas un proxy inverso, demuestra qué certificado ven los usuarios

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

Decisión: Si el proxy inverso presenta un certificado distinto al del nodo, arregla la configuración del proxy/almacén de certificados. No sigas “arreglando Proxmox” para un problema del proxy.

Tarea 15: Verifica la salud del sistema de archivos del clúster (porque los certs pueden vivir en /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

Decisión: Si el clúster no tiene quórum o /etc/pve está degradado, puedes ver comportamientos extraños de “archivo faltante”.
Arregla el quórum/comunicaciones del clúster antes de hacer ediciones grandes de configuración.

Tarea 16: Confirma que editas los archivos correctos (Proxmox tiene opiniones)

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

Decisión: Los nombres de archivo varían según versión y configuración; no asumas. Si no estás seguro, sigue los logs de pveproxy—ellos te dicen qué ruta está en uso.

Rutas de restauración seguras: elige tu estrategia de reparación

Una vez identificado el tipo—hora, servicio, contenido del certificado o proxy frontal—elige una estrategia que coincida con la situación.
No hay premio para la solución más creativa. Hay premio para la solución que sobreviva al siguiente reinicio.

Ruta A: UI está arriba, certificado expirado/no confiable → renueva o reemplaza, mantén el servicio en marcha

Si ss muestra pveproxy escuchando y curl -k local devuelve JSON de versión, no estás en un outage grave.
Estás en un outage de confianza. Eso es mejor.

Si ya tienes automatización de Let’s Encrypt: repara la automatización y luego renueva.
Si usas PKI interna: reemite con SANs correctos, incluye la cadena y despliega consistentemente.
Si usaste el self-signed por defecto: regenera de forma segura y distribuye la confianza donde haga falta (navegadores de admins, nodos de automatización).

Ruta B: pveproxy no arranca → arregla parseo/permisos primero, luego considera regenerar

La recuperación segura más rápida suele ser: restaurar un par cert/clave conocido bueno desde backup o regenerar el certificado proxy de Proxmox usando las herramientas estándar.
Lo que quieres evitar es editar PEM a mano bajo estrés sin validación.

Si realmente necesitas “entrar ahora” mientras reparas la confianza, el enfoque menos malo es SSH + comprobaciones de API locales.
No debilites la exposición en red del sistema porque tu navegador está impaciente.

Ruta C: Proxy inverso en frente → arregla el proxy primero o pásalo temporalmente

Si los usuarios alcanzan pve.example.internal y eso apunta a Nginx/HAProxy/Traefik, el certificado que ve el navegador puede no ser el certificado de Proxmox en absoluto.
Puedes pasarte el día renovando en el nodo y aún así fallar el handshake en el borde.

En incidentes, prefiero un bypass controlado: accede al nodo directamente por la red de gestión, verifica que esté sano y luego repara el borde.
Esto evita que una mala configuración del proxy se disfrace de outage de Proxmox.

Ruta D: La hora está mal → arregla la hora y vuelve a probar antes de cambiar cualquier otra cosa

Los certificados están atados al tiempo. Si la hora está fuera, todo parece roto:
validación de certificados, validez de tokens, a veces incluso interacciones de clúster. Arreglar la hora es casi insultantemente efectivo.

Broma #2: NTP es como la pasta de dientes—solo se nota cuando falta, y la situación se vuelve desordenada rápido.

Tres micro-historias corporativas (cómo esto sale mal en la vida real)

Micro-historia 1: El outage causado por una suposición errónea

Una empresa mediana ejecutaba un pequeño clúster Proxmox para servicios internos. Usaban el certificado por defecto de Proxmox en cada nodo y entrenaron a los admins a aceptar la advertencia del navegador.
No era elegante, pero era estable—hasta que un nuevo equipo de seguridad desplegó una política de navegador corporativa.

A la mañana siguiente, nadie podía alcanzar la UI web. La suposición fue “Proxmox está caído.” No lo estaba. El puerto 8006 estaba arriba, las VMs corrían, el almacenamiento estaba bien.
La política del navegador simplemente rechazó los self-signed sin un mecanismo de excepción específico.

El primer movimiento del equipo fue reiniciar servicios y “regenerar certificados” en todos los nodos. Eso creó un segundo problema: cada nodo ahora tenía un self-signed distinto al de ayer,
así que incluso los administradores que antes habían aceptado las advertencias no pudieron pasar los nuevos prompts de desajuste en sus herramientas de automatización.

La solución fue aburrida: desplegaron un certificado firmado por una CA interna con SANs apropiados y luego distribuyeron la CA interna a los endpoints gestionados.
Después de eso, la UI “mágicamente” funcionó otra vez y el incidente se reclasificó como impacto de cambio de política, no como fallo de Proxmox.

La lección: “El navegador dice no” no es lo mismo que “el servicio está caído”. Trátalo como una falla en la tubería de confianza hasta que se demuestre lo contrario.

Micro-historia 2: La optimización que se volvió en contra

Otra organización quiso “una URL limpia” para Proxmox: un único hostname detrás de un proxy inverso con certificado públicamente confiable.
Pusieron el clúster detrás de un proxy que terminaba TLS y luego reenviaba a cada nodo en 8006. Funcionó bien en demos.

Luego alguien optimizó: activaron checks de salud agresivos y “enrutamiento inteligente” basado en respuestas HTTP.
Proxmox, siendo una UI de gestión con auth, no agradeció ser sondeado incorrectamente. El proxy comenzó a marcar nodos saludables como no saludables durante breves cambios de redirección de login.

Durante una posterior renovación de certificado, actualizaron el certificado del proxy pero olvidaron ajustar el SNI/host header upstream.
Algunos clientes vieron el certificado nuevo; otros vieron uno antiguo cacheado o servido según una ruta SNI diferente. El incidente tuvo la propiedad encantadora de ser intermitente.

Finalmente simplificaron: separaron un chequeo de salud a nivel TCP estable de las suposiciones HTTP, y enrutan de forma determinista.
La “optimización” añadió fragilidad y ocultó dónde se terminaba TLS realmente.

La lección: los proxy inversos pueden ocultar problemas y crear nuevos. Si pones un proxy delante de Proxmox, sé explícito sobre dónde viven los certificados y qué significan tus checks de salud.

Micro-historia 3: La práctica aburrida que salvó el día

Un entorno regulado ejecutaba Proxmox con una PKI interna y certificados de corta vida. Su equipo de operaciones hacía dos cosas poco glamorosas:
(1) mantenían en una bóveda cifrada un backup de configuración del material cert/clave con historial de cambios, y (2) probaban la renovación en un nodo de staging mensualmente.

Un fin de semana, se rotó un CA intermedio. El lunes por la mañana, parte de la automatización que hablaba con la API de Proxmox comenzó a fallar con “issuer desconocido.”
La Web UI era accesible para humanos que tenían la store de confianza actualizada, pero los nodos de automatización estaban atrasados en las actualizaciones de CA.

Como tenían un registro limpio de qué cambió, confirmaron inmediatamente que los nodos Proxmox servían la nueva cadena correctamente.
La solución no estuvo en Proxmox en absoluto—fue desplegar el intermedio nuevo a los stores de confianza de los nodos de automatización.

Sin reemisiones en pánico. Sin reinicios aleatorios. Sin adivinanzas.
El incidente se cerró rápido porque el equipo pudo probar dónde se rompió la confianza y aplicar un cambio preciso.

La lección: la disciplina aburrida vence a los heroísmos. Cuando los certificados fallan, tu capacidad de comparar “antes/después” es oro.

Errores comunes: síntoma → causa raíz → solución

Esta es la sección donde el futuro-tú agradece en silencio al pasado-tú por ser honesto.
Son modos de fallo comunes y específicos que he visto en producción.

1) El navegador dice “Tu conexión no es privada” y se niega a continuar

Síntoma: La UI carga con un bloqueo duro; no hay “proceder de todos modos”.
Causa raíz: Política de navegador gestionada que no permite self-signed o CAs desconocidas; o el certificado está realmente expirado.
Solución: Usa un certificado confiable por CA (PKI interna o CA pública) con SANs correctos; o renueva el certificado expirado. Verifica con openssl x509 -dates.

2) El puerto 8006 está cerrado; `pveproxy` sigue fallando

Síntoma: ss no muestra nada en 8006; systemd muestra fallo.
Causa raíz: Archivo PEM corrupto, formato erróneo o desajuste de clave.
Solución: Lee journalctl -u pveproxy. Valida encabezados PEM, compara hashes del módulo, restaura archivos conocidos buenos y reinicia.

3) “NET::ERR_CERT_COMMON_NAME_INVALID” o advertencias de desajuste de nombre

Síntoma: El certificado es válido pero para otro hostname; el error menciona desajuste CN/SAN.
Causa raíz: Acceso por IP o un nombre DNS diferente al que figura en los SANs; a menudo tras renombrar un nodo o introducir un VIP.
Solución: Estandariza el acceso (preferido: un nombre DNS por nodo o un nombre VIP), reemite con SANs que cubran los patrones reales de acceso.

4) Funciona desde algunas máquinas, falla desde otras

Síntoma: Un administrador puede iniciar sesión; otro obtiene errores de issuer/cadena.
Causa raíz: Falta el certificado intermedio en la cadena servida; o stores de confianza diferentes entre clientes.
Solución: Sirve la cadena completa (leaf + intermedios) y asegúrate de que los clientes confíen en el root/intermedio. Verifica la cadena con openssl s_client -showcerts.

5) El certificado “expiró” justo después de renovarlo

Síntoma: Renovaste, reiniciaste, y aún muestra la fecha de expiración antigua.
Causa raíz: Actualizaste la ruta de certificado equivocada; el proxy inverso sigue sirviendo el cert viejo; cache del navegador; o múltiples nodos detrás de un VIP y solo uno actualizado.
Solución: Confirma el certificado presentado con openssl s_client contra el hostname exacto que usan los usuarios. Luego actualiza el punto real de terminación.

6) Después de “arreglar permisos”, pveproxy arranca pero la seguridad empeoró

Síntoma: Alguien ejecutó un chmod permisivo; la clave es legible por demasiados usuarios.
Causa raíz: Endurecimiento/aflojamiento en pánico sin entender las necesidades del servicio.
Solución: Restaura permisos mínimos requeridos; mantiene la clave privada legible solo por root y la cuenta de servicio si hace falta. Documenta los modos esperados.

7) La UI del nodo funciona, pero falla la unión/autenticación del clúster

Síntoma: UI web accesible; pero operaciones entre nodos fallan o muestran errores de autenticación.
Causa raíz: Confusión entre el certificado de pveproxy para la UI y la comunicación/autenticación del clúster; o romper /etc/pve sync/quorum mientras editas.
Solución: Verifica la salud del clúster con pvecm status, confirma que /etc/pve está montado y consistente, y aplica cambios nodo por nodo cuidadosamente.

Listas de verificación / plan paso a paso

Estos planes asumen que tienes acceso SSH (o consola) al host. Si no lo tienes, arregla eso primero.
El acceso fuera de banda no es un lujo; es el “cinturón de seguridad” de las operaciones de hipervisor.

Checklist 1: Restauración rápida de la Web UI cuando pveproxy está caído (nodo único)

Confirma la hora: ejecuta timedatectl. Si está mal, arregla NTP/tiempo y vuelve a probar. No toques certificados aún.
Comprueba si 8006 escucha: ss -lntp | grep 8006. Si no hay nada, continúa.
Inspecciona logs de pveproxy: journalctl -u pveproxy -n 60. Identifica el error exacto (parseo PEM, permiso, archivo faltante).
Valida el formato del archivo de certificado: abre el archivo referenciado y asegúrate de que contiene bloques PEM correctos. Cuenta bloques con awk.
Verifica coincidencia clave/certificado: check de módulo md5. Si hay desajuste, detente e instala el par correcto.
Restaura desde backup conocido bueno si está disponible. Esto suele ser el movimiento más rápido y seguro.
Reinicia pveproxy: systemctl restart pveproxy, luego comprueba systemctl is-active.
Verifica la API local: curl -k https://127.0.0.1:8006/api2/json/version.
Luego verifica remotamente: prueba con openssl s_client desde una máquina de administración para confirmar el certificado servido.

Checklist 2: La UI funciona pero navegadores/clientes rechazan el certificado (outage de confianza)

Demuestra que el servicio está arriba: ss -lntp y curl -k local.
Inspecciona fechas del certificado: openssl x509 -dates. Si está expirado, renueva/reemite.
Revisa SANs: openssl x509 -ext subjectAltName. Si hay desajuste, reemite con nombres correctos.
Comprueba completitud de la cadena: openssl s_client -showcerts. Si faltan intermedios, sirve la cadena completa.
Decide el modelo de confianza:
- CA interna: distribuye la CA a los clientes, luego despliega leaf+intermedios.
- CA pública: asegúrate de que el método de validación funcione (DNS/HTTP challenge) y que la automatización de renovación sea fiable.
- Self-signed: aceptable solo si controlas los stores de confianza de los clientes; de lo contrario estás programando dolor futuro.
Verifica desde al menos dos tipos de cliente: navegador gestionado + herramienta CLI (curl/openssl). Diferentes comportamientos de confianza capturan fallos distintos.

Checklist 3: Enfoque para clúster (evita arreglar un nodo y romper el resto)

Verifica quórum: ejecuta pvecm status en un nodo sano primero.
Elige un nodo “gold” para validar el procedimiento de certificados antes de tocar otros.
Documenta la ruta de acceso: acceso directo al nodo vs VIP vs proxy inverso. Tu certificado debe coincidir con esa realidad.
Aplica cambios uno por uno y verifica:
- pveproxy está activo
- 8006 escucha
- el certificado presentado coincide con lo esperado
Si estás detrás de un balanceador: drena temporalmente un nodo antes de cambiar su certificado para evitar la ruleta del usuario.
Después de todos los nodos: valida el punto de terminación VIP/proxy por separado.

Preguntas frecuentes

1) ¿Puedo simplemente desactivar HTTPS en Proxmox para recuperar la UI?

Puedes, pero no deberías. La UI es una interfaz de administración de un hipervisor—las credenciales y tokens de sesión importan.
Si necesitas acceso de emergencia, usa SSH y comprobaciones de API locales mientras restauras TLS correctamente.

2) ¿Por qué Proxmox lo llama “SSL” cuando en realidad es TLS?

Nomenclatura heredada. La industria siguió diciendo “certificado SSL” mucho después de que TLS reemplazara a SSL en la práctica. Tu navegador habla TLS; tus compañeros dicen SSL; todos siguen trabajando así.

3) Mi certificado es válido pero los navegadores siguen quejándose de “issuer”. ¿Por qué?

Usualmente es una cadena incompleta: instalaste solo el certificado leaf, pero los clientes necesitan los intermedios para construir confianza hasta un root CA.
Confirma con openssl s_client -showcerts y arregla sirviendo la cadena completa.

4) ¿Por qué pasó justo después de un reinicio?

Dos causas frecuentes: deriva del tiempo (NTP no se levantó bien y el reloj está mal) o permisos/rutas cambiaron y pveproxy no puede leer la clave al iniciar.
Revisa timedatectl y journalctl -u pveproxy.

5) ¿Es seguro usar el certificado self-signed por defecto de Proxmox?

Es seguro en el sentido de que el tráfico está cifrado, pero no es confiable automáticamente.
En entornos gestionados, los self-signed suelen convertirse en deuda operativa porque las políticas y herramientas cada vez más los rechazan.

6) Actualicé los archivos de certificado pero el navegador sigue mostrando el antiguo. ¿Por qué?

Probablemente no estás mirando al nodo que editaste (VIP/balanceador), o un proxy inverso está terminando TLS.
Demuestra qué se sirve con openssl s_client contra el hostname y puerto exactos que usan los usuarios.

7) ¿Cuál es el “fast fix” más seguro si pveproxy no arranca y estoy bajo presión?

Restaura un par cert/clave conocido y seguro desde un backup cifrado, reinicia pveproxy y confirma la respuesta de la API local.
Regenerar también está bien, pero restaurar reduce la probabilidad de introducir un desajuste o cadena faltante bajo estrés.

8) ¿Arreglar el certificado de la Web UI afecta el tráfico de las VMs o el almacenamiento?

No directamente. Este certificado es para el plano de gestión (Web UI/API) vía pveproxy.
La red de las VMs y el acceso a almacenamiento suelen seguir funcionando incluso cuando la UI es inaccesible—a menos que rompas otros servicios mientras solucionas.

9) ¿Cómo sé si esto es un problema de Proxmox o del proxy inverso?

Prueba ambos endpoints. Si el acceso directo al nodo en 8006 presenta el certificado correcto y funciona, pero el hostname público falla, el responsable es tu proxy/terminación de borde.

10) ¿Cuál es la causa más común que ves?

Expiración combinada con “pensábamos que la auto-renovación funcionaba”, seguida de alguien descubriendo que el job de renovación dependía de un token DNS que expiró hace meses.
En segundo lugar: cadenas incompletas.

Próximos pasos para evitar que vuelva a ocurrir

La verdad sobre fiabilidad: los outages TLS rara vez son “difíciles”. Son predecibles, y la predictibilidad es insultante cuando estás de guardia.
La solución no son los heroísmos; es poner los certificados en las mismas reglas de ciclo de vida que todo lo demás que te importa.

Haz esto a continuación, mientras el incidente aún está fresco

Escribe el punto real de terminación: Proxmox directo, proxy inverso o balanceador. Una frase. Sin ambigüedad.
Estandariza los nombres de acceso: elige nombres DNS que la gente debe usar y reemite certificados con SANs que coincidan con la realidad.
Automatiza la renovación con alertas: si la renovación falla, debes saberlo mucho antes que los usuarios. Rastrear fechas de expiración y estado de jobs.
Mantén un paquete de rollback conocido bueno: backup cifrado de cert/clave/cadena (y notas de dónde viven), más un procedimiento de restauración probado.
Prueba desde dos perspectivas de cliente: un navegador gestionado y una herramienta CLI. Esto detecta problemas de cadena y de política temprano.

Idea parafraseada de John Allspaw: la fiabilidad viene de sistemas y bucles de retroalimentación, no de heroísmos individuales. Construye el bucle; tus futuros fines de semana mejorarán.