Fallos del certificado MTA-STS y de la cadena HTTPS

MTA-STS utiliza dos conexiones TLS diferentes. Uno obtiene la política del host de políticas HTTPS; otro protege la entrega SMTP a un MX seleccionado. Un certificado de sitio web válido no puede establecer que la recepción SMTP sea compatible y un certificado SMTP válido no puede reparar un extremo de política roto.

Nombre el punto final que falla primero

Referencias: RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2.

Por example.com , la búsqueda de políticas valida mta-sts.example.com . El certificado debe contener una identidad DNS coincidente, no estar vencido y encadenarse a un ancla de confianza aceptada por el remitente. MTA. A CNAME El destino de destino o redireccionamiento no reemplaza silenciosamente el nombre de host de la política en esta verificación.

En cambio, la validación SMTP verifica el nombre de host MX seleccionado. También confirme que el nombre de host coincida con al menos un patrón de política mx permitido. Se trata de comparaciones distintas: el hecho de que lo permita una política de comodines no hace que un certificado no relacionado sea válido. Conserve el nombre seleccionado, la cadena presentada, el tiempo de verificación y el contexto del almacén de confianza.

Diagnosticar más que el vencimiento

Referencias: RFC 8461 §7.1, RFC 6066 §3.

Una falla puede provenir de una hoja caducada, una discrepancia en el nombre de host, certificados intermedios faltantes o incorrectos, una cadena que no es de confianza o un punto final que presenta un certificado predeterminado. Pruebe con la indicación del nombre del servidor configurada en el nombre de host de la política para HTTPS y en el nombre de host MX para SMTP . Un servicio de hosting compartido puede presentar diferentes cadenas según el SNI.

Compare las observaciones del entorno del remitente afectado siempre que sea posible. Diferentes almacenes de confianza o software de cliente antiguo pueden producir resultados diferentes. Un icono verde del navegador en una estación de trabajo es una prueba útil para ese navegador, no una promesa de que todos los MTA emisores acepten la misma cadena.

Conservar una sonda reproducible

Referencia de herramienta: Manual OpenSSL 3.5 s_client. La ayuda de OpenSSL 3.5.7 instalada confirma estas opciones; no se reclama ninguna nueva sonda de punto final.

Para un host de políticas autorizado, sustituya el nombre de host de políticas real por cada marcador de posición POLICY_HOST:

openssl s_client -connect POLICY_HOST:443 -servername POLICY_HOST -verify_hostname POLICY_HOST -verify_return_error -showcerts

No ejecute el marcador de posición literalmente. Suministre la tienda CA confiable adecuada de la plataforma cuando sea necesario. Guarde stdout, stderr, la versión de OpenSSL y el resultado de la verificación. Luego recupere la URL de la política exacta con un cliente HTTPS de validación, con el seguimiento de redireccionamiento deshabilitado, y confirme HTTP 200 y el cuerpo de la política previsto.

Para un MX autorizado, sustituya el nombre de host MX real por cada marcador de posición MX_HOST:

openssl s_client -starttls smtp -connect MX_HOST:25 -servername MX_HOST -verify_hostname MX_HOST -verify_return_error -showcerts

Utilice el almacén de confianza correspondiente en ambas sondas. Referencias: RFC 8461 §4.2 y Semántica de verificación de nombre de host de OpenSSL. Una verificación exitosa del nombre de host OpenSSL por sí sola no es prueba de cumplimiento de MTA-STS : la verificación genérica del nombre de host puede recurrir al nombre común del certificado cuando no existe una SAN aplicable. RFC 8461 §4.2 requiere específicamente que el certificado SMTP contenga un nombre alternativo del sujeto con un ID DNS coincidente. Inspeccione el certificado SAN por separado y confirme que el nombre de host MX seleccionado coincida con una entrada DNS allí; no acepte la coincidencia de solo nombre común como verificación de identidad SMTP requerida. También verifique el MX con la política de forma independiente. Para el host de políticas HTTPS, RFC 8461 §3.3 permite comparar solo con identificadores DNS-ID y permite un comodín solo como la etiqueta completa más a la izquierda, mientras que los valores predeterminados genéricos de OpenSSL pueden aceptar comodines de etiqueta parcial; Trate ambas sondas como diagnósticos, no como validadores completos de perfiles de certificados MTA-STS . Un bloqueo del puerto 25 de salida en el entorno de prueba es una limitación de conectividad, no una prueba de que el certificado remoto esté roto. No se probó ningún punto final de producción. Las observaciones de la cadena de certificados retenidas del 7 de noviembre de 2026 que aparecen a continuación se capturaron en servicios de bucle invertido y no se volvieron a ejecutar aquí.

Reparar la cadena sin debilitar el reclamo de la póliza.

Referencias: RFC 8461 §3.3, RFC 8461 §4.2.

Instale el certificado correcto y la cadena intermedia en el punto final afectado a través de su flujo de trabajo de servicio aprobado. Vuelva a probar el nombre original y todas las direcciones relevantes. No utilice una recuperación insegura como resultado de verificación exitosa ni amplíe un patrón MX para ocultar una discrepancia de certificado.

Una actualización fallida no descarta una política almacenada en caché válida. Mantenga esa distinción en las comunicaciones de incidentes: corregir la política HTTPS admite recuperaciones futuras, mientras que corregir un MX roto puede restablecer la entrega compatible para los remitentes que aplican una política anterior. Supervise ambos ciclos de vida de los certificados de forma independiente.

Evidencia histórica retenida y alcance restante

El siguiente es el registro de laboratorio retenido del 7 de noviembre de 2026, inspeccionado pero no vuelto a ejecutar como experimento de red para esta revisión. La ejecución de nuevos dispositivos fuera de línea se registra por separado.

El seguimiento local con marca de tiempo capturó errores de nombre de host HTTPS y SMTP . HTTPS al utilizar el certificado .example .test wrong.example falló y el nombre de host no coincide para mta-sts.example .test. Un certificado caducado falló con el certificado caducado. Un certificado de host de políticas válido recién generado restauró la recuperación HTTPS. Por separado, el servicio SMTP anunciado STARTTLS y primero completó TLS 1.3 con un certificado de laboratorio válido; después de instalar el certificado incorrecto, la verificación del cliente falló para mx.old.example .test. Todas las comprobaciones de confianza utilizaron una CA de laboratorio desechable explícita y el nombre SNI solicitado. Las marcas de tiempo conservadas identifican las observaciones. Esos certificados son material histórico, no credenciales ni prueba del estado actual del servicio. Los eventos de recuperación HTTPS exitosos también conservan las huellas digitales del certificado; los eventos HTTPS y SMTP fallidos conservan los resultados de la verificación pero no contienen huellas digitales de certificados de pares. Esto es una prueba aislada de apretón de manos, no una afirmación de que un proveedor público tenga un problema con el certificado o que se haya verificado la renovación del certificado público.