On 4/17/21 5:15 PM, Wietse Venema wrote: > Dan Mahoney (Gushi): >> All, >> >> The dayjob has a number of machines out in the wild that need to be able >> to send mail (mostly from cron jobs) home to the mothership. Not all have >> controllable reverse DNS. It's an issue with donated colo and transit. >> Doing a bunch of tunnels would work but it's a really stupid answer. >> >> We'd like to use client-certs as an auth mechanism. We're already >> deploying trusted client certs for use with puppet, so we have a full CA >> setup already in place. If we trust any cert signed by our puppetmaster's >> CA (which uses a root/intermediate/leaf setup for signing) we should be >> golden. >> >> However, reading the postfix docs >> (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see >> warnings that one should not use permit_tls_all_clientcerts for something >> like that. If an outside client were to connect with (say) a let's >> encrypt cert configured as a client cert (which we may want to *validate*, >> but *not permit for relaying*, that cert would allow relay) >> >> It seems that There are knobs that let you list *individual certs* for >> allowing trusted relaying, but not *individual ca's*. >> >> Is there any way around this? > > Yes: handle that traffic with a dedicated smtpd instance that only > trusts your internal root. > > Postfix check_ccert_access currently supports matches based on > certificate fingerprint and public key fingerprint. The other > available attributes, issuer name and subject name, are too soft > for security decisions. > > Wietse
Would it be possible to support trusting based on subject alt name? I would like a machine with a certificate for a.example.com to send mail from a.example.com domains. Sincerely, Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
