also sprach Viktor Dukhovni <postfix-us...@dukhovni.org> [2017-09-18 00:31 +0200]: > So your certral system generates the keys, and obtains the LE > certificates on behalf of the far-flung hosts? And then pushes > these keys to the hosts over an SSH tunnel? > > Is that only for the initial key issuance? And then each host > rotates the certs independently of the central system using the > existing key to authenticate to LE?
No, they're all managed centrally and pushed regularly. > I am curious why you want to rotate the submission TLS client > keys. If you are able to centrally push keys to the hosts, why > bother with a CA at all? Why not generate a self-signed key+cert, > store the fingerprint in a database, and leave LE out of it? The > key would not change for the lifetime of the host. This is a very good question, and I'm blushing a bit having to admit that I haven't thought of that. Heck, Debian even gives you a free snakeoil cert on installation. I'll totally have to look into it. Thanks for the brainfood. > DNSSEC helps with having CAA records that are difficult to MiTM, > and protectst the DNS challenge protocol, but I don't whether it > is possible to disable bootstrapping over weaker email challenges > and/or control over port 80. This is another excellent point I'lll bring up with the LE folks: if I go through lengths securing my DNS chain for their challenges, I'd like to be able to lock my account onto that, a bit like HSTS. At the moment, I have to assume, however, that LE wouldn't actually care if I requested a cert renewal with a http-01 when I've used dns-01 in the past. Anyway, this is getting vastly off-topic… sorry about that. > I should also note that with LE and certbot's "--csr" option you > can renew LE certificates *without* changing the public key. In > which case the public key fingerprint is stable, and need not > change. Hm, yes, I knew that, but I only just found out that postfix 2.9+ can do check_ccert_access based on the public key fingerprint (not the certificate fingerprint). So that's that then… > The reason I am asking them is not because I've decided to not > implement access by subject name (though given the SAN situation, > and the potentially large number of SANs to test, the feature is > tricky to implement fully and correctly). Indeed, it's not as easy as I had imagined. OTOH, it would not be unfathomable to iterate all SANs and check each against an access map. For sanity, one could introduce an upper bound. And it's a policy decision whether the final decision would be the min or the max of the set of sub-decisions… Thanks a lot for this enlightening exchange. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ takt ist der auf das benehmen angewandte gute geschmack. -- nicolas de chamfort spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
