Sent from my iPad
> On Apr 17, 2021, at 14:16, Wietse Venema <wie...@porcupine.org> 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.
Yes, but “signed by this cert, which is on local disk” or “traceable back to
this root cert, which is on local disk” is not. If the feature’s not there,
it’s not there, but this feels possible.
-Dan
