TLS en correo: por qué un “certificado válido” sigue fallando (y la solución real)

Qué significa realmente “certificado válido” en el mundo SMTP

Cuando alguien dice “el certificado es válido”, normalmente se refieren a: la firma del certificado leaf se verifica, no está caducado
y encadena a una raíz confiable en algún cliente. Eso es lo básico. SMTP añade más formas de estar equivocado.

En correo, la identidad TLS del servidor está ligada a nombres DNS, comportamiento de MX y políticas. Algunos clientes validan nombres estrictamente.
Otros no. Algunos se preocupan por SNI. Otros no pueden usar SNI. Algunos hacen cumplir cifrados modernos. Otros siguen anclados en 2012 pero siguen entregando correo para un banco.
“Válido” es un espectro, y tu MTA contraparte decide dónde trazar la línea.

Hechos interesantes y contexto histórico (corto, concreto y útil)

• STARTTLS para SMTP se estandarizó en 2002 (RFC 3207). Fue diseñado para una actualización oportunista, no para el cumplimiento estricto.
• SMTP se diseñó originalmente sin cifrado porque Internet temprana asumía un entorno cooperativo; el cifrado se añadió después.
• “TLS oportunista” se convirtió en la norma por años: cifra si es posible, vuelve a texto plano si no. Genial para entregabilidad, mediocre para confidencialidad.
• Las comprobaciones de nombres en certificados fueron históricamente inconsistentes entre MTAs. Esa inconsistencia explica por qué “funciona con Gmail” no es una prueba de certificado.
• SNI llegó más tarde que muchas pilas SMTP. Algunos MTAs antiguos aún no envían SNI, lo cual importa en servidores multiinquilino.
• Perfect Forward Secrecy se popularizó después de 2013. Preferencias de cifrado antiguas todavía pueden romper interoperabilidad cuando un lado desactiva lo “legacy” con exceso.
• MTA-STS es relativamente nuevo (RFC 8461, 2018) y cambió partes del TLS de correo de “mejor esfuerzo” a “aplicación por política”.
• DANE para SMTP existe (registros TLSA, RFC 7672) y puede hacer cumplir TLS sin CAs públicas—genial, hasta que DNSSEC no está implementado de extremo a extremo.
• Muchos MTAs aún tratan el puerto 465 como “SMTPS” para uso tipo submission, mientras que el puerto 25 sigue centrado en STARTTLS para servidor a servidor.

Hay una desalineación fundamental: la web es “cliente a un nombre de servidor”, mientras que SMTP es “servidor hacia lo que devuelva el DNS MX, potencialmente muchos nombres,
potencialmente cambiantes, potencialmente detrás de balanceadores”. A los certificados no les gusta la ambigüedad. SMTP sí.

Una frase que vale la pena mantener en la cabeza mientras depuras: La esperanza no es una estrategia. (idea parafraseada atribuida a la cultura de operaciones, usada en SRE y gestión de proyectos)

“Válido” es lo que la parte remota acepta. Tu trabajo es predecir qué aceptará una amplia variedad de contrapartes remotas—luego configurar en consecuencia.

Guía rápida de diagnóstico (comprueba esto, luego aquello)

Cuando TLS en correo falla, puedes perder horas en depuración basada en sensaciones. No lo hagas. Ejecuta esto en orden y normalmente encontrarás el cuello de botella rápido.

1. Primero: confirma qué nombre se está validando.
   • ¿Te conectas a mx1.example.com, mail.example.com o al dominio base?
   • ¿Cubre el certificado ese nombre exacto vía SAN?
   • ¿Estás detrás de un balanceador o proxy que cambia el endpoint TLS?
2. Segundo: captura el handshake real que ve el MTA remoto.
   • Usa openssl s_client con STARTTLS y (si aplica) SNI.
   • Verifica la presentación de la cadena: leaf + intermedios, en orden.
3. Tercero: lee los logs de tu MTA por cumplimiento de políticas.
   • ¿La parte remota aplica MTA-STS, DANE o “TLS requerido” para submission?
   • ¿Tu lado aplica comprobaciones de nombre o versiones mínimas de TLS?
4. Cuarto: verifica solapamiento de protocolo y cifrados.
   • TLSv1.2 es el mínimo para muchos MTAs modernos; TLSv1.0/1.1 son cada vez más rechazados.
   • Pero desactivar todo menos TLSv1.3 puede perjudicar si el par es antiguo.
