Магия .NET или “Да ну нафиг ваши CRL”

175px-Answer_to_Life Всем привет! Вот о чем мне сегодня хотелось бы Вам поведать: все прекрасно знают (кто не знает, ссылка будет), что при установке обновлений на Exchange Server, начиная с версии 2007, разработчик настоятельно рекомендует открыть серверам доступ к Certificate Revocation Lists, в простонародье именуемым CRL (церээль, сэрээл, срл), дабы избежать проблем при дальнейшем старте служб. Почему это происходит при установке обновлений, и не только обновлений ;), зачем это нам всем нужно, ну и Answer to the Ultimate Question of Life, the Universe, and Everything – как с этим бороться :). Все под кат!

Начнем с теории. При установке обновлений завязанных на .NET, Microsoft ввел модную утилиту, которую назвал Native Image Generator (NGen.exe). Эта утилита производит сборку машинного процессор-зависимого кода в момент установки. Зачем? А затем, что работа управляемого кода хранящегося в кэше операционной системы на диске, куда как быстрее, чем компиляция  на лету (Just-In-Time, JIT-compile), к тому же при его запуске не происходит проверки кода на безопасность (Type-Safety Verification, “А в те ли адреса памяти он полез, куда ему положено?”). И к управляемому коду как раз относятся многие сервисы Exchange Server. Они то обычно и не стартуют :)

Установили, собрали управляемый код. Запускаем. Начиная с Microsoft .NET Framework 2.0, а как помнится именно эта версия необходима для установки MS Exchange 2007, в момент загрузки управляемого кода вызывается функция CryptoAPI, проверяющая, а действительно ли это тот самый код, собранный из пакетов, предоставленных компанией-производителем, или это новомодная зараза, которую админ Вася положил на сетевой ресурс, который он зачем-то организовал на Exchange Server. вместе с последним сезоном Sailormoon. Для этого CryptoAPI проверяет т.н. Authenticode Signature (попросту подпись кода сертификатом), которая генерится производителем.

Проверка прошла. После этого CriptoAPI ОБЯЗАТЕЛЬНО проверит сертификат, которым подписан код, на предмет его валидности для производителя. Опять же простыми словами – не отозван ли он вендором? Как это делается? А просто. Происходит запрос к магическому адресу: http://crl.microsoft.com/pki/crl/products/CSPCA.crl по протоколу HTTP, откуда система и загружает список отозванных сертификатов, в которых, затем, и ищет тот самый, нужный. Ну просто очень естественно, что для этого необходимо подключение к Интернет.

image

Если CryptoAPI получает CRL-файл, не находит в нем сертификат, происходит запуск кода. Служба запустилась.

Второй, неблагоприятный случай: доступа к Интернет нет, и исходящие HTTP-запросы отвергаются файрволом. Сообщение об ошибке CriptoAPI не получает. И ждет. А вот такая вот долгая задержка приводит к тому, что Service Control Manager начинает подозрительно коситься на слишком долгое время старта службы. И как только время старта достигает порогового значения – SCM генерирует сообщение об ошибке. Сервис, мол, куд нот старт. И все тут. Та же самая ситуация повторяется при невозможности разрешить этот URL.

И в AppLogs появляется куча нехороших событий. Таких:

Event Type: Error
Event Source: Service Control Manager
Event ID: 7000
Description: The Microsoft Exchange EdgeSync service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Event Type: Information
Event Source: Microsoft Exchange Server
Event ID: 5001
Description: Bucket 77004151, bucket table 5, EventType e12, P1 c-rtl-amd64, P2 08.00.0733.000, P3 msexchangetransport, P4 unknown, P5 unknown, P6 s.serviceprocess.timeoutexception, P7 0, P8 08.00.0733.000, P9 NIL, P10 NIL.

Event Type: Error
Event Source: Service Control Manager
Event ID: 7000
Description: The Microsoft Exchange Transport Log Search service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Event Type: Error
Event Source: Service Control Manager
Event ID: 7009
Description: Timeout (30000 milliseconds) waiting for the Microsoft Exchange Transport Log Search service to connect.

The following events are logged in the Application log:

Event Type: Error
Event Source: MSExchange Common
Event Category: General
Event ID: 4999
Description:
Watson report about to be sent to dw20.exe for process id: 1448, with parameters: E12, c-RTL-AMD64, 08.00.0733.000, MSExchangeTransport, unknown, unknown, S.ServiceProcess.TimeoutException, 0, 08.00.0733.000

Event Type: Error
Event Source: Microsoft Exchange Server
Event ID: 5000
Description:
EventType e12, P1 c-rtl-amd64, P2 08.00.0733.000, P3 msexchangetransport, P4 unknown, P5 unknown, P6 s.serviceprocess.timeoutexception, P7 0, P8 08.00.0733.000, P9 NIL, P10 NIL.

