[nickfrostatx]

One problem I have with this tool is support for pre-computed public keys or CSRs. The client prefers to generate a new key pair for every certificate. Automated renewal that works the same way for existing CSRs as it does for regular certificates requires undocumented hacks.

Using the same key pair for multiple certificates is necessary for public key pinning, since Let's Encrypt only issues certificates that last 90 days. I would love to see this feature get developed further.

[pred_]

It's worth pointing out here that reusing a static keypair with Let's Encrypt is currently more or less straight-forward using acme-tiny.

https://github.com/diafygi/acme-tiny

Edit: Looks like https://github.com/lukas2511/letsencrypt.sh is capable of doing the same, as pointed out in another comment.

[schoen]

There is code in the client to reuse a keypair when renewing (without needing to reuse a CSR); there's just no way to trigger that from the UI so far. Maybe I'd better add one soon.

[pde3]

https://github.com/certbot/certbot/issues/2373 (if you want to reuse a CSR; reusing the key is probably easier)

[theandrewbailey]

> Using the same key pair for multiple certificates is necessary for public key pinning, since Let's Encrypt only issues certificates that last 90 days.

So do like Github does (did?)[0], and make the pins valid for 5 minutes.

[0] looks like they upped it to 60 days?

[oarsinsync]

> So do like Github does (did?)[0], and make the pins valid for 5 minutes.

That kinda defeats the point of HSTS. If the key is changing regularly, it makes it easy for an attacker to just temporarily prevent access to the site for long enough for the pin to timeout, and then present their own certificates and keys.

[pde3]

Perhaps you mean HPKP, not HSTS?

[oarsinsync]

Yes, sorry, HPKP.