EasyRSA 'renew' does NOT renew, it builds a new certificate *and* key

[TinCanTech]

For true certificate renewal the original key MUST be used.

I intend to remake Easy-RSA renew, as it should have been done in the first place.

renew sucks .. don't use it. -- Until further notice.

If you already did use renew then you can use rewind-renew <serial-number> to undo the damage caused. (Version 3.1x only)

[TinCanTech]

Because easy-rsa/git/master is development code renew ~~is hereby unsupported and will be disabled~~.

~~Until further notice~~.

renew shall remain as-is, instead a new function ~~req-renew~~ renew-req as been written to create a new request from the original key.

[TinCanTech]

If the private key is in the PKI then all is good.

If the private key is not in the PKI then the owner of the key must create a new request.

[ecrist]

So, there's a few things to consider here that aren't currently well supported in EasyRSA:

1. There is not a canonical renew function that uses the old key.
2. Support for signing a naked CSR not generated by EasyRSA is not present
3. CA/sub-CA should be handled different from regular certificates

These three things should be addressed in an update to the renew function. In reality, there really is no "renew" concept, you're just signing a new CSR with the CA/sub-CA.

The private key used MAY NOT be present if there is support for #2 above. This needs to be possible if we are to accept externally provided certificate signing requests. It is best practice that the certificate authority NOT have access to the private key.

Finally, with changes to policy on lifetimes of certificates that are not CA/sub-CA certs, there are different requirements for lifetime, how we handle CRL, etc. Yes, these are "just" certificates, but there is additional data to consider in this case.

Changes to the existing behavior of "renew" function in EasyRSA should not be made until the 3.2.x branch. 3.1.x should retain existing behavior sans bug fixes.

[TinCanTech]

1. There is not a canonical renew function that uses the old key

I have a patch which introduces renew-req, which creates a new request with the original key.

Support for signing a naked CSR not generated by EasyRSA

I don't believe EasyRSA is the right tool for signing requests from unknown sources.

CA/sub-CA should be handled different from regular certificates

Renewing a CA/Sub-CA leaves the user with the same problems as creating a completely new PKI; That is the problem of distributing the new CA certificate to all nodes. IMPO, CA renewal offers almost no advantage over complete PKI recreation.

Changes to the existing behavior of "renew" function in EasyRSA should not be made until the 3.2.x branch

Having created renew-req, renew can remain more-or-less as-is, see below. (Although, I would prefer that renew be renamed to rebuild for semantic accuracy)

3.1.x should retain existing behavior sans bug fixes

One improvement which I intend to make to renew is the use of nopass option.

The simple change is:

• Issue a confirmation that nopass has/has not been used correctly for this renewal, prior to rebuilding the cert/key pair.

This is better than forgetting to use nopass and then breaking out of the script when prompted for an unwanted password. Breaking out of the script at this point leaves the PKI in an undefined state, requiring manual intervention.

Also, it may not possible for easyrsa to determine if the new key should be encrypted because the original key may not be present. It may also be that the new key encrypted state is different to the original.

[dsommers]

Support for signing a naked CSR not generated by EasyRSA

I don't believe EasyRSA is the right tool for signing requests from unknown sources.

That is not correct. Any CA should be able to sign any CSR. The CSR may for security reasons be created on a host not accessible to EasyRSA, where the intention is to not share the private key with anyone else. This may even include private keys stored on Yubikeys or Nitrokeys. In these cases, the client provides the CSR to the CA maintainer, which can use EasyRSA to sign the request and return a signed certificate to be used by the client.

This is essentially the core concept of how any commercial CA operates today.

Otherwise, I do share @ecrist's view. These are all important features to implement correctly in EasyRSA:

[TinCanTech]

Any CA should be able to sign any CSR

OK.

I cannot think of any instances where EasyRSA has not been able to sign a CSR.

[dewydex]

CA/sub-CA should be handled different from regular certificates

Renewing a CA/Sub-CA leaves the user with the same problems as creating a completely new PKI; That is the problem of distributing the new CA certificate to all nodes. IMPO, CA renewal offers almost no advantage over complete PKI recreation.

There's possibly some confusion here regarding especially sub-CA operations. When Easy-RSA (or any CA) issues a subordinate/intermediary CA certificate, it's creating a chain of authority by granting permission for this sub-CA to issue certificates that will be trusted by entities which trust the root CA certificate (such as a root generated by Easy-RSA).

Whereas it is true that these sub-CA certificates need distributed, that distribution can then be "bundled" with other intermediary or leaf certificates (maintaining a "chain"). The issue being hinted at is less about distribution and more about trust, and the key takeaway is that these subordinate\intermediary certificates do not need to be specifically added to trust-stores\registries (the problem with "a completely new PKI"). They are distributed and trusted as part of other certificates in the chain (which may begin with Easy-RSA), and "renewal" in this case pertains to when\where\how these sub-CA's (which may not be Easy-RSA) are allowed to issue new certificates in the chain that will be trusted.

