4 ms·

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. Automate

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.

schoen 10y ago
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 10y ago
https://github.com/certbot/certbot/issues/2373 https://github.com/certbot/certbot/issues/2373 (if you want to reuse a CSR; reusing the key is probably easier)
pred_ 10y ago
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 https://github.com/diafygi/acme-tiny Edit: Looks like https://github.com/lukas2511/letsencrypt.sh https://github.com/lukas2511/letsencrypt.sh is capable of doing the same, as pointed out in another comment.
theandrewbailey 10y ago
> 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 10y ago
  > 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 10y ago
    Perhaps you mean HPKP, not HSTS?
    - oarsinsync 10y ago
      Yes, sorry, HPKP.

schoen 10y ago

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 10y ago

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

pred_ 10y ago

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 https://github.com/diafygi/acme-tiny Edit: Looks like https://github.com/lukas2511/letsencrypt.sh https://github.com/lukas2511/letsencrypt.sh is capable of doing the same, as pointed out in another comment.

theandrewbailey 10y ago

> 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 10y ago
> 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 10y ago
  Perhaps you mean HPKP, not HSTS?
  - oarsinsync 10y ago
    Yes, sorry, HPKP.