Облачное хранилище
Проблема с доступом в vCenter: ошибка Server certificates have expired
Ошибка Server certificates have expired в vCenter

Когда в vCenter истекают внутренние сертификаты, администратор получает классический «подарок»: веб-консоль перестаёт открываться, Appliance Management не доступен, а браузер даёт ошибку «Server certificates have expired».
Ситуация неприятная, но решаемая.

Почему это происходит

VMware vCenter использует набор внутренних сертификатов:

  • Machine SSL Certificate
  • STS Certificate
  • Solution Users Certificates
  • Root CA от VMCA

Когда один или несколько сертификатов истекают, vCenter перестаёт доверять собственным сервисам. В итоге интерфейс «падает» — даже логин под root или administrator@vsphere.local не помогает.

Как восстановить доступ

1. Подключаемся по SSH

Заходим на VCSA под root.

Включить SSH при необходимости:

shell.set --enabled true
shell

2. Запускаем Certificate Manager

/usr/lib/vmware-vmca/bin/certificate-manager

3. Выбираем пункт переработки всех сертификатов

Обычно это пункт №4 — Regenerate a new VMCA Root Certificate and replace all certificates.

4. Вводим пароль администратора

Нужен пароль от administrator@vsphere.local.

5. Заполняем поля сертификата

Допустимо оставить большинство значений по умолчанию.
Главное — корректный FQDN vCenter, также может пригодиться указать верный ip-address

6. Подтверждаем замену

Certificate Manager пересоздаст:

  • корневой сертификат VMCA
  • Machine SSL
  • сертификаты solution users
  • цепочки доверия

После завершения сервисы vCenter автоматически перезапустятся, и доступ обычно возвращается.

После восстановления

  • Проверьте работу внешних компонентов (backup-системы, плагины, мониторинг). Иногда требуется повторная авторизация.
  • Если в инфраструктуре использовались кастомные сертификаты CA — убедитесь, что цепочка доверия не нарушена.
  • Сделайте свежий бэкап / snapshot VCSA.
  • Проверьте срок действия STS-сертификата — это частая точка отказа в vSphere 6.x/7.x.

FAQ

❓ Что делать, если используется кастомный сертификат, а не VMCA?
Процесс аналогичен, но требуется повторный импорт цепочки CA после пересоздания VMCA.

❓ Можно ли заменить только один сертификат, а не все?
Да, Certificate Manager позволяет менять Machine SSL, solution users и root отдельно. Но при полной «порче» системы проще и безопаснее пересоздать всё.

❓ После замены сертификатов плагины в vCenter перестали работать.
Удалите их и добавьте заново — чаще всего требуется обновление trust-цепочки.

❓ Как проверить срок действия STS?
VMware предоставляет Python-скрипт для анализа STS token-signing сертификата. Его стоит держать под рукой, если в инфраструктуре vCenter 6.5–7.0.

Советы

  • Проверяйте срок действия STS-сертификата заранее — в vSphere 6.x/7.x именно он чаще всего вызывает полный отказ авторизации.
  • Если вы используете собственный CA, храните цепочки доверия отдельно: корень, промежуточные и Machine SSL — это сильно ускоряет восстановление при сбоях.
  • После полной регенерации сертификатов проверяйте плагины и внешние сервисы (бэкап, мониторинг, репликация). При обрыве trust-цепочки они «тихо» перестают работать.
  • Сразу после восстановления сделайте snapshot или резервную копию VCSA — это лучший rollback на случай, если после замены сертификатов выявятся дополнительные проблемы.
  • Не смешивайте кастомные сертификаты и автоматическую выдачу VMCA — это частая причина конфликтов цепочек доверия. Решите заранее, какой подход используете.
  • Поддерживайте корректный DNS и обратные записи PTR — сертификаты VMware чувствительны к FQDN, и ошибки имен часто ломают авторизацию.

Полезные ссылки