On Thu, Oct 10, 2013 at 02:20:40PM -0400, micah wrote:
> For the purposes of better scaling things out, I would prefer to
> maintain a table of certificate fingerprints that I want to deny, rather
> than a table of certificates that I want to allow.
You might think so, but you probably have not fully thought this
through.
> Such a table would
> need to be updated a small fraction of the time that an allow list would
> need to be updated, and would produce the same effect, but more
> efficiently.
It would generally not produce the same effect. Every client with
some random self-signed certificate would be allowed, not just the
ones you issued. The only plausible way to make this work is with:
http://wwwp.postfix.org/postconf.5.html#permit_tls_all_clientcerts
http://wwwp.postfix.org/postconf.5.html#tls_append_default_CA
where all trusted clients are issued from a small set of your own
CAs, exclusively for the purpose of allowing SMTP client access,
you have configured *only* these CAs in smtpd_tls_CAfile and
set tls_append_default_CA=no. Then you can use:
main.cf:
indexed = ${default_database_type}:${config_directory}/
tls_append_default_CA = no
smtpd_tls_fingerprint_digest = sha1
submission_CAfile = ${config_directory}/submission-CAs.pem
submission_restrictions =
check_ccert_access ${indexed}submission-ccerts,
permit_tls_all_clientcerts,
reject
master.cf:
submission inet n ... smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_req_ccert=yes
-o smtpd_tls_CAfile=$submission_CAfile
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=
-o smtpd_recipient_restrictions=$submission_restrictions
-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=
submission-ccerts:
da:39:a3:ee:5e:6b:4b:0d:32:55:bf:ef:95:60:18:90:af:d8:07:09
REJECT client certificate revoked
b7:87:76:f1:1e:a4:17:ae:64:d4:e2:34:92:c9:b2:4a:7b:1b:b5:3b
OK exception to trusted CA constraint
> However, from what I can tell, postfix only has $permit_tls_clientcerts,
> and no $denied_tls_clientcerts. Because I will have a lot of churn with
> new certs being generated continually, I would rather have the
> opposite.
The opposite is still not a good idea. Keep track of what you've issued,
and permit only the ones not revoked. Negative entitlements are fragile.
Failure to properly constrain the trusted CAs will be rather severe
and not easily seen to be a problem when someone is naively trying
to suppress log warnings or similar.
--
Viktor.
