If user interactively opts to change key type, should we skip the reinstall/renew prompt?
alexzorin opened this issue · comments
Say we already have an RSA certificate from pre-2.0 and we do certbot [run/certonly] in 2.0:
# certbot --apache --staging -d parlor-distant.bnr.la
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
An RSA certificate named parlor-distant.bnr.la already exists. Do you want to
update its key type to ECDSA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(U)pdate key type/(K)eep existing key type: u
Certificate not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/parlor-distant.bnr.la.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):
My feeling is that the choice on the first prompt (to update the key type) should provide an automatic answer to the second prompt (replace the certificate).
Choosing Update and then Renew Reinstall doesn't make a lot of sense.
What do you think about this @bmw, in relation to what you wrote in the design document?
If we choose to do this, it should be easy, since _handle_identical_cert_request directly calls _handle_unexpected_key_type_migration. It's more of a question whether we should!
Nice catch! I completely agree with:
My feeling is that the choice on the first prompt (to update the key type) should provide an automatic answer to the second prompt (replace the certificate).
Choosing Update and then Renew doesn't make a lot of sense.