On Mon, Sep 18, 2017 at 10:09:14PM +0200, martin f krafft wrote:
> > 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.
So, though this is not your best option, you can centrally capture
the updated fingerprints and automate their deployment (along with
the most recent previous fingerprint to avoid race conditions).
> > 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.
That should address your problem. You can think of these are
complex passwords, where the server only knows the hash. You'd
get the same security with a SASL password database that used
decently hashed passwords as a backend. I agree that public key
fingerprints are easier to manage, as that gets SASL out of the
way.
> 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.
I'd also be curious to know the answer to that. Please follow-up
if you find out. I'm sure that enough folks here use LE certs to
justify a slightly off-topic post.
> > 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 Postfix fingerprint security level does not distinguish between
certificate fingerprints and public key fingerprints. It is assumed
computationally infeasible to take a given public key and construct
a certificate with the same hash. That'd be a 2nd pre-image attack,
and none are known even for MD5 at present. So the client is
accepted when the key in the lookup table matches either the
certificate or the public key.
I think I made the right call, a non-negligible number of DANE
users initially get confused about the "selector" field, and publish
the certificate digests along the public key selector (SPKI(1)
instead of Cert(0)).
> 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…
Yes, that's possible, but not architecturally appealing. We could
default the limit to say 10, and if the client has more than 10
names process none of them. I'd not be a fan of processing just
a subset.
All that said, the case for submission based on CA authenticated
key -> name bindings is not looking too strong. This is not going
to have a significant priority unless a more compelling use-case
shows up.
--
Viktor.
