Пошкоджено SSL-сертифікат Proxmox: швидкі способи безпечно відновити доступ до Web UI

November 6, 2025 • February 3, 2026 • Читання: 5 хв • Views: 11

Було корисно?

Web UI Proxmox недоступний, браузер кричить про TLS, і хтось уже питає, чи «можна просто вимкнути HTTPS».
Тим часом у вас є віртуальні машини, які треба підтримувати, і кластер, що ніяк не оцінить імпровізацій.

Це один із тих інцидентів, що здаються серйознішими, ніж насправді — поки ви не погіршите ситуацію поспішним «швидким» рішенням.
Мета проста: швидко повернути безпечний, автентифікований доступ до порту 8006, не перетворюючи гіпервізор на вправу в довірі.

Швидкий план діагностики (перевірте це в першу чергу)

Коли в Proxmox «зламався SSL», зазвичай це одна з чотирьох категорій:
(1) час неправильний, (2) проксі не може завантажити ключі/сертифікати, (3) сервіс не слухає порт, або (4) щось зверху перехоплює з’єднання.
Нижченаведений план оптимізований на швидкість: знайдіть вузьке місце за кілька хвилин, а не в довгій емоційній SSH-сесії.

По-перше: UI дійсно не працює, чи просто невірять сертифікату?

Якщо порт 8006 слухає і ви можете отримати сертифікат, ймовірно проблема в довірі/терміні дії/ланцюгу.
Якщо порт 8006 не слухає або TLS-handshake падає миттєво, ймовірно проблема в запуску pveproxy або парсингу сертифіката/ключа.

По-друге: перевірте час, потім сервіси

Неправильний час миттєво робить дійсні сертифікати «ще не дійсними» або «простроченими». Виправте час перед тим, як торкатися файлів сертифікатів.
pveproxy не працює — UI недоступний незалежно від валідності сертифіката.

По-третє: перевірте цілісність сертифіката та ланцюг

Несумісність ключа (приватний ключ не відповідає сертифікату) вбиває pveproxy.
Пошкоджений PEM (неправильний формат, відсутні заголовки, CRLF-сміття) спричиняє помилки pveproxy.
Неповний ланцюг ламає браузери та зворотні проксі, але pveproxy може все ще запускатися.

По-четверте: специфічно для кластера — зламали на одному вузлі чи на всіх?

У кластері обробка сертифікатів може відрізнятися на кожному вузлі. Не припускайте, що виправлення на одному вузлі автоматично поширюється, якщо ви цього не налаштували.
Якщо ви використовуєте спільний VIP/балансувальник навантаження, один «поганий» вузол може непередбачувано псувати досвід користувачів.

Одне правило: не вимикайте TLS, щоб «швидко зайти». Саме так «тимчасове» перетворюється на «потрібно заводити інцидент».

Що насправді «зламалося», коли сказали про SSL

Proxmox VE подає Web UI через pveproxy на TCP/8006. Цей проксі очікує сертифікат і приватний ключ, які він може прочитати й розібрати.
Якщо він не може — часто не запускається. Якщо запускається, але сертифікат прострочений, не довірений або бракує проміжних, браузери й клієнти API можуть відмовлятися з’єднуватися.

Поширені кореневі причини, що ховаються за одним симптомом

Прострочений сертифікат: браузер показує попередження; автоматизація (Terraform, скрипти) може припинити роботу.
Зсув часу або неправильна часовий пояс: дійсний сертифікат виглядає як прострочений або ще не діє.
Несумісність ключа/сертифіката: pveproxy не запускається; порт 8006 може бути закритий.
Права/володіння: приватний ключ не читається сервісом (або навпаки — занадто відкритий, залежно від жорсткості політик).
Погане копіювання/вставка: PEM-формат зруйнований; відсутні BEGIN/END рядки; Windows-рядки кінців.
Встановлено неправильний сертифікат: сертифікат для імені хоста балансувальника, а ви звертаєтеся до IP вузла (або навпаки).
Проксі спереду: зворотний проксі подає власний сертифікат; ви виправили Proxmox, але користувачі все ще бачать старий сертифікат.
Плутанина SNI: браузер просить одне ім’я; проксі подає інший сертифікат.

