At a low level, "renewing" a certificate is just a term for generating a new certificate that shares similarities with an older one -- including the same hostnames, usually being issued by the same CA, and sometimes sharing the same keypair. (Certbot uses a new keypair by default.)
The main differences between "renewing a certificate" and "creating a new certificate" are administrative ones for you, the server operator. But a client connecting to your website doesn't know what command you used to issue a certificate, or what file name it's stored in. It just sees the certificate itself.
If you've lost all of /etc/letsencrypt/ except for one certificate and private key, the simple thing to do is just forget about those two files and run the Certbot command you used to create it in the first place, issuing a new certificate with a new key. It would be possible to reconstruct most of /etc/letsencrypt/, but it typically wouldn't be worth the effort.
Why not? What won't they accept? How would "renewing" the certificate be better? Can you explain the setup and what the problem would be?
One month ago, when migrating to K8S / Traefik, this is exactly what I did but my client told me he couldn’t read data because I changed my certs.
Basically, I am sharing an API endpoint with a big electricity supplier, and he has registered the certs I used, so I must stick with the same certs otherwise it would be a not too nice administrative task to update cert on their own.
He shouldn’t have done that. At least not without working it out with you first.
The point of the web PKI is that the only thing hardcoded in clients is the trust roots, and you can issue a new certificate whenever you want, and clients validate them.
You need to ask him what, exactly, he pinned. If he pinned your certificate, you can never renew it. It will expire, and either you have to keep using it, or it will just break.
If he pinned your keypair, or something, then you can renew your certificate as often as you want, as long as you use the same key. (Hope it never gets compromised.) It will be a little tricky to rebuild Certbot’s configuration to do that, but not impossible.
If he pinned the two roots that Let’s Encrypt uses, then you can issue new certificates with or without the same key, as often as you want. Until Let’s Encrypt gets a third root, or you change CAs.
If this is the only client accessing your API, maybe you should switch to a self-signed certificate with a really long lifetime, and then give him the details out-of-band. (And mark both of your calendars to remember to renew it when appropriate.)
Pinning isn’t necessarily a bad idea, but the details have to be worked out carefully. Choosing the right CAs, or creating backup keypairs, and ensuring that you both have a process to update things in the future when necessary.
