MTA-STS certificate and HTTPS-chain failures

MTA-STS uses two different TLS connections. One fetches the policy from the HTTPS policy host; another protects SMTP delivery to a selected MX. A valid website certificate cannot establish that receiving SMTP is compliant, and a valid SMTP certificate cannot repair a broken policy endpoint.

Name the failing endpoint first

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

For example.com, the policy fetch validates mta-sts.example.com. The certificate must contain a matching DNS identity, be unexpired and chain to a trust anchor accepted by the sending MTA. A CNAME target or redirect destination does not silently replace the policy hostname in this check.

SMTP validation instead checks the selected MX hostname. Also confirm that the hostname matches at least one allowed policy mx pattern. These are distinct comparisons: being allowed by a wildcard policy does not make an unrelated certificate valid. Preserve the selected name, presented chain, verification time and trust-store context.

Diagnose more than expiration

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

A failure can come from an expired leaf, a hostname mismatch, missing or incorrect intermediate certificates, an untrusted chain or an endpoint presenting a default certificate. Test with Server Name Indication set to the policy hostname for HTTPS and to the MX hostname for SMTP. A shared hosting service can present different chains depending on SNI.

Compare observations from the affected sender's environment where possible. Different trust stores or old client software can produce different results. A green browser icon on one workstation is useful evidence for that browser, not a promise that all sending MTAs accept the same chain.

Retain a reproducible probe

Tool reference: OpenSSL 3.5 s_client manual. The installed OpenSSL 3.5.7 help confirms these options; no new endpoint probe is claimed.

For an authorized policy host, substitute the real policy hostname for every POLICY_HOST placeholder:

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

Do not run the placeholder literally. Supply the platform's appropriate trusted CA store when needed. Save stdout, stderr, the OpenSSL version and the verification result. Then retrieve the exact policy URL with a validating HTTPS client, with redirect following disabled, and confirm HTTP 200 and the intended policy body.

For an authorized MX, substitute the actual MX hostname for every MX_HOST placeholder:

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

Use the relevant trust store on both probes. References: RFC 8461 §4.2 and OpenSSL hostname-check semantics. A successful OpenSSL hostname check alone is not proof of MTA-STS compliance: generic hostname verification can fall back to the certificate Common Name when an applicable SAN is absent. RFC 8461 §4.2 specifically requires the SMTP certificate to contain a subject alternative name with a matching DNS-ID. Inspect the certificate SAN separately and confirm the selected MX hostname matches a DNS entry there; do not accept Common Name-only matching as the required SMTP identity check. Also verify the MX against the policy independently. For the HTTPS policy host, RFC 8461 §3.3 allows matching only against DNS-ID identifiers and permits a wildcard only as the complete left-most label, whereas generic OpenSSL defaults can accept partial-label wildcards; treat both probes as diagnostics, not complete MTA-STS certificate-profile validators. An outbound port-25 block in the test environment is a connectivity limitation, not evidence that the remote certificate is broken. No production endpoint was probed. The retained 7 November 2026 certificate-chain observations below were captured against loopback services and were not rerun here.

Repair the chain without weakening the policy claim

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

Install the correct certificate and intermediate chain at the affected endpoint through its approved service workflow. Retest the original name and all relevant addresses. Do not use an insecure fetch as the successful verification result or broaden an MX pattern to hide a certificate mismatch.

A failed refresh does not discard a valid cached policy. Keep that distinction in incident communications: fixing policy HTTPS supports future fetches, while fixing a broken MX may restore compliant delivery for senders enforcing an older policy. Monitor both certificate lifecycles independently.

Retained historical evidence and remaining scope

The following is the retained 7 November 2026 lab record, inspected but not rerun as a network experiment for this review. New offline fixture execution is recorded separately.

The timestamped local trace captured both HTTPS and SMTP hostname failures. HTTPS using the wrong.example.test certificate failed with a hostname mismatch for mta-sts.example.test. An expired certificate failed with certificate has expired. A newly generated valid policy-host certificate then restored HTTPS retrieval. Separately, the SMTP service advertised STARTTLS and first completed TLS 1.3 with a valid lab certificate; after the wrong certificate was installed, client verification failed for mx.old.example.test. All trust checks used an explicit disposable lab CA and the requested SNI name. The preserved timestamps identify the observations. Those certificates are historical fixture material, not credentials or proof of current service health. Successful HTTPS fetch events also retain certificate fingerprints; the failed HTTPS and SMTP events retain verification outcomes but do not contain peer-certificate fingerprints. This is retained isolated handshake evidence, not a claim that a public provider has a certificate problem or that public certificate renewal was verified.