vCenter после перезагрузки отдаёт «No healthy upstream»: проверяем STS и возвращаем вход через vCert

Ночью перезагрузили VCSA после планового обслуживания, утром вместо vSphere Client — серая страница с надписью «no healthy upstream». SSH пускает, VAMI на 5480 открывается, виртуалки крутятся как ни в чём не бывало, а управлять инфраструктурой нечем. Разбираю, почему в 8 случаях из 10 виноват не веб-сервер и не «глюк обновления», а протухший сертификат службы выдачи токенов (STS) или solution users; как за десять минут это доказать по логам; и как аккуратно заменить сертификат утилитой vCert — включая тот случай, когда vCenter'ов в домене SSO несколько и один неверный откат превращает аварию на час в аварию на сутки.

«No healthy upstream» — это ответ прокси, а не приложения

Первое, что надо понять про эту ошибку: её отдаёт не vCenter. Её отдаёт Envoy — обратный прокси, который в VCSA сидит на 443 и разбрасывает входящие запросы по внутренним службам. Фраза переводится буквально: «в пуле апстримов нет ни одного живого». То есть браузер до аплайнса доехал, TCP установился, TLS отработал, прокси принял запрос — и не нашёл, кому его отдать. Служба vsphere-ui либо не поднялась, либо поднялась и упала, либо крутится в цикле рестартов.

Отсюда та самая обманчивая картина, из-за которой люди теряют полдня. SSH пускает — потому что sshd к сертификатам vCenter отношения не имеет. VAMI на 5480 открывается — потому что это отдельный applmgmt со своим стеком, и он честно скажет вам «Health: Unknown», что тоже мало кого настораживает. Хосты ESXi живут, виртуалки работают, vSphere HA работает (агенты на хостах не зависят от vCenter). Не работает ровно одно: централизованное управление. Поэтому первое, что я говорю клиенту по телефону — продакшен не лежит, паниковать не нужно, у нас есть время сделать всё аккуратно.

И вот тут начинается стандартный сценарий, который я вижу из раза в раз: рестарт служб, потом ребут аплайнса, потом ещё один ребут «на всякий случай», потом откат снапшота недельной давности, потом паника и тикет в поддержку. Не помогает ничего, потому что причина не в службах. По моей статистике на 7.x и 8.x примерно в восьми случаях из десяти это сертификат: STS signing, solution users или корневой VMCA под ними. Оставшиеся два — забитый раздел /storage/log или /storage/seat и разъехавшееся системное время. Именно в таком порядке я и проверяю.

# 1. время — если оно уехало, дальше можно не смотреть
date
chronyc tracking 2>/dev/null || ntpq -p

# 2. диски — /storage/log и /storage/seat заполняются молча
df -h

# 3. кто из служб не поднялся
service-control --status --all

# 4. кто падает в цикле
vmon-cli -l

• Ошибку рисует Envoy на 443 — значит, сеть, DNS и TLS до аплайнса живы, проблема внутри.
• SSH и VAMI (5480) работают в обход основного веб-стека — их доступность ничего не доказывает.
• Виртуальные машины и vSphere HA продолжают работать без vCenter — аварии продакшена нет.
• Не работают: vMotion/DRS, бэкапы через vCenter (Veeam, кроме прямого доступа к хостам), любые API-интеграции.
• Ребут не лечит. Если после ребута стало хуже — вы просто перезапустили службу, которая до этого держалась на выданных ранее токенах.

Разбор: магазин винила на 45 рабочих мест, три часа без управления

Условно — магазин винила «Виниловая пластинка», 45 рабочих мест: торговый зал, склад, интернет-магазин и небольшая бухгалтерия. Свой маленький серверный шкаф: два хоста ESXi 8.0, VCSA 8.0 на одном из них, на виртуалках — 1С, сервер интернет-магазина, файловое хранилище с каталогом и фотографиями пластинок, контроллер домена. Отдельного ИТ-отдела нет, инфраструктуру ведём мы. Обслуживание проводили в субботу после закрытия: обновили прошивки на хостах, по очереди вывели их в maintenance, в конце перезагрузили саму VCSA — штатная процедура. В воскресенье никто не заходил. В понедельник в 09:12 звонок от управляющей: «бэкап за ночь не прошёл, а vSphere пишет какую-то no healthy upstream».

