On Fri, Dec 19, 2025 at 07:59:56PM +0000, Gellner, Oliver via mailop wrote:
> > {"organization-name":"Mimecast","date-range":{"start-datetime":"2025-12-18T00:00:00Z","end-datetime":"2025-12-18T23:59:59Z"},"contact-info":"[email protected]","report-id":"3cc970363c04eb845df10306264fb5c1e297a8771da2dd52a01ee7440bb298c4","policies":[{"policy":{"policy-type":"sts","policy-string":[],"policy-domain":"charite.de","mx-host":[]},"summary":{"total-successful-session-count":0,"total-failure-session-count":1},"failure-details":[{"result-type":"sts-webpki-invalid","sending-mta-ip":"185.58.85.221","receiving-mx-hostname":"mail-cbf-ext.charite.de.","receiving-mx-helo":"","receiving-ip":"193.175.73.208","failed-session-count":1,"additional-information":"","failure-reason-code":""}]},{"policy":{"policy-type":"no-policy-found","policy-string":[],"policy-domain":"charite.de","mx-host":[]},"summary":{"total-successful-session-count":1,"total-failure-session-count":0},"failure-details":[]}]}
>
> sts-webpki-invalid means Mimecast failed to validate a certificate. As the
> certificates match the hostnames, are neither expired nor revoked, contain
> the EKU server authentication and provide the proper intermediate
> certificates, the only plausible explanation left is that Mimecast is unable
> to chain them back to a trusted root certificate.
> The funny thing is that the software they are using to fetch the MTA-STS
> policy itself is apparently trusting the Hellenic Academic root.
Or perhaps not, if upon retrying they fail to refresh the policy, and
proceed without authentication? In other words, MTA-STS is mere
security-theatre, trivially downgradable by an MiTM attack:
{
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [],
"policy-domain": "charite.de",
"mx-host": []
},
"summary": {
"total-successful-session-count": 0,
"total-failure-session-count": 1
},
"failure-details": [
{
"result-type": "sts-webpki-invalid",
"sending-mta-ip": "185.58.85.221",
"receiving-mx-hostname": "mail-cbf-ext.charite.de.",
"receiving-mx-helo": "",
"receiving-ip": "193.175.73.208",
"failed-session-count": 1,
"additional-information": "",
"failure-reason-code": ""
}
]
},
{
"policy": {
"policy-type": "no-policy-found",
"policy-string": [],
"policy-domain": "charite.de",
"mx-host": []
},
"summary": {
"total-successful-session-count": 1,
"total-failure-session-count": 0
},
"failure-details": []
}
]
}
As indeed fetching the policy does require chaining to the same root CA,
be it perhaps via a different (HTTP, rather than SMTP, over TLS)
software library:
$ curl -vLI https://mta-sts.charite.de/.well-known/mta-sts.txt
...
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 /
id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
* subject: C=DE; ST=Berlin; O=Charite - Universitaetsmedizin Berlin;
CN=mailman.charite.de
* start date: Nov 11 14:46:19 2025 GMT
* expire date: Nov 11 14:46:19 2026 GMT
* subjectAltName: host "mta-sts.charite.de" matched cert's
"mta-sts.charite.de"
* issuer: C=GR; O=Hellenic Academic and Research Institutions CA; CN=GEANT
TLS ECC 1
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128
Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192
Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192
Bits/secBits), signed using ecdsa-with-SHA384
* Connected to mta-sts.charite.de (141.42.206.45) port 443
...
The detail are perhaps illuminating:
$ host=mta-sts.charite.de
$ (
printf "HEAD /.well-known/mta-sts.txt HTTP/1.1\r\n"
printf "Host: %s\r\n\r\n" "$host" |
) |
openssl s_client -connect "$host:443" -showcerts |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin -out /tmp/p7.pem
$ openssl pkcs7 -in /tmp/p7.pem -print_certs -noout
subject=C=DE, ST=Berlin, O=Charite - Universitaetsmedizin Berlin,
CN=mailman.charite.de
issuer=C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS
ECC 1
subject=C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT
TLS ECC 1
issuer=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA
TLS ECC Root CA 2021
subject=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA
TLS ECC Root CA 2021
issuer=C=GR, L=Athens, O=Hellenic Academic and Research Institutions Cert.
Authority, CN=Hellenic Academic and Research Institutions ECC RootCA 2015
$ openssl pkcs7 -in /tmp/p7.pem -print_certs -out /tmp/charite.pem
$ openssl verify \
-trusted /etc/pki/tls/cert.pem \
-untrusted /tmp/charite.pem \
-purpose sslserver \
-verify_hostname "$host" \
-show_chain \
/tmp/charite.pem
/tmp/charite.pem: OK
Chain:
depth=0: C=DE, ST=Berlin, O=Charite - Universitaetsmedizin Berlin,
CN=mailman.charite.de (untrusted)
depth=1: C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT
TLS ECC 1 (untrusted)
depth=2: C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA
TLS ECC Root CA 2021
Now things get a bit interesting, because the chain ends a
trusted-anchor at depth 2, overriding the cross-cert in the
server-provided chain:
$ sed -ne '/HARICA TLS ECC Root CA 2021/,/^$/p' /etc/pki/tls/cert.pem |
openssl x509 -subject -issuer -dates -noout
subject=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA
TLS ECC Root CA 2021
issuer=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA
TLS ECC Root CA 2021
notBefore=Feb 19 11:01:10 2021 GMT
notAfter=Feb 13 11:01:09 2045 GMT
Ralf may find that truncating the SMTP server's chain file at 2
certifiates (EE cert + immediate issuer) gives better results,
the SMTP client in question may not do "trusted first" chain building
and may simply attempt and fail to "extend" the provided chain. It
might however succeed if the extraneous:
subject=C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA
TLS ECC Root CA 2021
issuer=C=GR, L=Athens, O=Hellenic Academic and Research Institutions Cert.
Authority, CN=Hellenic Academic and Research Institutions ECC RootCA 2015
cross-cert is ommitted, its subject is now itself a well known
trust-anchor that does not need a backup cross-issuer.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
