Planned updates and enhancements

[mholt]

A few things that could use enhancing:

Issuer load balancing

CertMagic currently tries issuers in order to get a certificate, and later ones are only fallbacks. This is already more than most certificate automators do, but load balancing would be a useful option: still fall back if one is down, but first choose (randomly? round-robin?) from among the selection rather than always trying the first one first.

For renewals, CertMagic tries the same issuer as last time, if configured/present. But this could also be load-balanced.

Private key rotation

Currently, CertMagic reuses the private key when renewing a certificate. This is the expected behavior most of the time, but can be problematic if the key is compromised (without knowing; CertMagic will already replace a private key if a certificate is revoked with reason keyCompromise, but this seldom if ever happens in practice). If the key was compromised by unauthorized access to storage, for example, rotating the key will simply give the attacker the new key. If the compromise is known, the cert will typically be revoked.

One argument is made against this: that the hole may be patched serendipitously, i.e. via felix culpa, such as applying a system upgrade or fixing an ACL. You didn't know a leak occurred but you fixed it anyway. In that case the cert would not be revoked, but it would still be useful to rotate the key.

Probably these days, CertMagic should use new keys for every cert rather than reusing keys.

ARI

ACME Renewal Information or ARI is an extension to ACME that hints at when to renew a certificate. I have mixed feelings on the utility of this extension, and I think it is unfortunate that it complicates already-complex infrastructure regarding revocation, which is broken anyway, and should be phased out in favor short-lived certificates instead.

Brief digression: If ARI tells you to renew early, the server may optionally include a URL which explains the reason. If the reason is impending revocation, then why continue to trust the certificate at all? If you know it will be revoked, the certificate might as well not be trusted. Or maybe the reason is to smooth out load; only respectful clients will do this anyway, and I don't know if it will help the stampeding herd problem that CAs sometimes face. But anyways...

We can support ARI to be a good Internet citizen.

[francislavoie]

My thoughts:

• Regarding issuers, I agree in theory that load balancing would be a good idea, but in practice (in the case of Caddy anyway), ZeroSSL has been somewhat less reliable than Let's Encrypt, so it feels better to use as a fallback rather than a "shared primary".

• Regarding private keys, it might also be a good time to support Allow configuration of private keys to use your own for TLS management caddy#2854 which would help with things like key pinning, and to do that they need the server to be using a consistent well-known key, instead of a generated one. Of course that means that it's the user's responsibility to rotate the key if it gets compromised.

• Regarding ARI, I agree. Unfortunate, but we should still do it.

  I would hope that your errata https://www.rfc-editor.org/errata/eid6317 would get reviewed and implemented, since that would help alleviate pressure on ACME servers with those changes, since we're forced to be wasteful with API calls.

[mholt]

Thanks for your thoughts, Francis:

so it feels better to use as a fallback rather than a "shared primary".

Yeah, or maybe configurable policies... simpler than a reverse proxy's, but, like: "first", "first_random", and "first_round_robin".

Regarding private keys, it might also be a good time to support caddyserver/caddy#2854 which would help with things like key pinning, and to do that they need the server to be using a consistent well-known key, instead of a generated one.

Ok, I'll look into that.

Regarding ARI,

See below...

An update

• Issuer LB and private key rotation are still planned. Heck, maybe I should just do those this week and get them done.

• ARI is shelved indefinitely. I tentatively added support for it into ACMEz, but stopped when I got to CertMagic due to unresolved questions where currently, ARI does not make any sense as-is. I suspect a fundamental re-thinking of a solution may be needed.

[francislavoie]

Yeah, the load balancing policy approach is a good idea 👍 I think first is probably the best default for Caddy FWIW, but allowing that to be configurable is great. You might want to consider allowing fallback policies for policy chaining, similar to what we just implemented in caddyserver/caddy#5488

[mholt]

Ok cool -- I've implemented this, and decided to skip "round_robin" for now, since I'm not sure what utility that really has, especially given that configs are short-lived/ephemeral.

Just going to start simple for now. By default, the current behavior is the same: try each issuer in turn. You can configure "first random" which shuffles the list, then tries each issuer in turn.

Since ARI is on hold, I'm going to close this issue and we can open a new one if the spec evolves or there is something actionable to do there.

[oliverpool]

I just had an idea regarding ARI (probably not the best place to discuss about this, but I value your feedback), would it be imaginable to put the information about "renewal window" into the OCSP response?

Since (according to Wikipedia) the OCSP responder is typically run by the certificate issuer, it could give the info if a renewal should occur soon.

[oliverpool]

This has already been discussed: https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/

(sorry for the noise)

[mholt]

It's alright, I appreciate careful thinking like that!

[mholt]

New issue tracking ARI: #284