Жарт #1: Сертифікати — як молоко: етикетка виглядає нормально, поки ви не відкриєте і не пошкодуєте про свій вибір.

Цікавинки та історичний контекст

Трохи контексту допоможе вирішити, чи «просто перегенерувати», чи «хірургічно виправити»:

TLS раніше називали SSL; усі досі кажуть «SSL-сертифікат», бо «TLS-сертифікат зламався» звучить страшно.
Браузери постійно посилювали правила щодо валідності сертифікатів, відповідності імен та повноти ланцюга; старий сертифікат, що «працював на моєму ноуті», може різко перестати працювати після оновлення браузера.
Let’s Encrypt зробив популярними короткоживучі сертифікати (зазвичай 90 днів), обмінявши довгі терміни на автоматизацію. Якщо автоматизація ламається — прострочення з’являється швидко.
Сучасні клієнти відкидають SHA-1 і слабкі RSA-ключі; старі внутрішні PKI-практики можуть спричинити аварії при зміні криптополітики.
Час — це залежність для довіри: X.509 валідація — це, фактично, «криптографія + годинники». Збої NTP реально спричиняли відмови в індустрії.
Проміжні сертифікати важливі: багато видавців покладаються на проміжні; якщо встановити лише листочок (leaf), «працює на деяких машинах, ламається на інших» — звичайне явище.
SNI (Server Name Indication) дозволяє кільком сертифікатам жити на одному IP:порті. Без нього ми б досі витрачали IP, наче 2005 рік.
За замовчуванням часто використовують самопідписані сертифікати в інфраструктурних UI, бо «безпечніше за замовчуванням» кращий варіант, ніж «відвантажити без TLS». Обмін — це керування довірою.

Практичні відновлювальні задачі з командами (і як вирішувати)

Нижче реальні задачі, які можна виконати по SSH на вузлі Proxmox. Кожна містить: команду, важливий для вас вивід і наступне рішення.
Тема: спочатку виміряйте, потім змінюйте мінімально необхідне.

Задача 1: Підтвердіть, що вузол доступний і ви не женетеся за мережевим привидом

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

Рішення: Якщо є втрата пакетів або немає маршруту, виправте мережу/VLAN/маршрутизацію перш ніж чіпати TLS. Сертифікати не лікують ARP.

Задача 2: Чи слухає порт 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))

Рішення: Якщо ви бачите pveproxy, UI працює і, ймовірно, проблема в довірі/терміні/ланцюгу.
Якщо нічого не слухає — переходьте одразу до логів сервісу і перевірки парсингу сертифіката.

Задача 3: Швидко перевірте стан сервісу

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)

Рішення: Якщо він упав — не гадати. Подивіться журнал далі; він часто вказує конкретний файл, який не може прочитати або розпарсити.

