Сервер Exchange 2016 отклоняет сертификат по истечении срока действия
У нас есть электронные письма, отправленные с использованием TLS с веб-сервера Windows 2012R2 (не присоединенного к домену) в нашей DMZ на наш внутренний сервер Exchange 2016 (также работающий в Windows 2012R2). Это работало нормально примерно месяц назад, когда они перестали приходить (мы только сейчас это заметили, потому что электронные письма очень редкие). Я принудительно отправил тестовое письмо, и когда я смотрю журналы протокола транспортных ролей, я вижу следующее:
2020-06-24 11:02:33.524,
MAILSERVER\Client Frontend MAILSERVER,
0102030405060708,
6,
192.168.1.44:587,
192.168.2.3:64961,
*,
" CN=*.example.com CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB
0102030405060708090A0B0C0D0E0F10
0102030405060708090A0B0C0D0E0F1011121314
2020-03-17T19:00:00.000Z
2021-03-18T18:59:59.000Z
*.example.com;example.com",
Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names
2020-06-24 11:02:33.540,
MAILSERVER\Client Frontend MAILSERVER,
0102030405060708,
7,
192.168.1.44:587,
192.168.2.3:64961,
*,
,
TLS negotiation failed with error CertExpired
Вы можете видеть, что срок действия сертификата - с 17 марта 2020 г. по 18 марта 2021 г. На стороне клиента отображается следующий журнал ошибок:
SERVER -> CLIENT: 220 mailserver.example.com Microsoft ESMTP MAIL Service ready at Wed, 24 Jun 2020 11:02:32 -0500
CLIENT -> SERVER: EHLO www.example.com
250-SIZE 36700160
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
CLIENT -> SERVER: STARTTLS
SERVER -> CLIENT: 220 2.0.0 SMTP server ready
Connection failed. Error #2: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed [E:\...\class-smtp.php line 374]SMTP Error: Could not connect to SMTP host.
CLIENT -> SERVER: QUIT
SERVER -> CLIENT: SMTP ERROR: QUIT command failed: Connection: closedSMTP Error: Could not connect to SMTP host.
В журнале событий на почтовом сервере отображается следующее событие:
A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 45.
- System
- Provider
[ Name] Schannel
[ Guid] {1F678132-5938-4686-9FDC-C8FF68F15C85}
EventID 36887
Version 0
Level 2
Task 0
Opcode 0
Keywords 0x8000000000000000
- TimeCreated
[ SystemTime] 2020-06-24 11:02:33.540386500
EventRecordID 417754
Correlation
- Execution
[ ProcessID] 484
[ ThreadID] 1552
Channel System
Computer mailserver.example.com
- Security
[ UserID] S-1-5-18
- EventData
AlertDesc 45
Но, опять же, это событие просто указывает на просроченный сертификат.
Любые идеи относительно того, почему Exchange считает этот сертификат истекший? Я проверил дату и время на обеих машинах, и они верны с точностью до секунды. Спасибо!
Итак, @ dave_thompson_085 был прав, поскольку проблема заключалась в том, что срок действия сертификата AddTrust, находившегося в корне моей цепочки сертификатов, истек. После устранения проблемы на сервере Exchange (путем воссоздания файла сертификата PFX без корня AddTrust и его повторного импорта) я все еще получал ту же ошибку. Я установил второй клиент, попытался отправить электронное письмо и обнаружил, что он работает правильно, поэтому я знал, что проблема связана с клиентским компьютером. Используя WireShark на сервере Exchange, я наблюдал за трафиком TLS между двумя машинами и мог видеть, что сервер Exchange отправляет сертификат и его непосредственный родительский сертификат (сертификат Sectigo CA), а затем клиент отклоняет его как просроченный (хотя оба сертификаты были действительны). Я предположил, что клиент должен проверять полученные сертификаты и каким-то образом обнаруживать, что они связаны с истекшим корнем AddTrust. Электронные письма отправлялись PHPMailer, поэтому я просмотрел настройки PHP и обнаружил, что у него есть пакет CA, который он использует (поскольку PHP, по-видимому, не может использовать хранилище сертификатов Windows). В этом пакете CA я обнаружил и удалил сертификат AddTrust, что устранило проблему.
В вашей информации не отображаются используемые сертификаты цепочки - попробуйте openssl s_client -connect $ host: $ port -servername $ host -showcerts и запустить каждый из полученных блоков PEM через openssl x509 -text , или, если вы предпочитаете, поместить их в (отдельные) файлы и дважды щелкнуть мышью. (Если OpenSSL 1.1.1 вам больше не нужен -servername $ host .)
Многие центры сертификации Comodo ^ WSectigo использовали мост USERTrust-to-AddTrust, срок действия которого истек 30 мая ; см. https://security.stackexchange.com/questions/232978/how-to-fully-view-cross-signed-certificate-signatures и https://stackoverflow.com/questions/ 62107431 / curl-error-60-ssl-certificate-problem-certificate-has-expired и ссылка на оба из этих https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust- Внешний CA-Root-Expiring-May-30-2020 . В частности, единственным зарегистрированным сертификатом прозрачности для Sectigo RSA DV-сервера является https://crt.sh/?id=924467861 в USERTrust RSA, который имеет четыре известных сертификата, перечисленных на https: // crt.sh/?caid=1167, поэтому, если вы используете AddTrust one # 4860286, вы можете увидеть, что notAfter был 30.05.2020 - примерно месяц назад.
Это именно то, что joeqwerty сказал выше, проверяли ли вы службу SMTP, назначенную сертификату или привязанную к коннектору?
Вы можете запустить команду ниже, чтобы проверить:
Get-ReceiveConnector | FL Identity,RemoteIPRanges,PermissionGroups,Auth*,TlsCertificateName
Подробнее: Настройка имени сертификата TLS для соединителей приема сервера Exchange