renew-req does not work from the CA signing side PKI

[TinCanTech]

When the private key is located at a remote location and renew-req is used at the remote location then renew-req works correctly:

• Remote renew-req generates a New CSR with the original key - Original CSR is over-written.
• New CSR is sent to the CA.
• CA revokes the old certificate - Original CSR and signed-cert are moved to pki/revoked.
• CA imports the New CSR.
• CA signs the new CSR - New certificate is signed.
• New certificate is sent back to the remote.

This does not work when the private key is located at the CA location:

• CA renew-req generates a New CSR with the original key - Original CSR is over-written.
• The CA cannot sign the New CSR because the original signed-cert exists in pki/issued.
• CA revokes the old certificate - New CSR, signed-cert and private key are moved to pki/revoked.
  The New CSR and original private key should not be moved to pki/revoked.
• CA cannot sign the New CSR.

The obvious fix appears to be new command option keep-key, eg:

• revoke client1 keep-key [reason] - Original CSR and signed-cert are moved to pki/revoked.
• CA renew-req generates a New CSR with the original key.
• CA signs the New CSR with the original key - New certificate is signed.
• New certificate is ready for use.

[TinCanTech]

CA end renew-req should follow renew: Use pki/renewed. [Solution]

Simply keep the private key in place.

[dekeonus]

I think this is an issue with revoke, not so much renew-req.
what about easyrsa --no-retire revoke client1 [reason] though I would have preferred the inverse, but changing that will break current workflows (i.e. explicitly --retire reqs/keys; and auto --retire on keyCompromise,CACompromise,cessationOfOperation).

I do wonder if re-signing an identical req is worth the cogitative load: The user already generated the req with the correct subject (and sAN and other exts) and there are no date-stamps in the req.
This becomes more of a pressing concern when the end-entity key-pair is actually stored on a HSM, this destroy req and regen thus means faffing about getting the HSM to sign/generate a new request - which in a plain renewal case, will have identical information as the destroyed one.

[TinCanTech]

#616

renew-req also forgot nopass.

[TinCanTech]

renew-req is a new feature for version 3.1.1.

Currently, this only works for a remote CSR and private key.
The CA signing party cannot use this part of the tool chain.

Article docs/EasyRSA-renewal.md is required.

[dekeonus]

In the remote case I'm not sure renew-req will get much use. For example in my own workflow I wouldn't use it - the CSRs I have are all fine as they are. They are "remote" from the signing CA view. (However a modify-req might be useful to say add/remove sANs)
For the current implementation¹ of revoke & renew I perform (on the signing CA):

• easyrsa revoke [basename] superseded the old cert
• easyrsa import-req [path/to/req] [basename] with the existing CSR
• easyrsa sign-req [type] [basename] to "renew" the certificate
• easyrsa gen-crl
• export certs and restart services
• export crl

I'm not sure what benefits renew-req provides for me: It's certainly less convenient as I would need the private passphrase for the end-entity certs (rather than just the keys and passphrases for the signing CA).

¹ or that's what I would do if I hadn't patched in a --retire(/--no-retire) so that the CSR didn't get moved during the revoke stage (or as the case truly is: the renew-as sub-command). This is similar to the workflow I used prior to 3.0.6 (no need to re-import the req as revoke did not move any files, and sign-req over wrote the issued/basename.crt).

[TinCanTech]

The idea of renew-req is to do exactly what you are doing. Just I was looking at it back-to-front.

This can be corrected soon enough. Leaving the milestone as-is.

[TinCanTech]

Closed via #685