5. Quinto: elimina “es el firewall” con evidencia.
   • Confirma puertos, NAT y cualquier dispositivo de inspección/intercepción TLS.
   • Revisa MTU/fragmentación si ves paradas extrañas a mitad del handshake.

Broma #1: La solución de problemas TLS en correo es como una novela detectivesca donde el villano siempre es “un intermediario faltante”, con un sombrero diferente en cada capítulo.

Por qué TLS falla incluso con un certificado válido

1) Coincidencia de hostname: el certificado es válido, pero no para ese nombre MX

Este es el problema número uno de “pero es válido!”. El certificado puede ser válido para mail.example.com,
mientras que el MTA remitente se conecta a mx1.example.com. O se conecta al dominio en el registro MX que apunta a
un hostname del proveedor que olvidaste que existía. La cadena está bien; la identidad es incorrecta.

SMTP añade una vuelta: muchos MTAs validan contra el nombre al que se conectaron (el objetivo MX), no contra lo que el servidor dice en el banner SMTP.
El banner puede ser honesto y aun así irrelevante.

Solución: pon los hostnames MX en los SAN del certificado, o cambia los MX a un nombre que controles y puedas certificar.
“Funciona en mi navegador” es irrelevante si tu navegador nunca se conecta al nombre MX.

2) Intermedio faltante: los navegadores lo buscan, los MTAs a menudo no

Los navegadores modernos son extremadamente tolerantes. Cachéan intermedios, los obtienen vía AIA y cubren configuraciones de servidor descuidadas.
Muchos MTAs, por diseño, no hacen fetching vía AIA. Esperan que el servidor presente una cadena completa.

Por eso un certificado puede verificarse en tu laptop y fallar en la entrega de correo en producción.
El MTA remoto ejecuta una build de OpenSSL antigua en un contenedor con un store de confianza mínimo y sin fetching AIA.
Ve el leaf, no puede construir la cadena y lo rechaza.

Solución: configura tu MTA para presentar leaf + intermedios en el orden correcto. No incluyas la raíz.

3) SNI y endpoints multiinquilino: obtuviste el certificado “por defecto”

Si múltiples dominios comparten una IP, el servidor necesita SNI para elegir el certificado correcto. Muchos clientes SMTP ahora envían SNI,
pero no todos. Algunos MTAs antiguos se conectarán sin SNI y recibirán el certificado por defecto, que puede ser válido, pero no para ti.

La parte divertida: esto puede ser intermitente. Algunos remitentes tienen éxito (envían SNI), otros fallan (no lo hacen). Obtienes una historia fantasma en los logs.

Solución: configura el certificado por defecto para que cubra de forma segura el nombre MX principal, o dedica IPs para correo cuando sea posible.
Si debes tener multiinquilino, prueba con y sin SNI.

4) Desajuste de versión TLS y suite de cifrado: “modernizar” puede significar “romper el correo”

A los equipos de seguridad les encantan las guías de endurecimiento. A SREs les encanta no recibir páginas a las 2 a.m. Estos amores no siempre coinciden.
Si desactivas TLSv1.2 o quitas cifrados comunes, puedes dejar varados a remitentes antiguos pero legítimos.

Por otro lado, si el remoto insiste en TLSv1.2+ y tu stack está atascado en TLSv1.0, tú eres el legado.
Esto aparece como fallos de handshake, alertas de versión de protocolo o errores de negociación de cifrado.

Solución: mantén TLSv1.2 habilitado en servidores SMTP. TLSv1.3 es excelente, pero no asumas soporte universal.
Desactiva cifrados claramente inseguros, pero conserva un conjunto de solapamiento sensato.

5) Confusión de políticas STARTTLS: oportunista vs obligatorio

STARTTLS fue diseñado para ser oportunista. Eso significa: si el cifrado falla, el correo aún puede entregarse en texto plano.
Pero varios mecanismos pueden cambiar ese comportamiento:

• Submission (587) a menudo requiere TLS, porque transporta credenciales de usuario.
• Transporte entre partners puede exigir TLS mediante una política explícita o ajustes de conector.
• MTA-STS indica a los remitentes: “Solo entrégame por TLS válido, o no entregues”.
• DANE puede forzar TLS a nivel DNS (cuando DNSSEC valida).

Así que puedes tener un certificado “válido” que aún falle porque la política exige validación de hostname, o un nombre particular,
o una cadena particular, no solo cifrado.