Дальше по шагам. Пингуется, 443 отвечает, VAMI открывается и показывает Health: Unknown. Захожу по SSH, смотрю date — время в порядке, расхождение с источником 12 мс. df -h — свободно 41 % на /storage/log, нормально. service-control --status --all — в Stopped висят vmware-stsd, vmware-vpxd, vpxd-svcs, vsphere-ui, vmware-vapi-endpoint. Классическая пирамида: не поднялся STS — не поднялось всё, что просит у него токены. Дальше — только в логи, гадать бессмысленно.

В /var/log/vmware/vpxd-svcs/vpxd-svcs.log лежало «Signing certificate is not valid at Date...», в /var/log/vmware/sso/vmware-identity-sts.log — «The token authority rejected an issue request for time period» и InvalidTimeRange. Проверяю сам сертификат STS: notBefore 14.03.2024, notAfter 14.03.2026, выписан не VMCA, а корпоративным центром сертификации. Ребут был 21 марта — то есть сертификат протух за неделю до аварии, а vCenter продолжал спокойно работать, потому что служба stsd не перезапускалась, а уже выданные токены доживали свой срок. Первая же перезагрузка всё вскрыла.

Почему это вообще случилось на 8.0, где автопродление STS есть из коробки? Потому что в 2024 году прошлый подрядчик, заводивший в магазине внутренний центр сертификации «для порядка», заменил в том числе и STS signing certificate на «свой». Автопродление в vSphere работает только для сертификатов, выпущенных VMCA. Кастомные и сторонние не продлеваются никогда — vCenter про них честно пишет в алармах, но алармы в vSphere Client никто не читает, а на почту они не настроены. Итог: 47 минут на замену сертификата через vCert, ещё 20 минут на перезапуск служб и проверку, что задание резервного копирования снова видит vCenter, плюс час на разбор и на то, чтобы завести внешний мониторинг срока годности. Касса и интернет-магазин не простаивали ни минуты, данные не пострадали, ни одна виртуалка не перезагружалась.

• Симптом: «работало до перезагрузки» — почти всегда означает, что сертификат истёк раньше, а ребут просто не дал службе стартовать.
• Сертификат STS по умолчанию на старых установках жил 2 года; при апгрейде с 6.7/7.0 этот двухлетний срок переезжает вместе с базой.
• Кастомный (не VMCA) STS-сертификат не участвует в автопродлении — это самая частая ловушка после «приведения в порядок сертификатов» подрядчиком.
• Веб-морда ляжет целиком, но виртуалки, HA и сеть не заметят ничего — это авария управления, а не сервиса.

Десять минут на доказательство: логи и хранилища сертификатов

Не начинайте с замены. Начните с того, чтобы доказать себе, что виноват именно сертификат, и понять, какой именно. Причин у «no healthy upstream» несколько, и лечатся они разными пунктами меню. Первый заход — grep по трём логам сразу. Broadcom в KB316619 прямо перечисляет строки, которые надо искать; я держу эту команду в сниппетах и вставляю не глядя.

grep -iE "Signing certificate is not valid|InvalidTimeRange|Failed to read X509|certificate has expired" \
  /var/log/vmware/sso/vmware-identity-sts.log \
  /var/log/vmware/vpxd-svcs/vpxd-svcs.log \
  /var/log/vmware/vpxd/vpxd.log

Второй заход — обход хранилищ VECS. Эта однострочная команда есть в KB402693 и она мне нравится тем, что за одну секунду показывает alias и дату истечения по всем стораджам: MACHINE_SSL_CERT, TRUSTED_ROOTS, вся папка solution users (vpxd, vpxd-extension, vsphere-webclient, machine). Если у вас просроченными светятся именно solution users — это не STS, это отдельный сценарий, и чинится он пунктом «Solution user certificates», а не «STS signing certificates».

for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do \
  echo "[*] Store :" $store; \
  /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -ie "Alias" -ie "Not After"; \
done;

И тут важная деталь, о которую спотыкаются почти все: сертификата STS в этом выводе не будет. STS signing certificate живёт не в VECS, а в каталоге VMware Directory (vmdir), поэтому vecs-cli его физически не видит. Проверять его нужно либо через vSphere Client (Administration → Certificate Management → STS signing certificate — но морда у вас как раз и не работает), либо через vCert: меню 2 «View Certificate Info», пункт 8 «STS signing certificates». Отдельный скрипт checksts.py, который годами кочевал по форумам, Broadcom из KB318968 удалил и объявил устаревшим — не тратьте на него время, он на 8.x и 9.x уже не про то.

