also sprach Viktor Dukhovni <postfix-us...@dukhovni.org> [2017-09-17 18:09 +0200]: > Can you explain your use-case in a bit more detail? What sort of > SMTP clients are these, that they authenticate using TLS client > certificates not issued by a CA you control and you're then > providing submission access to said clients based on their domain > as found in the certificate CN?
I have three distinct use-cases, but they're all more or less the same, involving 107 hosts altogether spread across the globe in untrusted networks, often with weird firewalling or other policies. There are several hundreds of users making use of cron and other things that basically require sendmail on each host. To keep our sanity, we currently have it such that all hosts forward their mail to a smarthost via the submission port, TLS-secured, and authenticated with the TLS cert fingerprint (using check_ccert_access). Our recent move to Letsencrypt means that the hosts now get new client certificates every 2–3 months. At the moment, this means we have to update the check_ccert_access map on the smarthost once almost every day with new fingerprint. Of course one could automate this, or switch to password authentication, but in thinking about this, I was wondering: Given that we trust Letsencrypt (for benefit of doubt) — Given that LE's challenge-response means that only we can issue certs that contain example.org in the CN or SubjectAltNames list — Why do I have to give postfix the fingerprints. Wouldn't it be just as safe and a lot easier to say "certs matching¹ .example.org issued by LE" and be done with it. Does that make it a bit clearer? ¹) see discussion on canonical identity and SubjAltNames lists below > Keep in mind that DNS names stored as the CommonName of the > certificate subject DN is a deprecated representation of the > client identity. Interesting, I didn't know that. I'll do some research. > Though most CAs have not yet stopped putting nonempty subject DNs > in certificates, the right place for certificate names is the > subjectAlternativeName extension, which bears zero or more DNS > names and perhaps names of other types too. So there exists no longer a canonical name/identity of a certificate? I am well aware of SubjectAltNames, but I am unsure they're ordered, or whether there even exists such a convention that e.g. the first one is the primary name. In the present technical approach I'm proposing, the lack of a canonical identity would mean that postfix would actually have to check every single one of the SubjectAltNames against an access map, which may cause problems depending on the length of this list,² and may well render this approach meaningless. ²) I've seen certs with dozens, maybe even >100 SubjAltNames… Obviously, one solution would be to create an intermediary CA that we control. However, I think that's just asking for trouble. For one, trust chains longer than 2 expose some nasty bugs in most server and client implementations, and second, Letsencrypt doesn't support that anyway I don't think, and we don't want to go back to the X.509 Mafia. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "of course the music is a great difficulty. you see, if one plays good music, people don't listen, and if one plays bad music people don't talk." -- oscar wilde spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