6) Nombre EHLO/HELO incorrecto y DNS inverso: no es TLS, pero a menudo se confunde con TLS

Este problema consume tiempo porque está junto a errores TLS en los logs. Algunos MTAs rechazarán o penalizarán
conexiones con rDNS malo, nombres HELO inconsistentes o banners genéricos. Eso puede parecer un “problema TLS”
cuando en realidad es un problema de reputación/identidad.

Solución: alinea PTR (DNS inverso), A/AAAA directo y el nombre HELO que usa tu servidor. No arreglará una cadena rota,
pero reducirá el ruido mientras solucionas TLS.

7) Middleboxes: inspección TLS, NAT y firewalls “útiles”

STARTTLS SMTP es especialmente bueno para activar middleboxes corporativos que creen que todo debería parecer HTTPS.
Algunos dispositivos deforman la negociación STARTTLS, eliminan extensiones o reinician conexiones cuando ven handshakes desconocidos.

Solución: evita la inspección TLS para SMTP, o usa un camino que no atraviese el dispositivo de inspección.
Si no puedes, prepárate para sufrir y documenta cada excepción que añadas.

8) Formato de certificado incorrecto / clave desajustada / permisos: básico pero real

El certificado puede ser válido y aun así no cargarse. Postfix, Exim y otros fallarán en abierto o cerrado dependiendo de la configuración.
Si tu servicio vuelve a texto plano o presenta un certificado por defecto porque no puede leer el correcto, obtendrás síntomas confusos.

Solución: verifica que el servicio en ejecución usa realmente el archivo que crees y que la clave coincide.

9) DANE y MTA-STS: cuando las reglas cambian debajo de ti

DANE con DNSSEC puede permitir certificados autofirmados o de CA privada si el registro TLSA coincide. Eso es potente—y frágil.
¿Rota un certificado y olvidas actualizar TLSA? Acabas de forzar tu propio outage.

MTA-STS es diferente: sigue dependiendo del PKI público, pero hace cumplir “certificado válido” y “nombre correcto” de una manera que TLS oportunista no hace.
Si publicas una política MTA-STS y tus endpoints MX no son consistentes, verás fallos súbitos de entrega por parte de remitentes que la respeten.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son comprobaciones de nivel producción. No son teoría. Ejecútalas, lee la salida, decide el siguiente movimiento.
Los comandos asumen un servidor Linux con herramientas comunes.

Tarea 1: Ver qué certificado presenta realmente tu servidor SMTP (STARTTLS en 25)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts -verify_return_error
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R11
verify return:1
depth=0 CN=mail.example.com
verify return:1
---
Certificate chain
 0 s:CN=mail.example.com
   i:C=US, O=Let's Encrypt, CN=R11
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C=US, O=Let's Encrypt, CN=R11
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
...

Qué significa: El CN del certificado leaf es mail.example.com, pero te conectaste a mx1.example.com.
Si los SAN no incluyen mx1.example.com, remitentes estrictos te rechazarán.

Decisión: Reemitir un certificado que incluya los hostnames MX en SAN, o cambiar MX para que coincida con el certificado.

Tarea 2: Verificar cobertura de SAN explícitamente

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 

cr0x@server:~$ openssl x509 -noout -text | sed -n '/Subject:/,/X509v3 Subject Alternative Name:/p'
Subject: CN = mail.example.com
            X509v3 Subject Alternative Name:
                DNS:mail.example.com, DNS:smtp.example.com

Qué significa: No hay mx1.example.com en SAN. CN por sí solo no es fiable, y la validación moderna usa SAN de todos modos.

Decisión: Añadir mx1.example.com (y cualquier otro objetivo MX) a los SAN durante la emisión.

Tarea 3: Comprobar intermedios faltantes (completitud de cadena)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++}{print > ("cert" i ".pem")}'
cr0x@server:~$ for f in cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer -in "$f"; done
== cert1.pem ==
subject=CN = mail.example.com
issuer=C = US, O = Let's Encrypt, CN = R11
== cert2.pem ==
subject=C = US, O = Let's Encrypt, CN = R11
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

Qué significa: El servidor presentó leaf + intermedio. Bien. Si solo hubieras visto cert1.pem,
muchos MTAs fallarían al construir la cadena.