Про наследие, которое до сих пор всплывает в поиске. Скрипт checksts.py раньше прикладывался к VMware KB 79248 — теперь это Broadcom KB318968, и в ней прямо написано, что checksts.py устарел и вместо него используется vCert. Та же история с fixsts.sh из старой KB 76719: адрес сейчас ведёт на KB316619, где рекомендован только vCert. Если у вас в заметках лежат эти скрипты с форумов — на 8.x и 9.x я их не запускаю. А вот lsdoctor (KB320837) по-прежнему актуален, но для другой задачи: он лечит рассинхрон данных PSC и регистраций служб в Lookup Service (ключи --rebuild, --solutionusers), а не просроченные сертификаты. Если после замены STS Lookup Service ругается на регистрации — это его случай, и снапшот перед ним обязателен.

• /var/log/vmware/sso/vmware-identity-sts.log — сама служба STS.
• /var/log/vmware/vpxd-svcs/vpxd-svcs.log — здесь всплывает «Signing certificate is not valid at Date».
• /var/log/vmware/vpxd/vpxd.log — «Failed to read X509 cert».
• /var/log/vmware/lookupsvc/ — если поехали SSL trust anchors и регистрации служб.
• /var/log/vmware/vsphere-ui/ и /var/log/vmware/vapi-endpoint/ — подтверждают, что фронт не стартовал следом.
• /var/log/vmware/content-library/cls.log — ошибки аутентификации библиотеки контента, KB316619 тоже перечисляет этот лог.

vCert: чем работать в 2026 году и как его завести на лежащем vCenter

Исторически такие вещи чинили скриптами certificate-manager и fixcerts. Сегодня Broadcom для всего жизненного цикла сертификатов рекомендует vCert — меню-ориентированную утилиту на Python, которая поддерживает vCenter Server 7.0, 8.0 и 9.0. Она распространяется приложением к KB385107; на момент написания актуальна сборка vCert-6.1.2-20260713.zip, хэши опубликованы в самой статье — сверяйте, качать «первую попавшуюся с гитхаба» тут категорически не надо. И да, в KB прямым текстом написано, что инструмент предназначен для использования под руководством поддержки Broadcom; это не значит «нельзя», это значит «понимайте, что делаете, и держите снапшот».

Отдельная бытовая проблема: аплайнс, скорее всего, в интернет не ходит, а wget/curl наружу через прокси на VCSA настраивать в разгар аварии — сомнительное удовольствие. Я просто заливаю zip на /root по SCP/WinSCP ровно в том виде, в каком скачал, и распаковываю на месте. Никаких промежуточных перепаковок — иначе слетают права и хэш.

# заливаем архив на /root аплайнса, затем на VCSA:
unzip -q vCert-6.1.2-20260713.zip
cd vCert-6.1.2-20260713
chmod +x vCert.py
./vCert.py

Меню верхнего уровня — девять пунктов: проверка текущего состояния сертификатов, просмотр информации, управление сертификатами, управление SSL trust anchors, проверка конфигураций, полный сброс на VMCA-сертификаты, операции с сертификатами ESXi, перезапуск служб и генерация отчёта. Для нашей задачи нужны ровно два маршрута: меню 2 → пункт 8 посмотреть, что там с STS, и меню 3 → пункт 8 заменить. Логи утилиты пишутся в /var/log/vmware/vCert/vCert.log, рабочие копии и бэкапы старых сертификатов складываются в /root/vCert-master/ с датой — оттуда потом удобно доставать, если что-то пошло не так.

Чего я делать не советую, пока не перепробовал точечные варианты: пункт 6 «Reset all certificates with VMCA-signed certificates». Он действительно чинит почти всё, но заодно сносит ваши кастомные машинные сертификаты, ломает доверие у интеграций (бэкап, мониторинг, скрипты с прибитыми отпечатками) и превращает часовую задачу в двухдневную. Полный сброс — это последний рубеж, а не первый шаг. Ещё нюанс для 9.0: пункт просмотра smart card информации там не поддерживается, не пугайтесь ошибки.

После замены службы надо перезапустить. В vCert для этого есть меню 8 «Restart services», но если утилиту уже закрыли, я делаю то же самое руками — полной остановкой и полным запуском, а не рестартом отдельных служб, чтобы зависимости поднялись в правильном порядке. Запуск занимает 10–15 минут, прерывать его не надо, даже если кажется, что всё зависло.

service-control --stop --all
service-control --start --all
# убеждаемся, что stsd, vpxd и vsphere-ui в статусе Running
service-control --status --all

