← RFC Reference

RFC 7817: Verificación de Identidad del Servidor TLS Actualizada para Correo Electrónico

Por qué existe esto

Cuando un cliente SMTP inicia una conexión TLS a un servidor de correo remoto (vía STARTTLS según RFC 3207 o TLS implícito según RFC 8314), recibe un certificado. ¿Pero qué nombre de host debe aparecer en ese certificado?

En correo electrónico, no te conectas directamente al dominio del destinatario. Buscas el registro MX para example.com, que podría apuntar a mail.hosting-provider.net. ¿Debería el certificado decir example.com o mail.hosting-provider.net? La respuesta importa porque:

• Verificar el nombre incorrecto significa que los certificados legítimos se rechazan
• No verificar en absoluto significa que TLS proporciona encriptación pero no autenticación — un atacante man-in-the-middle puede presentar cualquier certificado
• Los proveedores de alojamiento de correo sirven miles de dominios desde los mismos servidores y no pueden obtener certificados para cada dominio de cliente

Cómo funciona

RFC 7817 define una jerarquía clara de qué identificadores de referencia debe verificar un cliente contra el certificado del servidor, dependiendo de cómo se descubrió el servidor:

Orden de verificación de identidad

1. Nombre de host MX — si el servidor se encontró mediante búsqueda MX, verifica el certificado contra el nombre de host MX (p. ej., mail.hosting-provider.net), no el dominio del destinatario.
2. Dominio del destinatario — si no hay registro MX y el cliente recurre a un registro A/AAAA para el dominio mismo, verifica contra el dominio del destinatario.
3. Configuración explícita — si el servidor fue configurado manualmente (p. ej., un servidor de envío), verifica contra el nombre de host configurado.

Flujo de conexión TLS

; Paso 1: Resolver MX para dominio del destinatario
dig example.com MX
example.com.  IN  MX  10 mail.provider.net.

; Paso 2: Conectar a host MX, iniciar SMTP
220 mail.provider.net ESMTP ready
EHLO sender.example.org
250-mail.provider.net
250-STARTTLS
STARTTLS
220 Go ahead

; Paso 3: Protocolo de enlace TLS — verificar certificado contra "mail.provider.net"
; SAN del certificado: DNS:mail.provider.net, DNS:*.provider.net
; Coincidencia encontrada → identidad verificada

Detalles técnicos clave

Reglas de coincidencia de certificados

Identificador de referencia por método de descubrimiento

Interacción con DANE

Cuando DANE (RFC 7672) se implementa, el registro TLSA en DNS fija el certificado o la clave pública para el nombre de host MX. DANE proporciona una garantía de identidad más fuerte que la verificación tradicional basada en CA porque no depende de confiar en una autoridad de certificación — el propietario del dominio publica directamente los datos de certificado esperados en DNS firmado con DNSSEC.

Errores comunes

• Verificar el certificado contra el dominio del destinatario. Si MX para example.com apunta a mail.google.com, el certificado dirá mail.google.com, no example.com. Verificar el nombre incorrecto causa fallos de TLS o te fuerza a omitir la verificación completamente.
• Recurrir silenciosamente a TLS no autenticado. Muchos MTA utilizan "TLS oportunista" — encriptan si es posible pero no verifican certificados. Esto protege contra la escucha pasiva pero no contra ataques activos. Usa MTA-STS o DANE para requerir conexiones autenticadas.
• Certificados mal configurados en hosts MX. Si tu registro MX apunta a mx.yourdomain.com pero tu certificado solo cubre yourdomain.com, los remitentes que verifican certificados fallarán. Asegúrate de que el SAN de tu certificado incluya tu nombre de host MX.
• Ignorar la validación de la cadena de certificados. Verificar el nombre de host es necesario pero no suficiente. La cadena de certificados completa debe validar a una CA raíz confiable. Los certificados expirados o autofirmados seguirán fallando incluso si el nombre coincide.
• No renovar certificados antes de la expiración. Los certificados expirados en tus servidores MX causan fallos de protocolo de enlace TLS. Los remitentes que aplican MTA-STS se negarán a entregar correo a un servidor con un certificado expirado.

Impacto en entregabilidad

• La aplicación de MTA-STS depende de esto. Cuando un dominio receptor publica una política MTA-STS, los servidores de envío deben verificar el certificado MX según RFC 7817. Si tu certificado MX está mal configurado, los remitentes que aplican MTA-STS (incluido Gmail) no te entregarán correo.
• Google y Microsoft verifican certificados. Los principales proveedores cada vez más realizan verificación de certificados para correo saliente. Los certificados mal configurados en tu infraestructura receptora pueden causar fallos de entrega desde estos remitentes.
• DANE/TLSA proporciona la garantía más fuerte. DANE vincula el certificado a DNSSEC, eliminando completamente la dependencia de confianza en CA. Combinado con verificaciones de identidad RFC 7817, proporciona transporte de correo electrónico autenticado y encriptado.
• Reportes TLS revelan problemas. Informes TLS SMTP (RFC 8460) te envía reportes cuando los remitentes experimentan fallos de TLS conectando a tus servidores, incluidos fallos de verificación de certificados. Publica un registro TLSRPT y monitorea estos reportes.

Related RFCs