☰

sendmail: сервер показывает сбои из-за плохого клиентского сертификата

tag-icon • tag-icon ssl email sendmail
sendmail: сервер показывает сбои из-за плохого клиентского сертификата

Мой сервер sendmail (FreeBSD, скомпилированный с OpenSSL) отказывается согласовывать TLS с одним конкретным набором клиентов.

Сообщения журнала выглядят следующим образом:

sm-mta[92474]: STARTTLS=сервер, ошибка: принять не удалось=-1, причина=оповещение sslv3 о плохом сертификате, SSL_error=1, errno=0, повтор=-1, relay=xx.example.com [XX.XX.XX.XX]

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

Два вопроса, ответ на любой из которых был бы полезен:

  1. Как это диагностировать? В частности, можно ли получить копию плохого сертификата из среды sendmail?
  2. Могу ли я обновить конфигурацию sendmail, чтобы сообщить клиентам не предоставлять сертификат или сообщить sendmail принять поддельный клиентский сертификат?

Спасибо!

EDIT: Я нашел проблему здесь, которая заключалась в том, что сертификат моего сервера не соответствовал записи DANE TLSA моего сервера. Просмотр декодирования транзакции Wireshark показал, что провайдер (Comcast) получал мой действительный сертификат, но все равно отклонял его, и оказалось, что запись TLSA не была синхронизирована. Похоже, Comcast может быть одним из немногих отправителей электронной почты в Интернете, который отказывается отправлять после сбоя проверки DANE.

решение1

Вы можете использовать OpenSSL для запроса удаленного сервера. Например, чтобы увидеть сертификат на одном из почтовых серверов Google:

echo quit | openssl s_client -connect aspmx.l.google.com:25 -starttls smtp

должно быть что-то похожее на:

CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = mx.google.com
verify return:1
---
Certificate chain
 0 s:CN = mx.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG9DCCBdygAwIBAgIQdfcJTB0GgVsKbOXnm+OJmTANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzETMBEGA1UEAxMKR1RTIENBIDFDMzAeFw0yMzA0MDMwODIzNTRaFw0yMzA2MjYw