Decisión: Si falta el intermedio, arregla el smtpd_tls_cert_file (Postfix) o su equivalente para incluir fullchain.

Tarea 4: Confirmar que la clave privada coincide con el certificado leaf

cr0x@server:~$ openssl x509 -noout -modulus -in /etc/ssl/mail/fullchain.pem | openssl md5
MD5(stdin)= 6f0c9a7d5b0c0b3f4b6a7e3c2d1a9e10
cr0x@server:~$ openssl rsa -noout -modulus -in /etc/ssl/mail/privkey.pem | openssl md5
MD5(stdin)= 6f0c9a7d5b0c0b3f4b6a7e3c2d1a9e10

Qué significa: Los hashes de módulo coinciden: la clave y el certificado pertenecen juntos.
Si no coincidieran, tu MTA podría fallar TLS o presentar otro certificado.

Decisión: Si hay desajuste, despliega el par clave/cert correcto y recarga el servicio.

Tarea 5: Confirmar qué está configurado Postfix para usar (y si realmente está habilitado)

cr0x@server:~$ postconf -n | egrep 'smtpd_tls_|smtp_tls_|myhostname|mydomain'
myhostname = mx1.example.com
smtpd_tls_cert_file = /etc/ssl/mail/fullchain.pem
smtpd_tls_key_file = /etc/ssl/mail/privkey.pem
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

Qué significa: TLS entrante y saliente son oportunistas (may), y el nivel de log es bajo pero no cero.

Decisión: Si intentas satisfacer un requisito de partner que exige TLS, puede que necesites políticas por dominio, no un encrypt global.

Tarea 6: Convertir logs en evidencia (detalle de logs TLS en Postfix)

cr0x@server:~$ sudo postconf -e 'smtpd_tls_loglevel=2' 'smtp_tls_loglevel=2'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Feb  4 12:10:21 mx1 postfix/smtpd[22110]: Anonymous TLS connection established from mail-oi1-f169.google.com[209.85.167.169]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
Feb  4 12:10:44 mx1 postfix/smtpd[22110]: warning: TLS library problem: error:0A000086:SSL routines::certificate verify failed: TLS alert unknown ca

Qué significa: Primera línea: éxito con un remitente moderno. Segunda: otro par falló la verificación (o tu servidor falló al verificar el suyo, dependiendo de la dirección).

Decisión: Si las fallas son entrantes y no requieres certificados de cliente, asegúrate de no estar mal configurado para verificar clientes. Si son salientes, revisa tu store de confianza.

Tarea 7: Identificar si SNI cambia el certificado presentado

cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.25:25 -showcerts 2>/dev/null | openssl x509 -noout -subject
subject=CN = default.invalid
cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.25:25 -servername mx1.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject
subject=CN = mx1.example.com

Qué significa: Sin SNI obtienes el certificado por defecto (default.invalid), con SNI obtienes el correcto (mx1.example.com).

Decisión: Si no puedes dedicar IPs, configura el certificado por defecto a algo aceptable para tu MX principal y prueba con un cliente sin SNI.

Tarea 8: Probar solapamiento de protocolos (forzar versiones TLS)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -servername mx1.example.com 

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_1 -servername mx1.example.com
...
ssl3_read_bytes:tlsv1 alert protocol version
...

Qué significa: TLS 1.2 funciona; TLS 1.1 es rechazado. Eso es buena higiene en 2026.
Si tu par solo soporta TLS 1.1, ellos fallarán.

Decisión: Mantén TLS 1.2 habilitado. Decide si soportar pares legacy caso por caso (usualmente no en MX públicos).

Tarea 9: Confirmar qué cifrados ofrece tu servidor (desde el lado del servidor)

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_tls_mandatory_protocols|smtpd_tls_protocols|smtpd_tls_mandatory_ciphers|tls_high_cipherlist'
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high

Qué significa: Los protocolos obligatorios son TLSv1.2+. Lo oportunista aún permite más a menos que se limite.
“high” es vago; depende de OpenSSL.

Decisión: Si existen problemas de interoperabilidad, establece explícitamente una lista de cifrados moderna pero compatible en lugar de confiar en la magia de “high”.

Tarea 10: Comprobar registros MX y ver a qué nombres se conecta el mundo

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
cr0x@server:~$ dig +short A mx1.example.com
203.0.113.25
cr0x@server:~$ dig +short AAAA mx1.example.com
2001:db8:25::25

