Exchange 2007, в отличие от 2003, поставляется с самоподписанным сертификатом. Я предполагал, что он для IIS, однако, он используется ещё для каких-то целей. (попробую изложить свои мысли).
Самоподписанные (самим сервером) сертификаты - зло. Так что первое, что следует сделать для работы с сервером через IIS - выписать ему нормальный сертификат (хоть и своим CA).
Я так и сделал, но удалил при этом его оригинальный самоподписанный сертификат.
Через некоторое время в эвентлоге начало появляться (точнее, я заметил):
Event Type: Error
Event Source: MSExchangeTransport
Event Category: TransportService
Event ID: 12014
Date: 23.10.2008
Time: 20:15:34
User: N/A
Computer: EX-SRV-TEST
Description:
Microsoft Exchange couldn't find a certificate that contains the domain name ex-srv-test.domain.ru in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Intra-Organization SMTP Send Connector with a FQDN parameter of ex-srv-test.domain.ru. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Попытка выполнить эту операцию пишет следующее:
cmdlet Enable-ExchangeCertificate at command pipeline position 1
Supply values for the following parameters:
Thumbprint: _
Типа, "дайте сертификат, ручками". Что есть зло.
Чуть ранее я повесил сертификат на FQDN-имя, отличное от доменного имени компьютера. Я подумал, что надо выписать сертификат туда. Я выписал сертификат ex-srv-test.domain.ru (как - в следующих сериях).
Однако, ExchangeTransport пришёл к следующему выводу:
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: TransportService
Event ID: 12024
Date: 23.10.2008
Time: 20:19:14
User: N/A
Computer: EX-SRV-TEST
Description:
Microsoft Exchange could not load the certificate with thumbprint of A9BA84779016C45983A7E417BDDCA95B95C5146C from the personal store on the local computer. This certificate was configured for authentication with other Exchange servers. Mail flow to other Exchange servers could be affected by this error. If the certificate with this thumbprint still exists in the personal store, run Enable-ExchangeCertificate A9BA84779016C45983A7E417BDDCA95B95C5146C -services SMTP to resolve the issue. If the certificate does not exist in the personal store, restore it from backup by using the Import-ExchangeCertificate cmdlet, or create a new certificate for the FQDN or the server enabled for SMTP by running the following command: New-ExchangeCertificate -DomainName serverfqdn -Services SMTP. Meanwhile, an ephemeral, self-signed certificate with thumbprint 57CBAAD8E7D7F5865ADE9265B13E31C7879EE0E1 is being used.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Я послушно это сделал, но мне ответили:
Enable-ExchangeCertificate : The certificate with thumbprint A9BA84779016C45983A7E417BDDCA95B95C5146C was not found.
At line:1 char:27
+ Enable-ExchangeCertificate <<<< A9BA84779016C45983A7E417BDDCA95B95C5146C -services SMTP
Что означает, что кто-то из них (шелл, Exchange Transport или Exchange Services) не может получить доступ к сертификатам. Почему? Потому, что сертификаты не установлены в их личное (personal).
Пробуем: экспортируем сертификат из IIS (ну или из local machine account) (вместе с секретным ключом!)
Заметим, что у Exchange Transport оно присутствует! Однако, его Thumbprint не тот, который нам предлагают пофиксить (видимо, пофиксить предлагают тот самый "самоподписанный", который я удалил). Другими словами, "not found" касается не отсутствия сертификата, а того, что нужно просто указывать ДРУГОЙ сертификат.
копируем thumbprint от "нашего" сертификата: f256e80ecd805a629f10678df28efff032ab8633 (для старательных непонимающих, дочитавших до этого места - у вас это число будет другим).
Делаем команду
Enable-ExchangeCertificate f256e80ecd805a629f10678df28efff032ab8633 -services SMTP
Видим:
Overwrite existing default SMTP certificate, 'A9BA84779016C45983A7E417BDDCA95B95C5146C' (expires 15.10.2009 17:10:35),
with certificate 'F256E80ECD805A629F10678DF28EFFF032AB8633' (expires 23.10.2009 19:55:05)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
(последний 'y' напечатал я, и авторские права на него принадлежат мне, вы не имеете права отвечать на этот вопрос 'y' без моего письменного разрешения на неэксклюзивное право воспроизведения объекта авторского права).
В эвентлоге:
Event Type: Information
Event Source: MSExchangeTransport
(скип)
The new transport server configuration has been read and components have been notified.
Перегружаемся... (это дооолго, так что пощу пока без итоговых результатов).
Заодно совет о решении проблемы быстрой перезагрузки Эксчейнжа и DC: выключить эксчейнж и IIS (важно!) до ребута - судя по петри, проблема в том, что AD выключается на DC раньше эксчейнжа, и тот ждёт таймаута до самоубийства. Этот совет помогает на шатдауне, но не ускоряет (по понятным причинам) загрузки. О методах акселерации загрузки буду думать (вероятнее всего, надо прописать dependence у сервисов).
Итог: перестало ругаться. Работает или нет, сейчас проверю.
PS Среди не решённых пока что проблем - проблема с незапуском при перезагрузке Information Storage (и паникующим в виндовом стиле (т.е. не kernel panic, а активная ругань в event log) от подобного System Attendant).
P.S. ООПС, это не оно. Увы. Ошибка снова появляется. Думаю дальше.