Задача 4: Прочитайте логи для реальної причини (зазвичай 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'.

Рішення: «no start line» означає, що формат PEM пошкоджено (помилка копіювання/вставки, неправильний файл або бінарні дані). Виправляйте вміст файлу, а не сервіс.

Задача 5: Перевірте системний час і статус NTP перед тим, як торкатися сертифікатів

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

Рішення: Якщо синхронізація часу no або час сильно не відповідає правді, виправте NTP спочатку. Інакше ви можете «виправити» сертифікат, який не був зламаним.

Задача 6: Перевірте дати сертифіката (термін дії та дата початку)

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

Рішення: Якщо notAfter у минулому — оновіть/замініть. Якщо notBefore у майбутньому — ваш час неправильний або встановлено невірний сертифікат.

Задача 7: Переконайтеся, що сертифікат відповідає приватному ключу (несумісність вбиває 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

Рішення: Хеші мають збігатися. Якщо ні — встановлено сертифікат, що не належить цьому ключу. Перевстановіть правильну пару або перегенеруйте коректно.

Задача 8: Перевірте права доступу та володіння файлами (класика «працювало до перезавантаження»)

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

Рішення: Якщо ключ читабельний для всіх — у вас проблема з безпекою. Якщо сервіс не може його прочитати — проблема доступності.
Proxmox зазвичай очікує адекватних прав власності root; не «chmod 777» у продакшені.

Задача 9: Перевірте, який сертифікат вузол фактично подає на 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

Рішення: Якщо ви бачите «unable to get local issuer certificate», ймовірно неповний ланцюг.
Це може бути прийнятно для внутрішніх систем з корпоративними сховищами довіри, але браузери й автоматизація все одно можуть відмовити.

Задача 10: Перевірте вміст файлу ланцюга сертифікатів (leaf + проміжні)

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

Рішення: Якщо ви планували встановити повний ланцюг, але файл містить лише 1 сертифікат — бракує проміжних.
Виправте, об’єднавши leaf + проміжні в правильному порядку (leaf першим).

Задача 11: Швидка перевірка, що ви не зламали DNS/відповідність імен

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

Рішення: Якщо ви звертаєтеся по IP, а сертифікат має тільки DNS-імена (або навпаки), користувачі отримуватимуть помилку під mismatch.
Або змініть спосіб доступу (бажано) або перевипустіть сертифікат з правильними SAN.

Задача 12: Перезапустіть потрібний сервіс і перевірте, що він лишається активним

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

Рішення: Якщо він знову впадає в failed — негайно перевірте журнал; повторні рестарти — не стратегія, це загроза доступності.

Задача 13: Підтвердіть, що API відповідає локально (обминає драму довіри браузера)

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

Рішення: Якщо локальний curl працює, проблема може бути в довірі клієнта, зворотному проксі або невідповідності імен — а не в самому Proxmox.

Задача 14: Якщо ви використовуєте зворотний проксі, доведіть, який сертифікат бачать користувачі

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

Рішення: Якщо проксі подає інший сертифікат, ніж вузол, виправте конфігурацію проксі/сховище сертифікатів. Не продовжуйте «виправляти Proxmox» для проблеми проксі.

Задача 15: Перевірте здоров’я файлової системи кластера (бо сертифікати можуть жити в /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

Рішення: Якщо кластер не має кворуму або /etc/pve пошкоджено, ви можете спостерігати дивну поведінку «файл відсутній».
Відновіть кворум/зв’язок кластера перед великими змінами конфігурації.

Задача 16: Переконайтеся, що ви редагуєте правильні файли (Proxmox має власні уявлення)

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

Рішення: Імена файлів різняться за версією та налаштуванням; не припускайте. Якщо сумніваєтесь, слідуйте логам pveproxy — вони вкажуть, який шлях використовується.

Безпечні шляхи відновлення: виберіть стратегію ремонту

Коли ви визначили категорію — час, сервіс, вміст сертифіката або проксі спереду — оберіть стратегію, яка відповідає ситуації.
За креативність ніяких нагород немає. Є нагорода за виправлення, яке переживе наступне перезавантаження.

Шлях A: UI працює, сертифікат прострочено/недовірений → оновити або замінити, зберігаючи сервіс

Якщо ss показує pveproxy і локальний curl -k повертає JSON версії, ви не у важкому аутеджі.
Ви у відмові довіри. Це краще.

Якщо у вас вже є автоматизація Let’s Encrypt: відновіть автоматизацію, потім оновіть сертифікат.
Якщо ви використовуєте внутрішнє PKI: перевипустіть із правильними SAN, включіть ланцюг і розгорніть узгоджено.
Якщо використовували дефолтний самопідписаний: безпечно перегенеруйте і розподіліть довіру там, де потрібно (браузери адміністраторів, вузли автоматизації).

Шлях B: pveproxy не стартує → спочатку виправте парсинг/права, потім думайте про перегенерацію

Найшвидше безпечне відновлення зазвичай: відновити відомо добру пару сертифікат/ключ з бекапу або перегенерувати сертифікат проксі Proxmox стандартними інструментами.
Чого варто уникати — ручного редагування PEM під тиском без валідаторів.

Якщо треба «заходити терміново», поки ви відновлюєте довіру, найменш поганий підхід — SSH + локальні перевірки API.
Не послаблюйте мережеву експозицію системи, бо браузер нетерплячий.

Шлях C: Зворотний проксі спереду → виправте проксі спочатку або тимчасово обійдіть його

Якщо користувачі заходять на pve.example.internal і це спрямовано на Nginx/HAProxy/Traefik, сертифікат, який бачить браузер, може бути зовсім не Proxmox-овим.
Ви можете цілий день оновлювати на вузлі, а рукопашний handshake все одно зірветься на краю мережі.

В інцидентах я віддаю перевагу контрольованому обходу: доступ до вузла напряму по мережі керування, перевірка його стану, а потім виправлення краю.
Це запобігає маскуванню помилки проксі під відмову Proxmox.

Шлях D: Неправильний час → виправте час, потім повторно перевірте перед змінами

Сертифікати залежать від часу. Якщо час неправильний — усе виглядає зламаним:
валідація сертифіката, валідність токенів, іноді навіть взаємодія кластера. Виправлення часу майже завжди ефективне.

Жарт #2: NTP — як паста для зубів: помічають лише коли її нема, і ситуація швидко стає неприємною.

Три корпоративні міні-історії (як це йде не так у реальному житті)

Міні-історія 1: Відмова через хибне припущення

Середня компанія тримала невеликий кластер Proxmox для внутрішніх сервісів. Вони використовували дефолтний сертифікат Proxmox на кожному вузлі і навчали адміністраторів натискати «продовжити» в браузері.
Це було не елегантно, але стабільно — поки нова служба безпеки не розгорнула політику в браузері.

Наступного ранку ніхто не міг дістатися Web UI. Припущення було: «Proxmox впав». Насправді порт 8006 працював, ВМ працювали, сховище було в порядку.
Політика браузера просто відмовляла самопідписаним сертифікатам без спеціального винятку.

Перший крок команди — перезапустити сервіси і «перегенерувати сертифікати» на всіх вузлах. Це створило другу проблему: кожен вузол отримав інший самопідписаний сертифікат, і навіть адміністратори, які раніше погоджували попередження, не могли пройти через нові невідповідності в їхній автоматизації.

Виправлення було нудним: вони розгорнули сертифікат, підписаний внутрішнім CA з правильними SAN, а потім поширили внутрішній CA на керовані кінцеві точки.
Після цього UI «чарівно» знову запрацював, а інцидент перекваліфіковано як вплив зміни політики, а не відмову Proxmox.

Урок: «Браузер каже ні» — не те саме, що «сервіс упав». Розглядайте це як відмову каналу довіри, поки не доведено протилежне.

Міні-історія 2: Оптимізація, що обернулась проти

Інша організація хотіла «одне чисте URL» для Proxmox: єдине ім’я хоста за зворотним проксі з публічною довірою.
Вони підключили кластер до проксі, який термінував TLS, а потім форвардив до кожного вузла на 8006. У демо це працювало гарно.

Потім хтось оптимізував: ввімкнув агресивні health checks і «розумний роутинг» на основі HTTP-відповідей.
Proxmox, як UI з аутентифікацією, не дуже любить некоректні запити. Проксі почав помилково маркувати здорові вузли як нездорові під час коротких змін редиректу при вході.

Під час пізнішого оновлення сертифіката вони оновили cert на проксі, але забули налаштувати upstream SNI/host header.
Деякі клієнти бачили новий сертифікат; інші — старий, закешований або поданий через інший SNI-маршрут. Інцидент був періодичним і важкодовідним.

Вони врешті спростили: відокремили стабільну TCP-перевірку здоров’я від HTTP-логіки і налаштували детерміноване маршрутизування.
«Оптимізація» додала крихкості і приховала, де саме термінація TLS.

Урок: зворотні проксі можуть приховувати проблеми й створювати нові. Якщо ви ставите проксі перед Proxmox, чітко визначте, де живуть сертифікати і що означають ваші health checks.

Міні-історія 3: Нудна практика, що врятувала день

Регульована інфраструктура тримала Proxmox з внутрішнім PKI і короткоживучими сертифікатами. Їхня операційна команда робила дві нудні речі:
(1) зберігала конфігураційний бекап сертифікатів/ключів в зашифрованому сховищі з історією змін, і (2) щомісяця тестувала продовження в staging-вузлі.

Одного вікенду проміжний CA було обміняно. В понеділок деяка автоматизація, що зверталася до API Proxmox, почала падати з «unknown issuer».
Web UI був доступний для людей із оновленими сховищами довіри, але вузли автоматизації відставали в оновленні CA.

Оскільки у них був чистий запис змін, вони одразу підтвердили, що вузли Proxmox подають новий ланцюг коректно.
Виправляти довелося не Proxmox, а поширення проміжного сертифіката в сховища довіри вузлів автоматизації.

Жодних панічних перевипусків. Жодних рандомних рестартів. Жодних здогадок.
Інцидент закрили швидко, бо команда могла довести, де саме порушено довіру, і внести точкову зміну.

Урок: нудна дисципліна краща за героїчні дії. Коли сертифікати ламаються, ваша здатність порівняти «до/після» — це золото.

Поширені помилки: симптом → коренева причина → виправлення

Тут майбутнє-ви тихо дякує минулому-ви за чесність.
Це конкретні поширені сценарії, які я бачив у продакшені.

1) Браузер каже «Your connection is not private» і відмовляється продовжити

Симптом: UI блокується; немає «продовжити».
Коренева причина: Політика керованих браузерів забороняє самопідписані/невідомі CA; або сертифікат справді прострочений.
Виправлення: Використовуйте сертифікат з довірою CA (внутрішнє PKI або публічний CA) з правильними SAN; або оновіть прострочений сертифікат. Перевірте openssl x509 -dates.

2) Порт 8006 закритий; `pveproxy` постійно падає

Симптом: ss нічого не показує на 8006; systemd показує failed.
Коренева причина: Файл PEM пошкоджено, неправильний формат або несумісність ключа.
Виправлення: Читайте journalctl -u pveproxy. Перевірте заголовки PEM, зіставте модулі хешів, відновіть відомо добрі файли, потім перезапустіть.

3) «NET::ERR_CERT_COMMON_NAME_INVALID» або попередження про невідповідність імені

