Hello, As far as I can tell, postfix can authenticate its clients using certificates in two ways:
check_ccert_access (also permit_tls_clientcerts), which authorizes clients based on the cert fingerprint; permit_tls_all_clientcerts, which authorizes clients if they present a cert signed by a specific CA; We've been using the former for years, requiring us to manually deploy the new fingerprints every two years. But we've now migrated to Letsencrypt, and doing so every two months won't work anymore. Furthermore, we can't just trust all certs issued by Letsencrypt, nor is it feasible to introduce a custom CA just for this purpose. So we can now either automate the deployment of fingerprints, surely, but I was also wondering if it weren't possible to add the following functionality to postfix: Either extend check_ccert_access or introduce a new access map, which takes the CN from the client cert and maps it to a CA identifier. E.g. .example.org /etc/ssl/certs/DST_Root_CA_X3.pem meaning that if a client presents a certificate who's CN is a subdomain of example.org, and the certificate trust chain is complete up until the certificate provided in /etc/ssl/certs/DST_Root_CA_X3.pem, then grant access. This would allow users to easily grant access to all hosts in their subdomain, even if the certs are issued by a common CA such as Letsencrypt. The match on the cert CN should be sufficient to guard against abuse. What do you think? -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "god is a comedian playing to an audience too afraid to laugh." -- voltaire spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
