I imagine this has been answered multiple times but I’ve not discovered an explicit answer. I expected renew meant leveraging previously submitted and verified proof of domain control/ownership in order to stream line – for end users, intermediaries and Let’s Encrypt – the issuance process. Based on this quote from the Issuance Policies “each renewal will require a new challenge and response” process streamlining is certainly not the objective
So what is a Renewal request used for & why would I (as an end user) ever need it? I see no procedural difference between a new request and a renewal request …
It produced this output:
2023/10/11 15:51:16 [ Crypt::LE client v0.39 started. ]
2023/10/11 15:51:16 Loading an account key from account.key
2023/10/11 15:51:16 Loading a CSR from lacearte_com.csr
2023/10/11 15:51:18 Registering the account key
2023/10/11 15:51:18 The key is already registered. ID: 97159064
2023/10/11 15:51:18 Current contact details: admin@lacearte.com
2023/10/11 15:51:19 Challenge for lacearte.com requires:
A file 'kTPSurhZ7ynK2u2-aGwlLmlRRZwbwwwK9vCYCkC6ymk' in '/.well-known/acme-challenge/' with the text: kTPSurhZ7ynK2u2-aGwlLmlRRZwbwwwK9vCYCkC6ymk.h-uAiUtQ16LOztdVVDhqvt-2Ps4e5HTMF3v0YD6nZD8
2023/10/11 15:51:19 Challenge for www.lacearte.com requires:
A file 'ig-pL5pRUsEEthPpZxyDSR0HSqwusg2IdnHH4fMY1OU' in '/.well-known/acme-challenge/' with the text: ig-pL5pRUsEEthPpZxyDSR0HSqwusg2IdnHH4fMY1OU.h-uAiUtQ16LOztdVVDhqvt-2Ps4e5HTMF3v0YD6nZD8
2023/10/11 15:51:19 Challenge for mail.lacearte.com requires:
A file 'XR-oaauguf47rvBRr6d0gKul2d_RWv0poT-_Sv_nD8Q' in '/.well-known/acme-challenge/' with the text: XR-oaauguf47rvBRr6d0gKul2d_RWv0poT-_Sv_nD8Q.h-uAiUtQ16LOztdVVDhqvt-2Ps4e5HTMF3v0YD6nZD8
2023/10/11 15:52:39 Domain verification results for 'lacearte.com': success
2023/10/11 15:52:39 You can now delete the 'kTPSurhZ7ynK2u2-aGwlLmlRRZwbwwwK9vCYCkC6ymk' file.
2023/10/11 15:52:39 Domain verification results for 'www.lacearte.com': success
2023/10/11 15:52:39 You can now delete the 'ig-pL5pRUsEEthPpZxyDSR0HSqwusg2IdnHH4fMY1OU'' file.
2023/10/11 15:52:39 Domain verification results for 'mail.lacearte.com': success
2023/10/11 15:52:39 You can now delete the 'XR-oaauguf47rvBRr6d0gKul2d_RWv0poT-_Sv_nD8Q' file.
2023/10/11 15:52:39 Requesting domain certificate.
2023/10/11 15:52:39 Requesting issuer's certificate.
2023/10/11 15:52:39 Full certificate chain saved to lacearte_com.crt.
2023/10/11 15:52:39 Let's Encrypt job is done, enjoy your certificate! My web server is (include version):
My hosting provider, if applicable, is: Namecheap
I can login to a root shell on my machine :no
I'm using a control panel to manage my site: cPanel
The version of my client is Crypt::LE client v0.39
Technically it's not different indeed, perhaps except for the definition of e.g. the "duplicate certificate" rate limit, which has, barely, some technical aspects.
But usually it all comes down to terminology which can be helpful to distinguish two separate things, even if they're technically the same.
Mostly (if not all) it comes down how ACME clients work: it's way more user friendly to remember a previously issued certificate for future use, instead of the user having to enter the same commands over and over again. And if an ACME client re-issues a previously already requested certificate, it's very easy to call this process a "renewal". That way everybody knows it's about re-issuing a previously already issued certificate.
For ACME Servers that ratelimit, the above is correct.
For ACME Clients that handle (even basic) certificate management, like Certbot, this is also a "renewal" in the sense that existing services will not need to be reconfigured. For example, Certbot will have nginx/apache utilize the symlinks in the /live/ folder and not the original certificates. When you "renew" the Certificate, the original is stored in /archive/ and the symlinks in /live/ are updated - so no additional work is needed to reconfigure the service.
It's not directly related to certificates, but how Certbot manages its file structure under /etc/letsencrypt/ on *nix file systems. (And maybe on NTFS too, I dunno.) See Symbolic link - Wikipedia for more info.
Certbot used to keep everything, but from some version onwards I believe it only keeps the most recent 5 certs/private keys. At renewal, the oldest gets deleted. Other ACME clients probably have different methods.
There is not much utility in archiving expired certificates indefinitely, but the design and integration of most ACME clients require at least one previous certificate to remain on the system to allow for "rollbacks" when issues occur during the ACME process or anytime thereafter. If the previous certificates were deleted or overwritten with bad data, it may be impossible to restart web services.
Certbot, for example, saves versioned files in /archive and updates the symlinks in /live to reflect the most recent Certificate. Your applications are intended to reference the /live file. If any issues are encountered during the ACME process, the /live/ files are untouched. If you encounter issues after the ACME process, you only need to update the symlinks to reflect the older version.
If the symlinks were deleted and not replaced with fully spec compliant certificates, servers like Apache and Nginx would not be able to boot up and you would need reconfigure them without HTTPS or encounter downtime until you are able to obtain proper certificates.
Also, many users are inexperienced and do not read or understand the documentation and often need to revert to an archived certificate for a random reason (often due to ratelimiting).
@Osiris Oh, ok - I do understand symbolic links/junction points in the Windows context & archival policy looks to be a business decision taken by ACME client developers rather than a standards/regulatory issue. Thanx for the clarification.