• Меню 1 — Check current certificate status: быстрый обзор, с него начинаем всегда.
• Меню 2 → 8 — View Certificate Info → STS signing certificates: смотрим notBefore/notAfter и кем выписан.
• Меню 3 → 8 — Manage Certificates → STS signing certificates: собственно замена.
• Меню 3 → 2 — Solution user certificates: если по vecs-cli просрочены именно они.
• Меню 4 — Manage SSL trust anchors: если после замены Lookup Service продолжает ругаться на несовпадение.
• Меню 8 — Restart services: перезапуск в правильном порядке, не надо изобретать свой.

Enhanced Linked Mode: где обычно всё портят окончательно

Ошибка, которая превращает управляемую аварию в неуправляемую, всегда одна и та же: админ откатывает снапшот на одном узле ELM, потому что «на нём же и сломалось». А состояние домена SSO у вас общее — репликация vmdir, регистрации служб в Lookup Service, доверенные корни. Откатили один узел на вчерашнее состояние — получили расхождение с остальными, которое разгребается уже не за час и не вашими силами. Правило простое: любой откат в ELM — это скоординированная операция по всему домену SSO, все узлы или ни одного.

Второй момент, приятный: начиная с vSphere 8.0 обновление STS-сертификата на одном vCenter распространяется на все связанные системы автоматически. То есть бегать по четырём аплайнсам и менять сертификат на каждом не нужно — и не надо, это как раз способ развалить домен. Меняем на одном, потом проверяем остальные и, если поддержка/логи требуют, вручную перезапускаем службы. Broadcom отдельно оговаривает, что в отдельных случаях ручной рестарт всё-таки понадобится, хотя в норме на 8.0+ замена STS проходит без перезагрузки vCenter.

И третий момент, о котором забывают до первого недовольного бухгалтера: замена STS signing сертификата инвалидирует токены, сохранённые в пользовательских scheduled tasks. Все задания, которые кто-то когда-то создал в vSphere Client — «выключить ВМ в 22:00», «снять снапшот перед обновлением» — после замены надо удалить и создать заново. Молча они не заработают. Выгрузите их список ДО работ, иначе потом будете вспоминать по памяти.

Планируйте окно честно. Для одиночного vCenter это 40–60 минут работы плюс запас. Для ELM из трёх-четырёх узлов — считайте два-три часа только на корректные выключенные снапшоты и обратное включение, и это при условии, что всё пройдёт с первого раза. У «Виниловой пластинки» один vCenter, и весь этот раздел их не касается — но стоит компании открыть второй магазин с отдельным vCenter в том же домене SSO, правила меняются.

• Не откатывать отдельный узел ELM — только весь домен SSO целиком.
• Снапшоты в ELM снимаются на выключенных аплайнсах, иначе они бесполезны.
• На 8.0+ замена STS на одном узле обновляет остальные — не повторяйте процедуру на каждом.
• Выгрузите список пользовательских scheduled tasks до работ: после замены STS их придётся пересоздать.
• Порядок включения: сначала узел с ролью, где меняли сертификат, дайте службам подняться полностью, потом остальные.

Что реально изменилось в 8.0 и 9.0 — и почему это не индульгенция

Хорошая новость: тот кошмар с двухлетними STS-сертификатами, который выкосил в 2023–2024 годах сотни инсталляций vSphere 6.7 и 7.0, в современных версиях в основном закрыт. Начиная с vSphere 8.0, vCenter Single Sign-On сам продлевает STS signing certificate, выпущенный VMCA, — причём делает это заранее, до срабатывания 90-дневного аларма. На чистой установке 9.0 сертификат выписывается сразу на 10 лет. Аларм о приближении срока показывается раз в неделю начиная за 90 дней и ежедневно за последние семь. Обновление или импорт STS-сертификата на 8.0 и выше в норме не требует перезапуска vCenter, то есть простоя нет вообще.

Теперь честно про то, где эта защита не работает. Во-первых, автопродление распространяется только на VMCA-сертификаты — кастомный или сторонний STS не продлевается никогда, и это ровно тот сценарий, который я разбирал выше на примере «Виниловой пластинки». Во-вторых, апгрейд с 6.7/7.0 переносит существующие сертификаты как есть: вы можете сидеть на 8.0 U3 с сертификатом, выписанным ещё в 2022-м на два года. В-третьих, автопродление касается STS — а «no healthy upstream» прекрасно вызывается и просроченными solution users, и истёкшим корневым VMCA, у которых своя логика жизни.