Qué significa: Estos son los hostnames que deben estar cubiertos por certificados (o al menos presentar defaults correctos).

Decisión: Asegúrate de que cada objetivo MX tenga un certificado cuyo SAN incluya ese hostname exacto, para endpoints IPv4 e IPv6.

Tarea 11: Verificar alineación de DNS inverso (reduce problemas que parecen TLS)

cr0x@server:~$ dig +short -x 203.0.113.25
mx1.example.com.
cr0x@server:~$ hostname -f
mx1.example.com

Qué significa: PTR coincide con tu FQDN. A muchos receptores les gusta esto. Algunos lo requieren para puntuación de reputación.

Decisión: Si PTR está mal, arréglalo con tu proveedor de IP. No persigas fantasmas TLS hasta que la identidad básica esté alineada.

Tarea 12: Comprobar estado de MTA-STS desde DNS (¿aplicas TLS estricto?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=2024020401"
cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Qué significa: Publicas MTA-STS y reporting TLS. Remitentes que respeten STS pueden ahora hacer cumplir validez de certificado y comprobaciones de nombre.

Decisión: Si no estás listo para la severidad, no publiques MTA-STS. Si lo estás, asegúrate de que nombres MX y certificados sean consistentes en todas partes.

Tarea 13: Revisa TLSRPT (si recoges informes) para ver quién falla y por qué

cr0x@server:~$ sudo grep -R "sts-policy" -n /var/mail/tlsrpt/ | head
/var/mail/tlsrpt/report-2026-02-04.json:42:    "result_type": "sts-policy-invalid"
/var/mail/tlsrpt/report-2026-02-04.json:43:    "sending_mta_ip": "198.51.100.10"

Qué significa: Algunos remitentes fallan por cuestiones de política STS, no por mecánica TLS pura.

Decisión: Arregla la publicación de la política STS y la alineación, o ajusta temporalmente el modo de política para evitar fallos duros durante la transición.

Tarea 14: Confirmar que tu servicio escucha y anuncia STARTTLS

cr0x@server:~$ nc -v mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!
220 mx1.example.com ESMTP Postfix
cr0x@server:~$ printf "EHLO test.example\r\nQUIT\r\n" | nc -v mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!
220 mx1.example.com ESMTP Postfix
250-mx1.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

Qué significa: STARTTLS se ofrece. Si falta, los remitentes no pueden actualizar—aunque tengas un gran certificado.

Decisión: Si STARTTLS no se anuncia, arregla la habilitación TLS del MTA y asegura que ningún proxy elimine extensiones.

Tres microhistorias corporativas desde el frente

Microhistoria 1: El outage causado por una suposición equivocada (validación de hostname)

Una empresa SaaS de tamaño medio migró correo entrante a un nuevo clúster. El equipo hizo lo “correcto”:
nuevas IPs, nuevos registros MX y un flamante certificado de una CA pública. Probaron con un par de cuentas externas,
vieron el flujo de correo y declararon la victoria.

Entonces el gateway de seguridad de un cliente grande comenzó a aplazar mensajes con una razón de fallo TLS. No los rechazaba. Los aplazaba.
Eso es peor: se acumula y se convierte en el problema del día siguiente, justo cuando esperabas dormir.

El certificado de la empresa era válido para mail.example.com. Sus registros MX apuntaban a mx1.example.com y mx2.example.com.
Asumieron que el CN lo cubriría (“¿no es eso lo que hacen los certificados?”), y asumieron que los MTAs remitentes validan contra el nombre del banner.
El gateway del cliente validaba contra el nombre MX al que se conectó. Estrictamente. Correctamente.

La solución fue aburrida: reemitir el certificado con SAN cubriendo ambos nombres MX y el nombre de submission,
desplegar fullchain, recargar Postfix. La entrega se recuperó inmediatamente para ese cliente y varios otros que habían estado aplazando silenciosamente también.

La lección: un certificado válido no es una identidad; es una afirmación. Los pares SMTP deciden si creerla y con qué la comparan.
Tus suposiciones no tienen voto.

Microhistoria 2: La optimización que salió mal (endurecimiento que rompió compatibilidad)

Una iniciativa de seguridad recorrió una gran empresa: estandarizar “TLS moderno en todas partes”. Al equipo de correo le pidieron desactivar
protocolos y cifrados antiguos “para cumplir”. Nadie discutió la meta; discutieron el calendario.
El calendario ganó.

Desplegaron una configuración que en la práctica requería TLS 1.3 para SMTP entrante. En papel se veía progresista.
En la práctica convirtió su MX en un portero con una lista y sin paciencia.

Algunos remitentes negociaron TLS 1.3 bien. Otros—dispositivos industriales, MTAs de pequeñas empresas y algunos sistemas partner usando bibliotecas antiguas—
solo podían TLS 1.2. La entrega comenzó a fallar de forma intermitente. No solo fuentes spam. Facturas reales. Actualizaciones de tickets reales.
El incidente se clasificó inicialmente como “inestabilidad de red” porque parecía aleatorio entre remitentes.

La remediación fue un rollback controlado: permitir TLS 1.2, mantener TLS 1.0/1.1 deshabilitados y usar una lista de cifrados sensata que aún solapara
con builds comunes de OpenSSL. También implementaron monitorización que rastrea la distribución de versiones TLS en conexiones entrantes.

La lección: el endurecimiento no es un único control. Es una negociación. SMTP es un ecosistema, no tu aplicación.
Optimiza por seguridad sin probar la interoperabilidad y “aseguradamente” perderás correo.

Microhistoria 3: La práctica aburrida y correcta que salvó el día (TLSRPT + aplicación gradual)

Otra compañía quería forzar cifrado para correo entrante. Tenían requisitos legales y un modelo de amenazas real.
En lugar de pulsar todos los interruptores de una vez, lo hicieron por fases: observar, medir, luego aplicar.

Publicaron reporting TLS y recopilaron informes TLSRPT centralmente. Durante semanas, el equipo revisó las categorías de fallo.
La mayoría era ruido esperado, pero algunos eran reales: un nodo MX presentó la cadena incorrecta después de una actualización de paquete;
otro tenía una dirección IPv6 sirviendo un certificado obsoleto porque la automatización solo actualizaba VIPs IPv4.

Arreglaron las inconsistencias, añadieron un trabajo diario que comprueba cada endpoint MX por IPv4 e IPv6,
y solo entonces pasaron MTA-STS a modo enforce. Cuando finalmente aplicaron la exigencia, la tasa de fallos no aumentó.
De hecho bajó—porque eliminaron configuraciones erróneas que silenciosamente provocaban degradaciones oportunistas de TLS.

La lección: la observabilidad aburrida vence a la depuración heroica. Si quieres TLS estricto, gánatelo haciendo que tus endpoints sean consistentemente aburridos primero.

Broma #2: Lo único más persistente que un intermedio faltante es la invitación a la reunión para “volver a esto” el próximo trimestre.

Errores comunes: síntoma → causa raíz → solución

1) “Handshake TLS falló” con un certificado que luce bien en un navegador

