1 октября 2026, 12:00

Есть инфраструктура, которую давно хочется заменить, но пока она продолжает работать и требует аккуратного сопровождения. В моём случае это связка Exchange 2010 за Forefront TMG 2010.

Снаружи всё выглядит просто: HTTPS-запрос приходит на пограничный шлюз и уходит на Exchange. Но сертификат при этом живёт сразу в нескольких местах. Выпустить новый сертификат недостаточно: его нужно экспортировать, перенести, назначить службам Exchange, выбрать в IIS, переключить Web Listener на TMG и проверить результат с внешней стороны.

В этой статье - обезличенный рабочий регламент без паролей, внутренних имён серверов, thumbprint и адресов.

Схема продления TLS-сертификата в контуре Exchange и TMG

Архитектура контура

Internet
   |
   | HTTPS :443
   v
+---------------------+
| Edge Gateway / TMG  |
| HTTPS Web Listener  |
+----------+----------+
           |
           | HTTPS publish
           v
+---------------------+
| Exchange 2010       |
| IIS / OWA / SMTP    |
+---------------------+

Сертификат выпускается на отдельной Windows-машине через win-acme. HTTP-01 challenge сохраняется в webroot Exchange, после чего PFX вручную переносится на Exchange и пограничный шлюз.

Почему одной кнопки Renewal недостаточно

В старом контуре сертификат используется в нескольких слоях:

  • win-acme выпускает новый сертификат;
  • Windows Certificate Store хранит сертификат и приватный ключ;
  • Exchange должен получить нужные services;
  • IIS должен использовать новый binding на порту 443;
  • TMG Web Listener должен отдавать новый сертификат наружу;
  • правила публикации должны продолжить работать;
  • внешний клиент должен увидеть именно новый срок действия.
issue
  -> export PFX
  -> install on Exchange
  -> assign IIS + SMTP
  -> select IIS binding
  -> install on TMG
  -> switch Web Listener
  -> verify from Internet

1. Подготовка win-acme

В рабочей схеме использовался win-acme 2.2.9.1701. Перед запуском проверьте, что приватный ключ разрешено экспортировать в PFX:

{
  "PrivateKeyExportable": true
}

Запускайте wacs.exe от имени администратора.

Для существующего renewal последовательность выглядит так:

A  -> Manage renewals
D  -> посмотреть параметры renewal
T  -> Run the renewal (force, no cache)

В параметрах renewal должны быть указаны:

  • источник: Manual;
  • проверка: FileSystem;
  • challenge: HTTP-01;
  • webroot, доступный IIS Exchange;
  • хранилище: CertificateStore;
  • имена OWA и Autodiscover.

В публичной статье реальные домены намеренно не указываются.

Почему нужен force/no cache

В моём случае обычный renewal завершался ошибкой:

Error preparing for challenge answer.
No certificate generated

Режим force, no cache создаёт новый ACME order и не использует старое состояние renewal. Это не универсальное лекарство, но хороший первый шаг, если параметры уже проверены, а старый запуск застрял на подготовке challenge.

Ожидаемый успешный вывод выглядит примерно так:

Authorizing using http-01 validation (FileSystem)
Authorization result: valid
Downloading certificate
Installing certificate in the certificate store
Renewal succeeded

Проверяйте, что статус valid получен для каждого имени сертификата.

2. Экспорт сертификата в PFX

После успешного выпуска откройте MMC и добавьте оснастку Certificates для локального компьютера.

Найдите свежий сертификат и проверьте:

  • правильный CN;
  • наличие приватного ключа;
  • актуальные даты NotBefore и NotAfter;
  • наличие нужных SAN-имён.

Путь экспорта:

Certificates (Local Computer)
  -> Personal
    -> Certificates
      -> All Tasks
        -> Export
          -> Yes, export the private key
          -> PKCS #12 (.PFX)

При экспорте включите цепочку сертификатов и задайте отдельный сильный пароль. Сам PFX и пароль нельзя хранить в Git, общем чате или в незашифрованной папке.

PFX + private key
        |
        +------> Exchange 2010
        |
        +------> Forefront TMG 2010

3. Установка на Exchange 2010

Импортируйте PFX на Exchange в хранилище локального компьютера:

Local Computer
  -> Personal
    -> Certificates

Не используйте Current User. Exchange работает с сертификатами компьютера.

После импорта проверьте список сертификатов из Exchange Management Shell:

Get-ExchangeCertificate |
  Format-List Thumbprint,Subject,Services,NotBefore,NotAfter

Важный момент: импорт PFX ещё не означает, что Exchange начал использовать новый сертификат. Сразу после импорта у нового сертификата могут быть одни services, а IIS всё ещё будет работать со старым.

4. Назначение сертификата службам Exchange

После проверки выбранного сертификата назначьте его как минимум для IIS и SMTP:

$thumbprint = '<NEW_CERTIFICATE_THUMBPRINT>'
Enable-ExchangeCertificate `
  -Thumbprint $thumbprint `
  -Services IIS,SMTP