Поэтому мой практический вывод такой: на свежих 8.0 U3 и 9.x с VMCA-сертификатами риск действительно сильно преувеличен, специально ничего делать не надо — и это тот случай, когда я говорю клиенту «забейте». А вот если у вас апгрейженная инсталляция или кто-то когда-то «наводил порядок с сертификатами» руками — проверьте прямо сейчас, это пятнадцать минут. Broadcom рекомендует менять STS-сертификат, если до истечения осталось меньше шести месяцев; на мой взгляд, шесть месяцев — разумный порог, за который ещё можно спокойно спланировать окно.

Единого мнения по одному вопросу в сообществе, кстати, нет: менять ли STS обратно на VMCA-выпущенный, если у вас корпоративный CA. Формально требований безопасности к STS-сертификату как к «публичному» нет — он внутренний, его никто снаружи не проверяет, и служба безопасности обычно требует корпоративный CA только для Machine SSL, то есть для того, что видит браузер. Я в таких случаях возвращаю STS на VMCA и оставляю корпоративный CA только на машинном сертификате: получаем и зелёный замок в браузере, и работающее автопродление. Но если у вас в политике ИБ прописано иначе — спорить не буду, просто заведите календарное напоминание за полгода.

• vSphere 8.0+ — автопродление STS для VMCA-сертификатов, до срабатывания 90-дневного аларма.
• Чистая установка 9.0 — STS-сертификат на 10 лет.
• Кастомные и сторонние STS-сертификаты не продлеваются автоматически — вообще никогда.
• Апгрейд с 6.7/7.0 тащит за собой старые сроки: версия новая, сертификат старый.
• Порог замены по рекомендации Broadcom — меньше шести месяцев до истечения.

Чек-лист на будущее: что я оставляю у клиента после такой аварии

Разовое лечение — это половина работы. Вторая половина в том, чтобы через два года история не повторилась с другим админом и другим сертификатом. У меня после каждого такого случая остаётся короткий, намеренно скучный набор из четырёх вещей — ничего изощрённого, всё делается за пару часов и потом работает само.

Первое — внешняя проверка сроков. Не аларм внутри vSphere Client (его увидит тот, кто и так каждый день туда заходит, то есть никто), а активная проверка снаружи, которая шлёт в мессенджер. У себя мы держим это в Zabbix: скрипт раз в сутки ходит на аплайнс и вытаскивает даты по всем хранилищам, порог предупреждения — 90 дней, критикал — 30. Второе — отдельный контроль именно STS, потому что, как уже говорилось, в VECS его нет и обычные чекеры сертификатов его не увидят. Третье — мониторинг доступности /ui с проверкой кода ответа: 503 и текст «no healthy upstream» должны приходить алертом, а не звонком клиента в понедельник утром.

Четвёртое, и самое недооценённое — резервная копия самого vCenter, которая делается не через vCenter. Встроенный File-Based Backup из VAMI на 5480 работает независимо от веб-стека, настраивается за пять минут и складывает бэкап на SFTP/NFS. Если у вас есть свежий file-based backup, то самый плохой сценарий с сертификатами перестаёт быть страшным: развернули новый аплайнс из ISO, восстановили конфигурацию, поехали дальше. Проверьте, что он настроен и что задание реально отрабатывает — в половине инсталляций, куда я прихожу, эта галка не стоит вообще.

И про приоритеты, раз уж мы про них. Если у вас в моменте лежит vCenter — порядок такой: снапшот, логи, точечная замена сертификата через vCert, рестарт служб. Не сброс всех сертификатов, не переустановка, не откат недельного снапшота с потерей всей истории изменений. Если у вас ничего не лежит и вы просто дочитали статью — потратьте пятнадцать минут на проверку эмитента и сроков. Всё остальное из этого списка можно спокойно отложить на ближайшее плановое окно.

• Внешний мониторинг сроков всех сертификатов VCSA: warning 90 дней, critical 30.
• Отдельная проверка STS signing certificate (его нет в VECS).
• HTTP-чек https://vcenter/ui с алертом на 503 / «no healthy upstream».
• Настроенный и проверенный File-Based Backup из VAMI на 5480 — независимо от vCenter.
• Актуальная выгрузка пользовательских scheduled tasks — понадобится после любой замены STS.
• Записанная в базе знаний топология SSO: кто с кем в ELM, какие узлы гасить вместе.

Частые вопросы