☰

sendmail: 잘못된 클라이언트 인증서로 인해 서버에 오류가 표시됩니다.

tag-icon • tag-icon ssl email sendmail
sendmail: 잘못된 클라이언트 인증서로 인해 서버에 오류가 표시됩니다.

내 sendmail 서버(OpenSSL에 대해 컴파일된 FreeBSD)가 특정 클라이언트 집합과 TLS 협상을 거부합니다.

로그 메시지는 다음과 같습니다.

sm-mta[92474]: STARTTLS=서버, 오류: 승인 실패=-1, 이유=sslv3 잘못된 인증서 경고, SSL_error=1, errno=0, 재시도=-1, Relay=xx.example.com [XX.XX .XX.XX]

잘 알려진 ISP의 메일 인프라에서 발생한 이러한 오류를 제외하면 모든 것이 잘 작동합니다. 서버 자체의 인증서가 최신이고 유효합니다.

두 가지 질문 중 하나에 대한 답변이 도움이 될 것입니다.

  1. 어떻게 진단할 수 있나요? 특히 sendmail 환경 내에서 잘못된 인증서의 복사본을 얻을 수 있나요?
  2. 클라이언트에게 인증서를 제공하지 않도록 지시하거나, sendmail이 가짜 클라이언트 인증서를 수락하도록 지시하도록 내 sendmail 구성을 업데이트할 수 있습니까?

감사해요!

편집: 여기서 문제를 발견했습니다. 내 서버의 인증서가 내 서버의 DANE TLSA 레코드와 일치하지 않는다는 것입니다. 트랜잭션의 Wireshark 디코드를 살펴보면 ISP(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

여기서는 Wireshark에서 TLS 협상을 캡처하고 분석하는 것이 핵심이라는 것이 밝혀졌으며, 이를 통해 인터넷상의 거의 모든 발신자가 도메인 인증서를 수락하고 있음에도 불구하고 ISP(Comcast)가 내 도메인 인증서를 거부하고 있다는 사실을 알게 되었습니다.

추가 조사 결과 문제의 메일 서버에 대한 TLSA 레코드가 오래되었으며 Comcast가 TLSA 불일치로 인해 인증서를 거부하고 있는 것으로 나타났습니다.

불행하게도 TLS 협상에서 사용할 수 있는 오류 메커니즘은 발신자가 수신자에게 인증서가 거부된 이유를 알려주는 방법을 제공하지 않습니다. 아마도 TLS 1.4는 DANE 인증서 불일치에 대한 특정 경고를 정의할 수 있습니다.

관련 정보