Síntoma: MTAs remotos registran certificate verify failed o unknown ca; tu navegador muestra candado.

Causa raíz: Intermedio faltante en la cadena. Los navegadores lo obtienen; muchos MTAs no.

Solución: Sirve fullchain.pem (leaf + intermedios) desde tu MTA. No confíes en AIA fetching.

2) Funciona con algunos remitentes, falla con otros (aparentemente aleatorio)

Síntoma: Un subconjunto de remitentes falla consistentemente validación STARTTLS; otros tienen éxito.

Causa raíz: Selección de certificado dependiente de SNI, o distinta severidad de validación entre MTAs.

Solución: Prueba con y sin SNI. Haz el certificado por defecto aceptable para tu nombre MX o dedica IPs.

3) “hostname mismatch” o “certificate does not match”

Síntoma: Los logs mencionan mismatch; entrega aplazada o TLS degradado.

Causa raíz: SAN del certificado no incluye el hostname objetivo MX (común durante migraciones).

Solución: Reemitir el certificado para incluir todos los hostnames MX en SAN; o ajustar MX para coincidir con un nombre de certificado existente.

4) STARTTLS no se ofrece, aunque configuraste certificados

Síntoma: La salida EHLO no incluye 250-STARTTLS.

Causa raíz: TLS deshabilitado en la configuración del MTA; problemas en ruta chroot; problemas de permisos; o proxy que quita extensiones.

Solución: Asegura que TLS esté habilitado, que cert/key sean legibles por el MTA y que ningún middlebox modifique extensiones SMTP.

5) Fallos súbitos tras habilitar MTA-STS