Exchange может спросить, нужно ли заменить default SMTP certificate. Выбирайте A только в утверждённом окне работ и после проверки отпечатка сертификата.

Проверка:

Get-ExchangeCertificate -Thumbprint $thumbprint `
  | Format-List Thumbprint,Subject,Services,NotAfter

Ожидаемый результат: новый сертификат обслуживает IIS и SMTP.

5. Проверка IIS binding

На Exchange откройте IIS Manager:

Sites
  -> Default Web Site
    -> Bindings...
      -> https :443

Проверьте выбранный SSL certificate. Если там остался старый сертификат, вручную выберите новый.

Затем выполните:

iisreset

После перезапуска проверьте OWA изнутри. Не переходите к TMG, пока IIS не отвечает штатно.

6. Перенос сертификата на Forefront TMG

На пограничном сервере импортируйте тот же PFX через Certificates (Local Computer) в:

Personal
  -> Certificates

Проверьте наличие приватного ключа.

В Forefront Threat Management Gateway откройте Firewall Policy. В текущей схеме Exchange опубликован тремя правилами:

Publish Exchange ActiveSync
Publish Exchange Autodiscovery
Publish Exchange OWA

Для каждого правила проверьте:

Rule Properties
  -> Listener
    -> Properties
      -> Certificates

Если все правила используют один Web Listener, сертификат достаточно заменить на Listener. Если Listener несколько, каждый нужно проверить отдельно.

После изменения нажмите Apply и дождитесь завершения применения конфигурации TMG.

7. Внешняя проверка

Проверка из локальной сети недостаточна. Запрос должен пройти через внешний TLS-контур и TMG Web Listener.

Откройте OWA с внешней стороны и посмотрите информацию о сертификате:

https://<public-owa-domain>/owa/

Проверьте:

  • Issued To соответствует нужному имени;
  • Issued By - Let’s Encrypt;
  • дата выпуска новая;
  • дата окончания обновилась;
  • браузер не показывает старый сертификат;
  • OWA открывается;
  • Autodiscover и ActiveSync не получили побочные ошибки.
External client
      |
      v
TLS certificate on TMG Web Listener
      |
      v
TMG publishing rule
      |
      v
Exchange IIS / OWA

Что делать, если снаружи всё ещё старый сертификат

Разделяйте диагностику по слоям:

  1. На Exchange новый сертификат импортирован?
  2. Новый сертификат назначен для IIS?
  3. IIS binding использует новый сертификат?
  4. PFX с приватным ключом импортирован на TMG?
  5. Web Listener использует новый сертификат?
  6. Нажат Apply и конфигурация TMG завершила применение?
  7. Проверка выполняется действительно извне, а не из кэшированной внутренней точки?

Чаще всего проблема находится не в выпуске сертификата, а в том, что новый сертификат импортировали, но не переключили на одном из последующих уровней.

План отката

Старый сертификат не удаляйте сразу после переключения.

Если после обновления OWA или другой сервис работает неправильно:

  1. верните старый сертификат на TMG Web Listener;
  2. нажмите Apply;
  3. верните старый IIS binding на Exchange;
  4. при необходимости верните старый сертификат службами Exchange;
  5. проверьте внешний OWA и клиентские сценарии;
  6. сохраните логи и симптомы для повторной диагностики.

Rollback должен возвращать рабочую конфигурацию, а не просто удалять новый сертификат.

Типичные ошибки

No certificate generated

Проверить параметры renewal и повторить через force, no cache.

HTTP-01 challenge не проходит

Проверить webroot, доступность challenge-файла через HTTP и то, что запрос не перехватывается неправильным правилом публикации.

Новый сертификат есть, но Exchange использует старый

Проверить Services и выполнить Enable-ExchangeCertificate.

Внутри новый, снаружи старый

Проверить Web Listener TMG и правило, через которое реально приходит внешний запрос.

Ошибка доверия к цепочке

Проверить intermediate CA. Leaf-сертификат не нужно помещать в Trusted Root.

Итоговая схема

+----------------+
| win-acme       |
| HTTP-01        |
+--------+-------+
         |
         | new certificate
         v
+----------------+
| PFX export     |
| private key    |
+----+-------+---+
     |       |
     v       v
+--------+ +---------+
|Exchange| |   TMG   |
|IIS SMTP| |Listener |
+----+---+ +----+----+
     |          |
     +----+-----+
          |
          v
  External HTTPS check

Что стоит автоматизировать дальше

Текущая процедура рабочая, но частично ручная. Следующий аккуратный этап:

  • настроить renewal так, чтобы сертификат сразу попадал в LocalMachine\\My;
  • автоматизировать назначение нового сертификата на Exchange services;
  • оставить ручной контроль Web Listener на старом TMG;
  • хранить PFX и секрет отдельно от проекта;
  • добавить внешний мониторинг срока действия сертификата;
  • перед следующим боевым renewal выполнить тестовый прогон.

Главный вывод простой: сертификат нужно проверять не там, где он выпустился, а в конечной точке, которую видит внешний клиент.