Методы борьбы с этой бякой: (бяка не сама проверка, а невозможность ее выполнения, и, следовательно последствия)

1. Дать доступ к CRL. На мой взгляд один из самых правильных вариантов. Если не сказать правильный.

2. Избежать отправки сетевых пакетов “вникуда”, как говорят братцы-мириканцы “into a black hole”. Как я упомянул выше, отбой проверки по таймауту, следствие отсутствия “понятных” ответов. Если маршрутизатор пришлет внятный ICMP-пакет в ответ на запрос, например “no route to host” или что-то подобное, проверка прервется с ошибкой, вы получите предупреждение в AppLog, но служба запустится! SCM не успеет ее выбить по тому же таймауту. У этого решения две вариации:

Вариация А: Добавить запись в файл host сервера вида crl.microsoft.com 127.0.0.1. Получите правильный ответ. Файл host, если кто забыл, тут %systemroot%\system32\drivers\etc\host

Вариация В: отключить сетевую карту в момент старта. Бред? Нет. Есть случаи, когда помогает. О них чуть ниже.

3. использовать специальный переключатель в конфигурационном файле сервиса, отключающий проверку CRL. Помогает. Но не всегда. Файлы конфигурации сервисов находятся в каталоге Program Files\Microsoft\Exchange\bin. Они имеют имена вида <FullServiceFilenam.config>, например Microsoft.Exchange.Transport.exe.config. Редактируются блокнотом. Просто добавьте в раздел <configuration>

 
<runtime>
           
           <generatePublisherEvidence enabled="false" />
</runtime>

Если тэги <runtime> уже присутствуют, вставьте ключ внутрь поля между тэгами.

Для некоторых служб файлы конфигураций нужно создавать. А именно для:

  • Microsoft.Exchange.AntispamUpdateSvc.exe
  • MsExchangeFDS.exe
  • MSExchangeTransport.exe
  • Для сервисов POP3 и IMAP конфигурационные файлы будут лежать в каталоге Program Files\Microsoft\Exchange\ClientAccess

    4. Отключение проверки на уровне системы. Ну это уже вообще никуда не годиться :)

-Откройте в IE  Tools, Internet Options, Advanced

— В панели Security уберите флажок из чекбокса Check for  publisher’scertificate revocation

— Нажмите OK, и закройте Internet Options.

А теперь новогодние сюрпризы

Сюрприз номер раз:

Мы тут как-то привыкли, что данные проблемы возникают только при установке Update Rollup для Exchange. Разработчики в каждой статье, посвященной UR, публикуют инструкции, как сделать все красиво, мы на них благополучно забиваем, и все идет по кругу. А вот для меня лично стало откровением, когда один из серверов клиента вдруг отвалился без причин. Службы не стартуют, UR не ставились. Оказалось причиной послужили обновления .NET Framework. Симптомы один в один, решение тоже :)

Сюрприз номер два:

Установка Exchange Server Load Generator, в простонародье LoadGen. Установщик вылетает с ошибкой:

image

При нажатии на кнопку ОК, происходит, разумеется, откат изменений. В блоге Brian Gibson, нашел описание проблемы. Не стартует Microsoft Exchange Load Generator Remote Agent. Он нашел решение в виде отключения сетевого интерфейса в момент инсталляции. А вот поправить конфигурационный файл несозданной еще службы у вас не получится :) Поэтому два вывода: отключение сетевого интерфейса во время инсталляции не такой уж и бред в некоторых случаях, и отключение проверки в конфиг-файлах спасает не всегда :)

Вот вроде бы и все, что хотелось Вам рассказать по этому поводу. Жду замечаний и предложений ниже. Всех с наступающим новым годом!

А как же выводы? Выводы таковы:

1. Во-первых, все выводы сделанные из этого поста – вещь сугубо персональная. Ниже мои :)

2. По возможности включайте доступ к CRL для серверов Exchange. Это хорошо и православно.

3. Если по каким-либо причинам сделать этого нельзя – поправьте файлик host. Это нанесет наименьший вред безопасности системы.

4. Редактирование файлов конфигурации дело муторное, и не всегда помогает.

5. Отключение проверки на уровне системы – зло. Не надо этого делать.

6. Ну а ответ на Самый Главный Вопрос Жизни, Вселенной И Всего Такого остается неизменным. 42!

Реклама
Магия .NET или “Да ну нафиг ваши CRL”

Магия .NET или “Да ну нафиг ваши CRL”: 3 комментария

  1. Stanky:

    4-й способ — не системная настройка, а в контексте текущего пользователя ;) . То есть, она может помочь при установке, но никак не при работе от системной учётной записи.

  2. Хорошая статья. Действительно было интересно почитать. Не часто такое и встречается та.Наверное стоит подписаться на ваше RSS

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s