ODIzNTNaMBgxFjAUBgNVBAMTDW14Lmdvb2dsZS5jb20wWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAASHHjjoYwgwyC6/DYMfRij2+kZyiywt8lVwAyy90RasYt3tDcmD
kqUhLf8Mv527u0akQVq00cpcRg9W1tFgSKl9o4IE1TCCBNEwDgYDVR0PAQH/BAQD
AgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYE
FBneGLCbQL6PsUCbmin+e8j25tSYMB8GA1UdIwQYMBaAFIp0f6+Fze6VzT2c0OJG
FPNxNR0nMGoGCCsGAQUFBwEBBF4wXDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au
cGtpLmdvb2cvZ3RzMWMzMDEGCCsGAQUFBzAChiVodHRwOi8vcGtpLmdvb2cvcmVw
by9jZXJ0cy9ndHMxYzMuZGVyMIIChgYDVR0RBIICfTCCAnmCDW14Lmdvb2dsZS5j
b22CD3NtdHAuZ29vZ2xlLmNvbYISYXNwbXgubC5nb29nbGUuY29tghdhbHQxLmFz
cG14LmwuZ29vZ2xlLmNvbYIXYWx0Mi5hc3BteC5sLmdvb2dsZS5jb22CF2FsdDMu
YXNwbXgubC5nb29nbGUuY29tghdhbHQ0LmFzcG14LmwuZ29vZ2xlLmNvbYIaZ21h
aWwtc210cC1pbi5sLmdvb2dsZS5jb22CH2FsdDEuZ21haWwtc210cC1pbi5sLmdv
b2dsZS5jb22CH2FsdDIuZ21haWwtc210cC1pbi5sLmdvb2dsZS5jb22CH2FsdDMu
Z21haWwtc210cC1pbi5sLmdvb2dsZS5jb22CH2FsdDQuZ21haWwtc210cC1pbi5s
Lmdvb2dsZS5jb22CGGdtci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0MS5nbXIt
c210cC1pbi5sLmdvb2dsZS5jb22CHWFsdDIuZ21yLXNtdHAtaW4ubC5nb29nbGUu
Y29tgh1hbHQzLmdtci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0NC5nbXItc210
cC1pbi5sLmdvb2dsZS5jb22CDW14MS5zbXRwLmdvb2eCDW14Mi5zbXRwLmdvb2eC
DW14My5zbXRwLmdvb2eCDW14NC5zbXRwLmdvb2eCFWFzcG14Mi5nb29nbGVtYWls
LmNvbYIVYXNwbXgzLmdvb2dsZW1haWwuY29tghVhc3BteDQuZ29vZ2xlbWFpbC5j
b22CFWFzcG14NS5nb29nbGVtYWlsLmNvbYIRZ21yLW14Lmdvb2dsZS5jb20wIQYD
VR0gBBowGDAIBgZngQwBAgEwDAYKKwYBBAHWeQIFAzA8BgNVHR8ENTAzMDGgL6At
hitodHRwOi8vY3Jscy5wa2kuZ29vZy9ndHMxYzMvUU92SjBOMXNUMkEuY3JsMIIB
AwYKKwYBBAHWeQIEAgSB9ASB8QDvAHUAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvS
K8E6V6NS61IAAAGHRm4lhwAABAMARjBEAiAbFYSOoxVgUmcJ//sPa+hYjV4DrVfp
I3BK/Z6oBCwARQIgKKWKSA17g7eWZarLagY5oG4P+UxzBZd5uJHM+nj379IAdgDo
PtDaPvUGNTLnVyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYdGbiVNAAAEAwBHMEUC
IQDINMfMYnK9vpptQYj9Ve6EOYa26GZV2TaM4Sw7J30ZkwIgSB8GtydIcaC+2pgJ
EifKh9ZkJvY/o6L24amB1gFUxIswDQYJKoZIhvcNAQELBQADggEBAAnbG+WzOmkA
FqJGasrOMQGIcLwfHSwEAeAjuQOCVxZ8I0e3bKV3+4jLMDEXz9SkhTCXq57p9pWu
YorP5fPlR9+5Z2cCCCbFU5sHXRsZ3olFqVIbTqtN0pxAOFSKah85KnEq2cMSeQ6j
fhhFT41nLvd+QotH5vYh0IUnSgEOGnOxNfgc/Ixk75ENZ7GBZopWzIQ75J+X8RE6
j/SC42wunfCeR6xywhlpDg70mwjLP6QslX/JHfsR6pg+MLyTgmrTincbWeStauvN
G2JZkth9MeorZoTmyx+vooeKQgIV8PKRs5Llc+lSjA4b9wlJNHA9hMd5mBRZL291
oMYlrLxMli8=
-----END CERTIFICATE-----
subject=CN = mx.google.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5201 bytes and written 423 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 SMTPUTF8
DONE

Вы можете добавить -showcerts, чтобы получить все сертификаты в цепочке.

решение2

Мой общий подход к вопросу проверки сертификатов таков:

  1. Сделайте сетевой захват с помощью tcpdump или аналогичного
  2. Откройте захват в Wireshark и щелкните правой кнопкой мыши поПРЕДУПРЕЖДЕНИЕ SSL/TLSпакет и выбрал Follow->TCP stream
  3. Проверьте сертификат X509:
    • Даты (находится ли текущая дата между датой выдачи и датой истечения срока действия?)
    • Тема (имя хоста, используемое клиентом, совпадает с полем CN=?)
    • Альтернативное имя субъекта (похоже на Тема)
    • Ограничения
    • Промежуточные сертификаты (все ли промежуточные сертификаты представлены после сертификата хоста? Действительны ли они?)

Обычно причиной такой проблемы является отсутствие промежуточного сертификата (некоторые клиенты не проверяют сертификат вашего сервера).

решение3

Оказалось, что ключевым моментом здесь был захват и анализ согласования TLS в Wireshark, и это привело меня к обнаружению того, что интернет-провайдер (Comcast) отклонял мой сертификат домена, несмотря на то, что почти все остальные отправители в Интернете принимали его.

Дальнейшее расследование показало, что запись TLSA для рассматриваемого почтового сервера устарела, и что Comcast отклонил сертификат из-за несоответствия TLSA.

К сожалению, механизмы ошибок, доступные в согласовании TLS, не предоставляют отправителю возможности сообщить получателю, почему сертификат был отклонен. Возможно, TLS 1.4 может определить конкретное оповещение о несоответствии сертификата DANE.

Связанный контент