Síntoma: Correo previamente entregado ahora se aplaza desde proveedores importantes; TLSRPT muestra fallos de política.

Causa raíz: Publicar MTA-STS convirtió TLS oportunista en validación estricta, revelando inconsistencias de nombre/cadena.

Solución: Alinea certificados en todos los endpoints MX (incluyendo IPv6), verifica nombres, corrige presentación de cadena y vuelve a aplicar.

6) Solo falla la entrega por IPv6 en TLS

Síntoma: El camino IPv4 funciona; IPv6 muestra certificado equivocado o cadena caducada.

Causa raíz: VIP separado, listener separado, automatización obsoleta o pool de balanceador diferente para AAAA.

Solución: Prueba explícitamente endpoints A y AAAA; unifica la automatización para que el despliegue de certificados cubra ambos.

7) “no shared cipher” o “handshake failure” tras endurecer

Síntoma: TLS falla en negociación; logs muestran desajuste de cifrados o alerta de protocolo.

Causa raíz: El endurecimiento eliminó el solapamiento común (o forzó solo TLS 1.3).

Solución: Mantén TLS 1.2; usa una lista de cifrados moderna pero compatible. Valida contra una matriz de stacks de remitentes reales.

8) El certificado rota y luego los partners fallan (especialmente con DANE)

Síntoma: Tras rotación, un subconjunto de remitentes rechaza TLS aunque el nuevo certificado sea válido.

Causa raíz: Registros TLSA no actualizados (DANE), o pinning/caché de partners.

Solución: Actualiza TLSA antes o durante la rotación; planifica ventanas de solapamiento; comunica a partners estrictos.

Listas de verificación / plan paso a paso

Paso a paso: hacer que un certificado SMTP funcione realmente

1. Inventaria tus nombres públicos.
   • Lista todos los targets MX (incluyendo MX de backup).
   • Lista hostnames de submission/IMAP/POP si comparten endpoints.
   • Incluye endpoints IPv6 AAAA.
2. Emite certificados para los nombres a los que se conectan las personas.
   • Pon cada hostname MX en SAN.
   • No confíes solo en CN.
   • Decide si necesitas wildcards (usualmente evitar para correo; nombres explícitos son más claros).
3. Despliega la cadena completa correctamente.
   • Usa fullchain.pem (leaf + intermedios).
   • No incluyas la CA raíz en la cadena presentada.
4. Establece el certificado por defecto intencionalmente.
   • Asume que algunos clientes no enviarán SNI.
   • Haz que el cert por defecto sea válido para el nombre MX primario.
5. Elige versiones TLS con interoperabilidad en mente.
   • Habilita TLS 1.2 y TLS 1.3.
   • Deshabilita TLS 1.0/1.1 salvo necesidad de negocio muy concreta y controles compensatorios.
6. Prueba desde fuera de tu red.
   • Ejecuta comprobaciones STARTTLS contra cada nombre MX y cada familia IP.
   • Prueba con y sin SNI.
7. Decide mecanismos de aplicación cuidadosamente.
   • TLS oportunista está bien para “seguridad básica”.
   • MTA-STS/DANE es para cuando mantienes tu configuración consistentemente bajo cambios.
8. Operacionaliza rotaciones.
   • Automatiza despliegues y recargas.
   • Monitoriza expiración, corrección de cadena y paridad de endpoints (IPv4/IPv6).

Lista de verificación: antes de publicar MTA-STS en modo enforce

• Cada endpoint MX (todas las direcciones A/AAAA) presenta la misma cadena de certificado correcta.
• El SAN del certificado incluye todos los hostnames objetivos MX.
• El certificado por defecto es aceptable cuando falta SNI.
• TLS 1.2 funciona en todas partes; TLS 1.3 funciona donde esté soportado.
• No hay middleboxes que quiten STARTTLS o alteren la negociación.
• Tienes logs y un proceso para investigar fallos TLS rápidamente.

Lista de verificación: resolver conectores partner “TLS requerido”

• Obtén el hostname y puerto exactos a los que se conecta el partner.
• Obtén el texto de error exacto y si ocurre durante handshake, comprobación de nombre o validación de cadena.
• Prueba tu lado con openssl s_client -starttls smtp contra ese hostname.
• Si terminas TLS detrás de un balanceador, valida el cert del LB y el comportamiento SNI.
• Verifica que el partner no esté haciendo pinning de un certificado o intermedio antiguo.

