Investigue los errores de nombre de certificado en relación con el extremo SMTP notificado y la política aplicada, manteniendo separada la identidad HTTPS del host de la política.
Identificar qué certificado fue evaluado
Referencias: RFC 8460 §4.3.1, RFC 8461 §3.3.
Certificate-host-mismatch es una categoría de error de negociación de transporte en RFC 8460 . Comience con el tipo de política, el dominio de la política, el nombre de host mx-receptor, la ip-recepción y el período del informe. El informe puede describir un servicio SMTP , mientras que MTA-STS La recuperación de políticas utiliza un nombre de host HTTPS independiente. Un certificado válido en mta-sts.example.com no prueba que mx1.example.net presente una identidad SMTP adecuada. Por el contrario, corregir el certificado del sitio web de la política no reparará un punto final SMTP que presente el certificado incorrecto.
Verifique la coincidencia de políticas y la identidad del certificado por separado
Referencias: RFC 8461 §4.1, RFC 8461 §4.2, RFC 8461 §3.3.
Para MTA-STS , el host MX seleccionado debe coincidir con los patrones MX permitidos de la política y el certificado SMTP TLS debe satisfacer las comprobaciones de identidad y confianza requeridas. Un patrón MX en la política no es un certificado emitido para ese host. RFC 8461 §4.2 requiere un ID de DNS coincidente en el nombre alternativo del sujeto del certificado SMTP . como el Documentación de verificación de nombre de host de OpenSSL explica, un verificador de nombre de host genérico puede aceptar el respaldo de nombre común; eso por sí solo no cumple con este requisito SAN. Verifique el destino MX real, no el dominio de correo electrónico visible del destinatario ni la etiqueta DNS inversa del servidor. Conserve la cadena de política informada porque un remitente aún puede estar usando una versión almacenada en caché vigente. Compare las configuraciones históricas y actuales antes de decidir qué cambio causó la discrepancia.
Vea el ejemplo del punto final incorrecto
En una configuración sintética, example.com tiene MX mx1.example.net y una política STS que permite mx1.example.net . El punto final SMTP presenta un certificado cuyo único DNS SAN es web.example.net . La comparación de políticas MX se realiza, pero el nombre de host exacto no aparece en este ejemplo de identidad de certificado, por lo que la verificación de identidad ilustrada falla. Reemplazar el conjunto SAN en el dispositivo local con mx1.example.net hace que se pase la verificación de nombre exacto deliberadamente simplificada. El dispositivo no es un validador X.509 completo y no implementa comodines, cadenas, caducidad o DANE normas.
Inspeccionar todas las rutas que puedan presentar un certificado.
Los balanceadores de carga, las direcciones IP alternativas y los hosts MX de respaldo pueden producir fallas intermitentes si solo algunos oyentes tienen el certificado deseado. Recopile la cadena real presentada y la identidad del punto final a través de SMTP autorizado STARTTLS pruebas. Compare la ruta y la marca de tiempo con los registros de implementación. No deshabilite la validación del nombre de host para que la prueba sea exitosa. Evite probar solo un puerto HTTPS o una dirección preferida y luego generalizar a todas las rutas de correo entrante. Marque ambas familias de direcciones donde estén desplegadas y sean relevantes para el reportero afectado.
Repare la capa responsable y vuelva a comprobar
Referencias: RFC 7672 §3.1.1, RFC 8460 §4.1.
Instale el certificado correcto o repare el enrutamiento al escucha TLS previsto. Si un patrón de política MX es realmente incorrecto, revise ese cambio por separado y considere las cachés del remitente. No agregue permisos amplios comodín simplemente para silenciar un error inexplicable. Conserve la evidencia del antes y el después y luego compare los informes posteriores por período de ocurrencia en lugar de por hora de llegada. Una política DANE requiere su propio análisis de autenticación específico del uso: la identidad DANE-EE no es el mismo modelo de verificación de nombres que MTA-STS . El ejemplo elaborado de este artículo es explícitamente STS y no utiliza ningún dominio de producción ni certificado activo.
Evidencia histórica retenida y controles actuales.
Las siguientes observaciones de transporte se capturaron el 7 de noviembre de 2026 y se inspeccionaron, no se volvieron a ejecutar como pruebas de red, para esta revisión. Las comprobaciones del nuevo modelo fuera de línea se registran por separado.
El corredor de evidencia/tls_lab.py retenido y el resultado fechado documentan un protocolo de enlace SMTP STARTTLS local real. El control positivo confía en una CA de laboratorio efímera y valida mx1.example .test. El caso name_mismatch utiliza un certificado para web.example .test y falla con el código de verificación de certificado 62. El resultado con marca de tiempo incluye el intercambio SMTP , el mensaje de validación exacto y la huella digital SHA-256 del certificado; public_lab_certificates.json conserva la hoja pública para su inspección. No se utiliza ninguna omisión de verificación de nombre. Esta captura retenida documenta una falla de punto final controlada, pero no ninguna ruta de recepción de producción. El corredor de transporte histórico requiere Python con criptografía y sockets de bucle invertido. Sus resultados son evidencia de laboratorio limitada, no el estado actual del servicio o la interoperabilidad de la producción.
Base de fuente primaria
Las definiciones de campo y los límites de informes provienen de RFC 8460 , Informes SMTP TLS, secciones 3 y 4. Cuando se analice la validación STS, consulte RFC 8461. Las recomendaciones operativas se distinguen de los requisitos del protocolo.