☰

sendmail: el servidor muestra fallas debido a un certificado de cliente incorrecto

tag-icon • tag-icon ssl email sendmail
sendmail: el servidor muestra fallas debido a un certificado de cliente incorrecto

Mi servidor de sendmail (FreeBSD, compilado con OpenSSL) se niega a negociar TLS con un conjunto particular de clientes.

Los mensajes de registro se ven así:

sm-mta[92474]: STARTTLS=servidor, error: error de aceptación=-1, motivo=sslv3 alerta de certificado incorrecto, SSL_error=1, errno=0, reintento=-1, ​​retransmisión=xx.example.com [XX.XX .XX.XX]

Aparte de estos fallos, que se originan en la infraestructura de correo de un ISP conocido, todo funciona muy bien; el certificado en el servidor está actualizado y es válido.

Dos preguntas, sería útil responder a cualquiera de ellas:

  1. ¿Cómo puedo diagnosticar esto? En particular, ¿puedo obtener una copia del certificado incorrecto desde el entorno de sendmail?
  2. ¿Puedo actualizar mi configuración de sendmail para decirle a los clientes que no proporcionen un certificado o para decirle a sendmail que acepte un certificado de cliente falso?

¡Gracias!

EDITAR: Encontré el problema aquí, que era que el certificado de mi servidor no coincidía con el registro DANE TLSA de mi servidor. Al observar una decodificación de Wireshark de la transacción, se mostró que el ISP (Comcast) estaba recibiendo mi certificado válido pero lo rechazaba de todos modos, y resultó que el registro TLSA no estaba sincronizado. Parece que Comcast podría ser uno de los pocos remitentes de correo electrónico en Internet que se niega a enviar después de una falla en la verificación del DANE.

Respuesta1

Puede utilizar OpenSSL para consultar el servidor remoto. Por ejemplo, para ver el certificado en uno de los servidores de correo de Google:

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

debería mostrar algo similar 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

Puede agregar -showcertspara obtener todos los certificados de la cadena.

Respuesta2

Mi forma genérica de abordar el problema de la validación de certificados es:

  1. Realizar una captura de red con tcpdump o similar
  2. Abra la captura en Wireshark y haga clic derecho en elALERTA SSL/TLSpaquete y eligió Follow->TCP stream
  3. Verifique el certificado X509:
    • Fechas (¿la fecha actual está entre la fecha de emisión y la fecha de vencimiento?)
    • Asunto (¿el nombre de host utilizado por el cliente es el mismo que el campo CN=?)
    • Nombre alternativo del sujeto (similar al Asunto)
    • Restricciones
    • Certificados intermedios (¿se presentan todos los certificados intermedios después del certificado de anfitrión? ¿Son válidos?)

Generalmente es la falta de un certificado intermedio lo que genera este tipo de problemas (algunos clientes no validan el certificado de su servidor).

Respuesta3

Resultó que capturar y analizar la negociación TLS en Wireshark era la clave aquí, y me llevó a descubrir que el ISP (Comcast) estaba rechazando mi certificado de dominio, a pesar de que casi todos los demás remitentes en Internet lo aceptaban.

Una investigación adicional encontró que el registro TLSA para el servidor de correo en cuestión estaba desactualizado y que Comcast rechazaba el certificado debido a una discrepancia de TLSA.

Desafortunadamente, los mecanismos de error disponibles en la negociación TLS no brindan una manera para que el remitente le diga al receptor por qué se rechazó el certificado. Quizás TLS 1.4 pueda definir una alerta específica para la falta de coincidencia del certificado DANE.

información relacionada