Preguntas frecuentes

1) ¿Por qué mi certificado valida en un navegador pero falla para SMTP?

Los navegadores suelen obtener intermedios faltantes y tienen stores de confianza amplios. Muchos MTAs no obtienen intermedios y dependen de lo que presentes.
Además, los pares SMTP validan el hostname MX al que se conectan, no necesariamente lo que probaste en un navegador.

2) ¿Necesito un certificado separado para cada servidor MX?

No estrictamente. Puedes usar un único certificado con entradas SAN para todos los hostnames MX, desplegado en todos lados.
Operativamente, eso suele ser más sencillo—una canalización de emisión, un calendario de renovación—si puedes mantener la distribución controlada.

3) ¿Debo usar un certificado wildcard para correo?

Usualmente: evítalo a menos que tengas una razón fuerte. Los wildcards no cubren nombres de varios niveles y pueden ocultar inventario descuidado.
SANs explícitos facilitan auditorías y aplicación de políticas sin sorpresas.

4) ¿Es necesario el puerto 465 para correo seguro?

Para servidor a servidor: no, el puerto 25 con STARTTLS es la norma. Para submission desde clientes, el puerto 587 es estándar con STARTTLS,
y el puerto 465 se usa comúnmente para submission con TLS implícito. Usa lo que soporten tus clientes, pero no muevas tráfico MX fuera del 25.

5) ¿Cuál es la diferencia entre TLS oportunista y TLS obligatorio en SMTP?

TLS oportunista actualiza cuando es posible y puede volver a texto plano si la negociación falla. TLS obligatorio (vía MTA-STS, DANE
o conectores de partners) rechaza la entrega si TLS no puede validarse según la política.

6) ¿Todos los MTAs validan hostnames en certificados?

No, pero más lo hacen que antes—especialmente bajo MTA-STS o cuando están configurados para “TLS requerido”.
Debes asumir que algunos pares validarán de forma estricta y configurar en consecuencia.

7) ¿Cuál es la mala configuración más común que ves?

Servir solo el certificado leaf sin el intermedio. Es el clásico bug de “funciona en mi laptop” vestido de PKI.

8) Si usamos DANE, ¿podemos prescindir por completo de CAs públicas?

Potencialmente sí, si tu dominio está firmado con DNSSEC correctamente y tus pares validan DNSSEC y DANE para SMTP.
En la práctica, necesitas entender tu ecosistema de corresponsales antes de apostar la entregabilidad a una validación DNSSEC universal.

9) ¿Por qué algunos remitentes se conectan a la dirección IPv6 y fallan, mientras IPv4 funciona?

Porque tu AAAA apunta a un listener o pool diferente con certificado obsoleto, cadena incorrecta o certificado por defecto distinto.
Prueba y gestiona IPv6 como un endpoint de primera clase, no como una casilla de verificación.

10) ¿Debo incluir el certificado raíz en la cadena que presento?

No. Presenta el leaf y los intermedios necesarios para construir hasta una raíz confiable. Incluir la raíz no es necesario y a veces es perjudicial.

Conclusión: pasos prácticos siguientes

“Certificado válido” es una frase reconfortante, como “el servidor está arriba”. También no es una respuesta.
TLS en correo falla en las grietas: hostname equivocado, cadena incompleta, desajuste SNI, aplicación de políticas e endpoints inconsistentes.
Arreglarlo es menos comprar un certificado mejor y más hacer que identidad, DNS y despliegue concuerden en todas partes.

1. Ejecuta pruebas STARTTLS contra cada nombre MX (y ambos IPv4/IPv6). Captura la cadena presentada y los SAN.
2. Haz que el certificado coincida con cómo se conecta el mundo: SANs para todos los objetivos MX, certificado por defecto correcto, despliegue consistente.
3. Sirve la cadena completa (leaf + intermedios) y verifica con herramientas no navegador.
4. Mantén TLS 1.2 habilitado; añade TLS 1.3; evita endurecer hasta eliminar el solapamiento común sin evidencia.
5. Si quieres aplicación (MTA-STS/DANE), gánatela haciendo que tus endpoints sean aburridamente consistentes antes de activar.

Haz esas cinco cosas y la mayoría de los “misteriosos fallos TLS en correo” dejarán de ser misteriosos. Volverán a ser lo que siempre fueron:
deriva de configuración, desajuste de identidad y suposiciones optimistas frente al mundo real.