Симптом: Сертифікат дійсний, але для іншого хоста; помилка згадує CN/SAN mismatch.
Коренева причина: Звернення по IP або іншому DNS імені, ніж ті, що в SAN; часто після перейменування вузла або введення VIP.
Виправлення: Стандартизуйте доступ (бажано: одне DNS-ім’я на вузол або один VIP), перевипустіть сертифікат з SAN, що відповідають реальним шляхам доступу.

4) Працює з деяких машин, не працює з інших

Симптом: Один адміністратор може залогінитись; інший отримує помилки issuer/chain.
Коренева причина: Відсутній проміжний сертифікат у поданому ланцюгу; або різні сховища довіри у клієнтів.
Виправлення: Подавайте повний ланцюг (leaf + проміжні) і переконайтесь, що клієнти довіряють корінню/проміжним. Перевірте ланцюг через openssl s_client -showcerts.

5) Сертифікат «прострочений» відразу після оновлення

Симптом: Ви оновили, перезапустили, а все одно бачите стару дату закінчення.
Коренева причина: Ви оновили неправильний шлях сертифіката; зворотний проксі все ще подає старий; кеш браузера; або кілька вузлів за VIP і оновлено лише один.
Виправлення: Перевірте поданий сертифікат за допомогою openssl s_client проти тієї самої адреси, що бачать користувачі. Потім оновіть фактичну точку термінації.

