Yeah, your original cert folders were a mess so instead of trying to repair them I think it would be easier to get rid of them. I don't want to even try over-writing the originals or to use the certbot delete command as we still might have a mess when we're done.
Easier to delete them all and re-issue those two. The --dry-run just proves all is well.
You can add a -d grembeirn.duckdns.org to the end of each command. It will just avoid being prompted for it. I edited my earlier post to include that so you may have missed it.
Deleted (rm -rf ) the subfolders, did the dry-run first which was successful. Then the actual certificate creation.
Output:
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/grembeirn.duckdns.org/fullchain.pem
Key is saved at: /etc/letsencrypt/live/grembeirn.duckdns.org/privkey.pem
This certificate expires on 2024-06-11.
These files will be updated when the certificate renews.
When checking the certificates, I now get:
sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Python 3.7 support will be dropped in the next planned release of Certbot - please upgrade your Python version.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: grembeirn.duckdns.org
Serial Number: some number
Key Type: ECDSA
Domains: grembeirn.duckdns.org
Expiry Date: 2024-06-11 22:21:51+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/grembeirn.duckdns.org/fullchain.pem
Private Key Path: /etc/letsencrypt/live/grembeirn.duckdns.org/privkey.pem
Guess next step now is to make sure my update script works fine:
sudo /opt/certbot/bin/certbot renew --dns-duckdns-credentials /etc/letsencrypt/renewal/grembeirn.duckdns.org.conf
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Python 3.7 support will be dropped in the next planned release of Certbot - please upgrade your Python version.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/grembeirn.duckdns.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
/etc/letsencrypt/live/grembeirn.duckdns.org/fullchain.pem expires on 2024-06-11 (skipped)
No renewals were attempted.
Oh, you did not run that certbot renew with those duckdns options again did you?
This is the proper way to test
sudo certbot renew --dry-run
And this is the proper way to renew
sudo certbot renew
I hope you didn't damage your certbot renewal config file by running with those duckdns options on that renew. If the renew --dry-run works then I guess we're okay.
I think about 99% of what I type is just muscle memory at this point, and sometimes the nerve signals get crossed. When I switch keyboards, it takes me a few hours to days to mentally "remap" my finger movements by those slight differences.
@MikeMcQ I actually did run it with the duckdns options. Remember, this has been working correctly for the past 2-3 years. So I didn't think of removing it.
Anyway, this is what I get when testing when renewing with --dry-run
In this case seems not to make difference. But, if you ever create another cert on this system it might.
The certbot certonly ... command saves all the needed options in the renewal conf file for that cert.
The certbot renew operates on ALL the renewal conf files using the successful saved options for each. If you supply options with renew those get written to every renewal conf file. This definitely can cause problems if these options contradict the options used when getting these other certs.
It is bad practice to use options with renew. There are some clever one-time uses of options with renew also using --cert-name but this is rare.
Shows we're just human making errors.