This concept becomes one of Easy-RSA's strengths in general-purpose as having an "offline" CA used exclusively for the creation (and then ideally "renewal") of subordinate\intermediary CA's (which can then be operated in more timely, online, interactive manners) approaches the pinnacle of the use-cases and problem-sets certificate authorities were designed to handle in the larger landscape of diverse technology.

This might border the more "advanced" uses and configurations of Easy-RSA, but this software can and has been used for that exact purpose (quite effectively) in earlier versions. How those use-cases become reflected in future developments may well be in discussion, but the "possibility" of this type of configuration (as an offline root CA) is a notable part of the program's legacy.

[ecrist]

There are assumptions made with "simple" setups and use of EasyRSA that are not going to be true in more advanced deployments. Namely that the CSR comes from the admin signing the certificate, and as an extension, the private key is available. We must assume the we may only have a CSR and no private key. A private key is not needed if we're provided a CSR.

Also, with regard to CA/sub-CA certificates, we need to ensure we aren't signing certificates that are valid longer than the CA doing the signing. It's not up to EasyRSA to be concerned with deployment of CAs and sub-CAs - that's left to the admin.

Finally, there really is no such thing as an actual renewal in PKI - you're just generating a new certificate with the same CN. There are artificial restrictions on duplicate CN within a validity window, but holding on to the idea that we must use the same key isn't how the real world does it.

[dsommers]

Finally, there really is no such thing as an actual renewal in PKI - you're just generating a new certificate with the same CN. There are artificial restrictions on duplicate CN within a validity window, but holding on to the idea that we must use the same key isn't how the real world does it.

A certificate renewal is, as you say, the certificate subject preserved from the prior issued certificate. But the public key in the certificate remains the same; this is the important difference from a new issuance. And naturally the expiry dates are new.

This is an important detail also for sub-CAs. If the sub-CA is not managed directly by the current root-CA, when updating just the sub-CA certificate, the sub-CA can continue signing certificates with the same private sub-CA key. Essentially, the sub-CA can continue to do it's job without changing anything else but its sub-CA certificate.

[TinCanTech]

FTR, while I generally agree with this discussion about CA/sub-CA, I do not accept that EasyRSA renew should be how it is done or even discussed.

EasyRSA renew only deals with server and client certificates.

If EasyRSA is to renew CAs and sub-CAs then that must be another command. eg: renew-ca with option sub-ca.

There can be a unified back-end, if that is possible.

[TinCanTech]

Re-opening for follow up discussion regarding renew-req command. #616

[dekeonus]

I have patched 3.0.8 (was looking at migrating this forward to 3.1.0) for more robust ANY cert type (well not the kdc type) renewals based just upon the existing req (I put subjAltNames in the req, and extract SAN for all but kdc type req), using some awk magic (looking over that awk code I'd say some chaos magic ... was avoiding using Gnu extensions to awk).

The awk compared the extendedKeyUsage and keyUsage for the req with the x509-types/ and IFF there was one match renewed the cert as that match if there was more than one match it printed the matches and directed the user to rerun as renewas <filename_base> [ cmd-opts ]

Also had added a --retire option to revoke and renew(as) which moved the cert,req,key as in the previous behaviour (and automatically did so if the revoke reason was a "compromised" type)

[TinCanTech]

@dekeonus Your comments do not belong on this thread.

Please start a new issue.

~~Your comments here will be deleted.~~

[dekeonus]

@TinCanTech fair enough, delete away. The gist of my comments are relevant to this this thread: A means to renew based upon the existing CSR. I am curious to the reasoning behind requiring generation of a new CSR if the contents will match the old CSR.

I was considering a PR (after I learn how to use github for such), but there's little point cleaning my code up if I will be duplicating / conflicting with what you are coding.

[TinCanTech]

@dekeonus Please start your thread and refer to it here as a linked URL.

Then please, stop bombing other issues.

If you wish to discuss other options then we are available on IRC.

[TinCanTech]

@dekeonus You can open as many new issues as you need to.

__

[TinCanTech]

Summary:

• renew builds a new certificate and key, this will not change.
• renew-req creates a new request from an existing key. v3.1.1+ only.

[hyacin75]

This looks like it was added... and then, removed?

Can anyone shed any light on what happened here?

I'm in the same boat (and from a quick search online, so are many others) ... I can't update all my client certs, especially that they're now disconnected since my server cert expired ... I need to generate a new cert they'll accept and I thought this was the way :-/

[TinCanTech]

This issue has been resolved.

EasyRSA command renew will correctly renew a certificate.

[dekeonus]

@hyacin75

Can anyone shed any light on what happened here?

The original implementation did not renew rather it created an entirely new private + public keypair & CSR & Cert (this functionality, if desired, is still available as rebuild) . The old implementation was less than ideal in cases where users of EasyRSA were generating the CSR outside of the CA (or subCA) working directory (for example using EasyRSA on a target server to generate CSR and importing that CSR into a separate machine running an EasyRSA CA).

The current renew is a renew using the existing (possibly previously imported) CSR.