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?
-Dan Mahoney
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
FB: fb.com/DanielMahoneyIV
LI: linkedin.com/in/gushi
Site: http://www.gushi.org
---------------------------
