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
