Am 2023-11-30 18:36, schrieb Viktor Dukhovni via Postfix-users:
On Thu, Nov 30, 2023 at 03:37:02PM +0100, Alexander Leidinger via Postfix-users wrote:> > Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate > > verification failed for in-9.smtp.github.com[140.82.112.31]:25: > > num=62:hostname mismatch > > That is the error.Indeed that's the issue. The SANs in the certificate don't match the name matching settings for this destination.> The hostname your TLS configuration is probably expecting for that > connection is reply.github.com, but that's apparently just a mail > domain, not a hostname, and the machines acting as MXs for it don't use > a certificate with that name. Why should it expect reply.github.com?Because that name is securely known from the recipient address.
But it doesn't matter. If I use a commercial spam filter solution in the cloud, I would have to set my MX to a hostname I can't control and which is not in any relation to my own domain name. If then someone send mails to alexan...@leidinger.net, why should it match the hostname against leidinger.net? My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net, and I expect the sending MTA to match the hostname in the MX against the SAN of the cert. I do not expect it to match against leidinger.net. If I set the MX of leidinger.net to smtp.google.com, I expect the delivering MTA to check the SAN against smtp.google.com, and not against leidinger.net. How else can you use a Google workspace offering as a MX for your own domain (https://support.google.com/a/answer/9222085?hl=en#zippy=%2Cstep-sign-in-to-your-domain-host%2Cstep-add-the-mx-record)?
The MX record lists in-9.smtp.github.com as a MX,http://www.postfix.org/TLS_README.html#client_tls_limits The MX hostname is typically obtained via an insecure (subjet to MiTM tampering) DNS lookup, so you lose all security when validating certificates against the payloads of MX records.
You (and the link) are talking about trust. I talk about the technical operation of establishing a TLS connection and verifying the certificate. The validation itself has nothing to do with trust. The technical operation takes a hostname to validate the SAN in the cert against, and a cert-chain to validate it against. Trust is orthogonal to this. I agree with all what is written in the link and what you said about insecure (if no DNSSEC is used), but this is trust, not technical validation.
The technical problem I have is that postfix seems to use parts of the cert store (it validates the MX of FreeBSD, but not the MX of github), whereas posttls-finger uses the complete cert store. As answered to Wietse, the cert store is readable no permission problem, no user access problem, no security polcies, no chroot. He didn't tell that posttls-finger uses a different validation policy than postfix. If I understand it correctly: if both have the same access to the cert store and the network, they should produce the same result (valid or not valid). They don't. I want to solve this technical problem and let them both agree, that the cert is valid (which it is, the SAN of the MX of github has *.smtp.github.com, and this is a match from a certificate validation point of view with the hostname the MX presents).
This has nothing to do with the email address I want to deliver to this server.See above. You're missing the point.
I agree that we are talking about 2 different things. Please tell me what is wrong about: - the MX of domain A.c points to a.B.c- a sending MTA has to take a.B.c and match it against the SAN the server a.B.c provides (ignoring details of doing a reverse lookup and resolving the resulting IP and validating that too)
In HTTP the name to match against what is provided by the user in the URL, in SMTP it is the MX, as the domain part of the email address is not at all significant for the name of the MX (see above the Google workspace example).
So there is a mismatch between postfix and postls-finger on a TLS connection level which to my understanding shall not happen.No, there's a mismatch between the configuration of your Postfix SMTP client and what you posttls-finger was asked to do.
That's the reason why I come her and ask what I do wrong. I agree that there is a difference between the operation of both. I want to have both to agree. What do I have to do to the MTA, to let it agree with the result of posttls-finger? Where shall I look for which problem? Which part of my config is affecting that and should check for X or provide for inspection? What can I do to drill down more? Tracing which part of postfix (ktrace (like strace), dtrace... whatever), looking for what action/access/...?
smtp_tls_policy_maps = hash:/my/tls_policy, mysql:/my/tls-policy.cfThis must be matching "reply.github.com" directly or as ".github.com".smtp_tls_security_level = maySince delivery was deferred when TLS authentication failed, you were notactually using "may", so the policy table MUST be matching the destination.
You are correct, I overlooked a line in the DB. Connections to github have a "secure" policy. This explains why it fails instead of delivering anyway, but this is not my concern. What I care about currently is the validation of the TLS part of the work postfix has to do.
Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