6) Після «виправлення прав» pveproxy стартує, але безпека погіршилась

Симптом: Хтось поставив надто м’які права; ключ читає надто багато користувачів.
Коренева причина: Панічне послаблення/затвердіння прав без розуміння потреб сервісу.
Виправлення: Відновіть мінімально потрібні права; залиште приватний ключ читабельним тільки для root і при потребі для облікового запису сервісу. Задокументуйте очікувані режими доступу.

7) UI вузла працює, але приєднання до кластера/аутентифікація ламаються

Симптом: Web UI доступний; але міжвузлові операції падають або показують помилки аутентифікації.
Коренева причина: Плутанина між сертифікатом pveproxy для UI і сертифікацією для міжвузлового зв’язку; або порушено синхронізацію /etc/pve/quorum під час редагування.
Виправлення: Перевірте здоров’я кластера з pvecm status, переконайтесь, що /etc/pve змонтовано і консистентне, і вносьте зміни по вузлу, обережно.

Контрольні списки / покроковий план

Ці плани передбачають, що у вас є SSH-доступ (або консоль) до хоста. Якщо ні — виправте це спочатку.
Офлайн-доступ не розкіш; це «пасок безпеки» при роботі з гіпервізором.

Контрольний список 1: Швидке відновлення Web UI коли pveproxy не працює (один вузол)

