Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
*.cs.binghamton.edu
I ran this command:
Certbot renewal with custom deploy hook
It produced this output:
Worked correctly.
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
I just successfully passed through my first automatic renewal for wildcard cert *.cs.binghamton.edu after switching to Let's Encrypt and Certbot. Today I received an expiry reminder stating that the certificate had still not been renewed. The check is apparently based on https://cs.binghamton.edu, but that particular URL is redirected to a server in our parent organization.
crt.sh does in fact show that the cert was renewed.
My question: is there an account setting that would allow me to specify a different URL that would be used for these expiry checks?
You have had several different certificate requests that were not all the same, most likely one of the other requests is what is "expiring" and can be ignored.
How do you mean, "different URL that would be used"? Let's Encrypt does not use an "URL" to check certificate expiration. It just checks its database with previously issued certificates and follows the rules set forth as mentioned in the expiry email documentation which was linked in the email you received.
Back in Jan9-10 you got a cert with the wildcard and its basename.
But, you also got certs with just the wildcard and just the basename. Your email notice is probably about these. It should list the names in the cert it is notifying you about.
In case the hands are moving faster than the eye can see...
If you get a cert for just "A".
And then you get a cert for just "B".
And then you also get a cert with both "A&B". Those are three independent certs.
So, if you only renew the third one [the one with "A&B"], then the first two will eventually trigger their expiration notices; as they are independent of / unrelated to each other.
Thank you for the many responses. Back in early January I was trying to figure it all out - Certbot, Let's Encrypt Wildcard requests, DNS validation, the deployment hook script. I think I didn't realize I had created so many certs at that point.
The certificate I really wanted is *.cs.binghamton.edu. Certbot's 60 day timeout expired around March 9, but I had bugs in my deployment script. Now that I've got those worked out, I guess I'll be waiting until early May. By then all of those other certificates should hopefully expire and go away.
Regarding the expiry warnings, I'm glad to know that it's just by scanning your databases rather than by checking that the cert got successfully deployed. I got fooled by the 'cs.binghamton.edu' in the notice.
One point: The documentation for the Deployment Hook scripts mentioned a couple environment variables that would be set before calling the script, but I couldn't find where it describes what they'd be set to and what I would find there. I also couldn't find a way to force an early renewal so I could debug my script right away, so I had to wait 60 days.
Admittedly, I'm running the CertBot package from Debian 11 (version1.12.0-2). I expect to be upgraded to Debian 12 before the next Certbot renewal.
Which documentation exactly and could you perhaps tell us what wasn't exactly clear to you? And perhaps what you'd like to know? So we could suggest improvements to the Certbot team.
Please see the certbot --help all information about --dry-run.
The documentation for the Deployment Hook scripts mentioned a couple environment variables that would be set before calling the script, but I couldn't find where it describes what they'd be set to and what I would find there.
Which documentation exactly and could you perhaps tell us what wasn't exactly clear to you? And perhaps what you'd like to know? So we could suggest improvements to the Certbot team.
I'm referring to RENEWED_LINEAGE and RENEWED_DOMAIN. No search I did defined the value of these at the point where the deploy hook is invoked. More to the point, the general file structure of /etc/letsencrypt/live and /etc/letsencrypt/archive. Importantly, that the contents of 'live' are symlinks and that a deploy hook script based on the contents of 'live' might need to dereference these before copying them.
bingocs:
I also couldn't find a way to force an early renewal so I could debug my script right away, so I had to wait 60 days.
Please see the certbot --help all information about --dry-run.
--dry-run focuses on the interaction with the Let's Encrypt servers to generate a new certificate by generating a temporary. What I was looking for was a way to retrieve a live certificate and deploy it, or specifically a way to 'move the clock forward' so the certbot.timer kicks off a full live renewal at a time like '2 minutes from now', including running the deploy hook scripts. I didn't see a way to do this, but this would have allowed me to debug my deploy script sooner than 60 days after I wrote it.
For this command,
the shell variable $RENEWED_LINEAGE will point to the
config live subdirectory (for example,
"/etc/letsencrypt/live/example.com") containing the
new certificates and keys
Sounds pretty explanatory to me.
That's not explained in the documentation indeed. I guess it wasn't deemed important. E.g. cp dereferences symlinks by default.
What's wrong with using the staging environment (instead of wasting production environment resources) and run the deploy hook with the existing cert by using --dry-run in combination with --run-deploy-hooks? Did you even look at the --dry-run documentation as I mentioned?
Sorry. I didn't mean to come off harsh. I did this back in January and it went a bit rough for me for whatever reason. I was also under the gun since my Comodo cert was about to expire and I really wanted to make the switch to Let's Encrypt.
I'm glad that what I was looking for is actually in the documentation. I think I probably stayed with the docs for the version I was using because sometimes when one reads the docs for a different version it leads to trying things that aren't in the version that's installed.
I do wish I had found my way to this mailing list back in January. Too much of a hurry.
| 
bingocs: