☰

sendmail: servidor mostra falhas devido a certificado de cliente incorreto

tag-icon • tag-icon ssl email sendmail
sendmail: servidor mostra falhas devido a certificado de cliente incorreto

Meu servidor sendmail (FreeBSD, compilado com OpenSSL) está se recusando a negociar TLS com um conjunto específico de clientes.

As mensagens de log são assim:

sm-mta [92474]: STARTTLS = servidor, erro: falha na aceitação = -1, motivo = certificado incorreto de alerta sslv3, SSL_error = 1, errno = 0, nova tentativa = -1, relé = xx.example.com [XX.XX .XX.XX]

Tirando essas falhas, que se originam na infraestrutura de correio de um ISP bem conhecido, tudo está funcionando perfeitamente; o certificado no próprio servidor está atualizado e válido.

Duas perguntas, uma resposta para qualquer uma delas seria útil:

  1. Como posso diagnosticar isso? Em particular, posso obter uma cópia do certificado inválido no ambiente sendmail?
  2. Posso atualizar minha configuração do sendmail para dizer aos clientes para não fornecerem um certificado ou para dizer ao sendmail para aceitar um certificado de cliente falso?

Obrigado!

EDIT: Encontrei o problema aqui: o certificado do meu servidor não correspondia ao registro DANE TLSA do meu servidor. Observar uma decodificação da transação pelo Wireshark mostrou que o ISP (Comcast) estava recebendo meu certificado válido, mas o rejeitou mesmo assim, e descobriu-se que o registro TLSA não estava sincronizado. Parece que a Comcast pode ser um dos poucos remetentes de e-mail na Internet que se recusa a enviar após uma falha na verificação do DANE.

Responder1

Você poderia usar OpenSSL para consultar o servidor remoto. Por exemplo, para ver o certificado em um dos servidores de e-mail do Google:

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

deve mostrar algo semelhante a:

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

Você pode adicionar -showcertspara obter todos os certificados da cadeia.

Responder2

Minha maneira genérica de abordar o problema de validação de certificado é:

  1. Faça uma captura de rede com tcpdump ou similar
  2. Abra a captura no Wireshark e clique com o botão direito noALERTA SSL/TLSpacote e escolheu Follow->TCP stream
  3. Verifique o certificado X509:
    • Datas (a data atual está entre a data de emissão e a data de validade?)
    • Assunto (o nome do host usado pelo cliente é igual ao campo CN=?)
    • Nome alternativo do assunto (semelhante ao assunto)
    • Restrições
    • Certificados intermediários (todos os certificados intermediários são apresentados após o certificado do host? Eles são válidos?)

Geralmente é falta de um certificado intermediário que dá esse tipo de problema (alguns clientes não validam o certificado do seu servidor).

Responder3

Acontece que capturar e analisar a negociação TLS no Wireshark era a chave aqui, e isso me levou a descobrir que o ISP (Comcast) estava rejeitando meu certificado de domínio, apesar do fato de quase todos os outros remetentes na Internet o aceitarem.

Uma investigação mais aprofundada descobriu que o registro TLSA do servidor de e-mail em questão estava desatualizado e que a Comcast estava rejeitando o certificado devido a uma incompatibilidade de TLSA.

Infelizmente, os mecanismos de erro disponíveis na negociação TLS não fornecem uma maneira de o remetente informar ao destinatário por que o certificado foi rejeitado. Talvez o TLS 1.4 possa definir um alerta específico para incompatibilidade de certificado DANE.

informação relacionada