Підтвердіть час: виконайте timedatectl. Якщо неправильно — виправте NTP/час і повторно перевірте. Не чіпайте сертифікати поки це не виправлено.
Перевірте, чи слухає 8006: ss -lntp | grep 8006. Якщо нічого — рухаємося далі.
Перегляньте логи pveproxy: journalctl -u pveproxy -n 60. Визначте точну помилку (парсинг PEM, права, відсутній файл).
Перевірте формат файлу сертифіката: відкрите посилання на файл і впевніться, що там коректні PEM-блоки. Порахуйте блоки сертифікатів за допомогою awk.
Перевірте відповідність ключ/сертифікат: modulus md5 перевірка. Якщо несумісність — зупиніться і перевстановіть правильну пару.
Відновіть з відомого бекапу, якщо доступний. Це зазвичай найшвидший безпечний крок.
Перезапустіть pveproxy: systemctl restart pveproxy, потім перевірте systemctl is-active.
Перевірте локальний API: curl -k https://127.0.0.1:8006/api2/json/version.
Потім перевірте віддалено: використайте openssl s_client з робочої машини адміністратора, щоб підтвердити поданий сертифікат.

Контрольний список 2: UI працює, але браузер/клієнти відкидають сертифікат (відмова довіри)

Доведіть, що сервіс працює: ss -lntp і локальний curl -k.
Перегляньте дати сертифіката: openssl x509 -dates. Якщо прострочено — оновіть/перевипустіть.
Перевірте SAN: openssl x509 -ext subjectAltName. Якщо невідповідність — перевипустіть з правильними іменами.
Перевірте повноту ланцюга: openssl s_client -showcerts. Якщо бракує проміжних — подавайте повний ланцюг.
Визначте модель довіри:
- Внутрішній CA: розповсюдьте CA на клієнти, потім розгорніть листочок+проміжні.
- Публічний CA: переконайтесь, що метод валідації (DNS/HTTP) працює і автоматизація надійна.
- Самопідписаний: допустимий лише якщо ви контролюєте клієнтські сховища довіри; інакше це просто майбутні проблеми.
Перевірте принаймні з двох типів клієнтів: керований браузер + CLI інструмент (curl/openssl). Різні клієнти виявляють різні проблеми довіри.

Контрольний список 3: Підхід для кластера (щоб не поламати решту, лагодячи один вузол)

Перевірте кворум: запустіть pvecm status на здоровому вузлі спочатку.
Виберіть «золотий» вузол для перевірки процедури сертифікації перед тим, як чіпати інші.
Задокументуйте шлях доступу: прямий доступ до вузла vs VIP vs зворотний проксі. Ваш сертифікат має відповідати цій реальності.
Застосовуйте зміни по одному вузлу і перевіряйте:
- pveproxy активний
- 8006 слухає
- сертифікат, що подається, відповідає очікуванням
Якщо за балансувальником: тимчасово вивантажуйте (drain) вузол перед зміною сертифіката, щоб уникнути «лотереї» для користувачів.
Після всіх вузлів: окремо перевірте термінацію на VIP/проксі.

Питання й відповіді

1) Чи можна просто вимкнути HTTPS на Proxmox, щоб повернути UI?

Можна, але не варто. UI — це адміністрування гіпервізора: тут важливі облікові дані та сесійні токени.
Якщо потрібен екстрений доступ — використовуйте SSH і локальні перевірки API, поки відновлюєте TLS коректно.

2) Чому Proxmox називає це «SSL», якщо насправді TLS?

Це спадкова назва. Галузь досі каже «SSL-сертифікат» довго після того, як TLS замінив SSL на практиці. Ваш браузер говорить TLS; колеги кажуть SSL; таке життя.

