MTA-STS usa duas conexões TLS diferentes. Busca-se a política do host da política HTTPS; outro protege a entrega SMTP para um MX selecionado. Um certificado de site válido não pode estabelecer que o recebimento de SMTP é compatível e um certificado SMTP válido não pode reparar um endpoint de política quebrado.
Nomeie primeiro o endpoint com falha
Referências: RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2.
Por example.com , a busca de política valida mta-sts.example.com . O certificado deve conter uma identidade DNS correspondente, não ter expirado e estar vinculado a uma âncora confiável aceita pelo remetente MTA. A CNAME destino ou destino de redirecionamento não substitui silenciosamente o nome do host da política nesta verificação.
A validação SMTP verifica o nome do host MX selecionado. Confirme também se o nome do host corresponde a pelo menos um padrão MX de política permitido. Estas são comparações distintas: ser permitido por uma política curinga não torna válido um certificado não relacionado. Preservar o nome selecionado, a cadeia apresentada, o tempo de verificação e o contexto do armazenamento confiável.
Diagnosticar mais do que expiração
Referências: RFC 8461 §7.1, RFC 6066 §3.
Uma falha pode vir de uma folha expirada, uma incompatibilidade de nome de host, certificados intermediários ausentes ou incorretos, uma cadeia não confiável ou um endpoint apresentando um certificado padrão. Teste com a Indicação de Nome do Servidor configurada para o nome do host da política para HTTPS e para o nome do host MX para SMTP . Um serviço de hospedagem compartilhada pode apresentar diferentes cadeias dependendo do SNI.
Compare as observações do ambiente do remetente afetado sempre que possível. Diferentes armazenamentos confiáveis ou software cliente antigo podem produzir resultados diferentes. Um ícone verde do navegador em uma estação de trabalho é uma evidência útil desse navegador, e não uma promessa de que todos os MTAs de envio aceitam a mesma cadeia.
Mantenha uma sonda reproduzível
Referência da ferramenta: Manual do OpenSSL 3.5 s_client. A ajuda instalada do OpenSSL 3.5.7 confirma essas opções; nenhuma nova investigação de endpoint é reivindicada.
Para um host de política autorizado, substitua o nome do host de política real para cada espaço reservado POLICY_HOST:
openssl s_client -connect POLICY_HOST:443 -servername POLICY_HOST -verify_hostname POLICY_HOST -verify_return_error -showcertsNão execute o espaço reservado literalmente. Forneça o armazenamento CA confiável apropriado da plataforma quando necessário. Salve stdout, stderr, a versão OpenSSL e o resultado da verificação. Em seguida, recupere o URL exato da política com um cliente HTTPS de validação, com o redirecionamento seguinte desativado, e confirme o HTTP 200 e o corpo da política pretendido.
Para um MX autorizado, substitua o nome do host MX real por cada espaço reservado MX_HOST:
openssl s_client -starttls smtp -connect MX_HOST:25 -servername MX_HOST -verify_hostname MX_HOST -verify_return_error -showcertsUse o armazenamento confiável relevante em ambas as investigações. Referências: RFC 8461 §4.2 e Semântica de verificação de nome de host OpenSSL. Uma verificação bem-sucedida do nome do host OpenSSL por si só não é prova de conformidade com MTA-STS : a verificação genérica do nome do host pode recorrer ao nome comum do certificado quando um SAN aplicável estiver ausente. RFC 8461 §4.2 exige especificamente que o certificado SMTP contenha um nome alternativo de assunto com um ID DNS correspondente. Inspecione o certificado SAN separadamente e confirme se o nome do host MX selecionado corresponde a uma entrada DNS ; não aceite correspondência apenas de nome comum como verificação de identidade SMTP necessária. Verifique também o MX em relação à política de forma independente. Para o host da política HTTPS, RFC 8461 §3.3 permite a correspondência apenas com identificadores DNS-ID e permite um curinga apenas como o rótulo completo mais à esquerda, enquanto os padrões OpenSSL genéricos podem aceitar curingas de rótulo parcial; trate ambas as sondagens como diagnósticos, não como validadores de perfil de certificado MTA-STS completos. Um bloco da porta 25 de saída no ambiente de teste é uma limitação de conectividade e não uma evidência de que o certificado remoto está quebrado. Nenhum endpoint de produção foi investigado. As observações da cadeia de certificados retidas de 7 de novembro de 2026 abaixo foram capturadas em serviços de loopback e não foram executadas novamente aqui.
Reparar a cadeia sem enfraquecer a reivindicação da apólice
Referências: RFC 8461 §3.3, RFC 8461 §4.2.
Instale o certificado correto e a cadeia intermediária no endpoint afetado por meio do fluxo de trabalho de serviço aprovado. Teste novamente o nome original e todos os endereços relevantes. Não use uma busca insegura como resultado de verificação bem-sucedida nem amplie um padrão MX para ocultar uma incompatibilidade de certificado.
Uma atualização com falha não descarta uma política válida em cache. Mantenha essa distinção nas comunicações de incidentes: consertar a política HTTPS oferece suporte a buscas futuras, enquanto consertar um MX quebrado pode restaurar a entrega compatível para remetentes que aplicam uma política mais antiga. Monitore os dois ciclos de vida dos certificados de forma independente.
Evidências históricas retidas e escopo restante
A seguir está o registro de laboratório retido de 7 de novembro de 2026, inspecionado, mas não executado novamente como um experimento de rede para esta revisão. A nova execução de fixture offline é registrada separadamente.
O rastreamento local com registro de data e hora capturou falhas de nome de host HTTPS e SMTP . HTTPS usando o certificado wrong.example .test falhou com uma incompatibilidade de nome de host para mta-sts.example .test. Um certificado expirado falhou e o certificado expirou. Um certificado de host de política válido recém-gerado restaurou a recuperação de HTTPS. Separadamente, o serviço SMTP anunciado STARTTLS e concluiu primeiro TLS 1.3 com um certificado de laboratório válido; após a instalação do certificado errado, a verificação do cliente falhou para mx.old.example .test. Todas as verificações de confiança usaram uma CA de laboratório descartável explícita e o nome SNI solicitado. Os carimbos de data/hora preservados identificam as observações. Esses certificados são materiais históricos e não credenciais ou prova da integridade atual do serviço. Eventos de busca HTTPS bem-sucedidos também retêm impressões digitais de certificados; os eventos HTTPS e SMTP com falha retêm os resultados da verificação, mas não contêm impressões digitais do certificado de pares. Isto é uma evidência de handshake isolada e não uma alegação de que um provedor público tem um problema de certificado ou que a renovação do certificado público foi verificada.