3) Сертифікат дійсний, але браузери все одно скаржаться на «issuer». Чому?

Зазвичай це неповний ланцюг: ви встановили тільки leaf-сертифікат, але клієнтам потрібні проміжні, щоб побудувати довіру до кореня.
Перевірте через openssl s_client -showcerts і виправте, подаючи повний ланцюг.

4) Чому це сталося одразу після перезавантаження?

Дві часті причини: зсув часу (NTP не стартував коректно і годинник неправильний) або змінилися права/шляхи і pveproxy не може прочитати ключ при старті.
Перевірте timedatectl і journalctl -u pveproxy.

5) Чи безпечно використовувати дефолтний самопідписаний сертифікат Proxmox?

Це безпечно в тому сенсі, що трафік зашифровано, але сертифікат не довірений автоматично.
У керованому середовищі самопідписані сертифікати часто перетворюються на операційну заборгованість, бо політики і інструменти дедалі частіше їх відкидають.

6) Я оновив файли сертифікатів, але браузер все ще показує старий. Чому?

Ймовірно ви не дивитесь на той вузол, який редагували (VIP/балансувальник), або зворотний проксі термінує TLS.
Доведіть, що саме подається, через openssl s_client проти точного хоста і порту, який бачать користувачі.

7) Яке найпростішe «швидке» безпечне рішення, якщо pveproxy не стартує і ви під тиском?

Відновіть відомо добру пару сертифікат/ключ з захищеного бекапу, перезапустіть pveproxy і підтвердіть локальну відповідь API.
Перегенерування теж підходить, але відновлення знижує ризик внести несумісність або відсутній ланцюг під стресом.

8) Чи впливає виправлення сертифіката Web UI на трафік ВМ або сховище?

Не безпосередньо. Цей сертифікат належить plane керування (Web UI/API) через pveproxy.
Мережа ВМ і доступ до сховища зазвичай продовжують працювати навіть якщо UI недоступний — якщо ви не зламаєте інші сервіси під час роботи.

9) Як зрозуміти, чи це проблема Proxmox чи зворотного проксі?

Перевірте обидві точки. Якщо прямий доступ до вузла на 8006 подає правильний сертифікат і працює, але публічне ім’я падає — винен проксі/термінація на краю.

10) Яка найпоширеніша причина, яку ви бачите?

Прострочення в поєднанні з думкою «ми думали, що автооновлення працює», після чого з’ясовується, що робота оновлення залежала від DNS-токена, який протух місяці тому.
На другому місці: неповні ланцюги.

Наступні кроки, щоб уникнути повторення

Істина надійності: TLS-аутеджі рідко «важкі». Вони просто передбачувані, і передбачуваність ображає вас на виклику.
Виправлення — це не героїчні дії; це поставити сертифікати на ті самі колії життєвого циклу, що й все інше, за що ви відповідаєте.

Зробіть це наступним чином, поки інцидент ще свіжий

Запишіть фактичну точку термінації: прямий Proxmox, зворотний проксі чи балансувальник. Одне речення. Без двозначностей.
Стандартизуйтесь з іменами доступу: оберіть DNS-імена, які повинні використовувати люди, і перевипустіть сертифікати з SAN, що відповідають реальності.
Автоматизуйте оновлення з алертами: якщо оновлення не вдається, ви повинні дізнатись до того, як користувачі. Слідкуйте за датами закінчення і статусом завдань.
Тримайте пакет відкату «знаю-що-робити»: зашифрований бекап сертифікатів/ключів/ланцюга (і нотатки про їхні шляхи), плюс протестована процедура відновлення.
Тестуйте з двох типів клієнтів: керований браузер і CLI-інструмент. Це рано виявляє проблеми з ланцюгом і політиками.

Перефразована ідея Джона Оллспоу: надійність походить від систем і зворотних зв’язків, а не від індивідуальних героїчних дій. Побудуйте петлю — і ваші майбутні вихідні стануть кращими.

Схожі статті

Ubuntu 24.04: збої TLS‑підключення в curl — швидкий чекліст виправлень SNI/CA/часу Proxmox «Too Many Open Files»: який ліміт підвищувати і для якої служби