Hello everyone,
A new member.
How do i find step by step process to renew your certificate? Video and/or document.
Thanks.
1 Like
Welcome to the Let's Encrypt Community! 
A renewal certificate is simply a new certificate covering the same domain names (SANs) as your current certificate. Just repeat whatever you did to acquire your current certificate.
3 Likes
Also, many ACME Clients have renewals built-in. If you answer more of the questions from the form you were shown we could give more specific advice.
================================================
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. https://crt.sh/?q=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:
I ran this command to get my certificate:
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 if you're using Certbot):
4 Likes
Thank you both.
I ran this command to get my certificate: My pervious DevOp set up the certificate for me and he no longer works for us. I don't know what he has done to get the certificate. I got an email from LetsEncrypt (see below please)
My web server is (include version): www.dev.zunuzi.com and dev-classroom.zunuzi.com
The operating system my web server runs on is (include version): Linux
My hosting provider, if applicable, is: AWS
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): I use CMD line
The version of my client is (e.g. output of certbot --version if you're using Certbot):
FYI: I was told I cannot make the renewal automatically in AWS because we turn OFF/ON the server often (it is a development server)
See the email below:
Hello,
Your certificate (or certificates) for the names listed below will expire in 6 days (on 2024-12-11). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors.
We recommend renewing certificates automatically when they have a third of their total lifetime left. For Let's Encrypt's current 90-day certificates, that means renewing 30 days before expiration. See Integration Guide - Let's Encrypt for details.
Some more info below. on www.dev.zunuzi.com (not the other domain)
ubuntu@ip-172-31-104-29:~$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
No renewals were attempted.
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
It seems I need to renew the certificate on both domains?
www.dev.zunuzi.com
dev-classroom.zunuzi.com
these two servers are connected. We turn ON dev-classroom.zunuzi.com when we need it (not too often)
Let's start with www.dev.zunuzi.com. Which I think is misspelled. Isn't it: www-dev.zunuzi.com ?
Also, please show output of this:
sudo certbot certificates
4 Likes
Usually, whatever software is installed to manage your certificates handles everything automatically. It'd be good for you to figure out what software is running on your servers. (Certbot is a popular choice, but there are a lot of others, too.)
That doesn't really make sense to me, and I suspect something was miscommunicated somewhere in the telephone game of how that message got to you. As long as it has persistent storage, then it should check for renewals whenever it's on as needed. (And if you didn't have it on for a long period, then sure a cert would expire, but then once you turned it back on to use it again it should renew again.)
Again, everything should be handled automatically in a well-set-up system. So the first step is figuring out what's currently set up, to figure out what might be misconfigured in it. And ideally whoever is administrating the system will know more about how to figure that out than us random people you're asking on the Internet here, but many people here do an amazing job anyway. 
4 Likes
The dev-classroom IP is an EC2 instance and sounds like they often leave it Stopped. There would be no way for any ACME client to run automatically.
They showed using Certbot but that must not be the dev-classroom machine since it said no cert was due for renewal. And, dev-classroom definitely is due. But, if they use Certbot on one machine they probably do elsewhere.
I should have been clearer that they should start dev-classroom and run sudo certbot certificates and show us that output.
There are both CloudFront and ALB involved somehow based on cert history. But, I'm hoping the dev-classroom is vanilla EC2
5 Likes
Leave it on for more than 12 hours and we'll find out
3 Likes
Probably but not necessarily
4 Likes
Sure. I'm just saying that even if the cert expired due to the system being off, all they'd need to do to get another one is just turn it on again.
Hmm. It'd be smart if the timer/cron/etc. that certbot used knew if the system was starting back up after having been off for more than 12 hours, and run right away once the system turned back on. I'm pretty sure that systemd timers can be configured to do that sort of thing (they're rather powerful), but I don't know if common certbot installation methods actually do.
4 Likes
Probably. But maybe not. We don't know for sure what ACME Client was used or if it was setup for automated renewal. For dev machine even Certbot could just be some --manual method.
4 Likes
Hi Mike,
Here is answer to your question:
ubuntu@ip-172-31-104-29:~$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
No certs found.
ubuntu@ip-172-31-104-29:~$
It seem my previous Devop has set both www-dev.zunuzi.com and 'www.dev.zunuzi'
I appreciate everyone's contribution and support.
Very nice of you.
I try to answer as much as I can.... our dev-op has left and I am not an experienced in AWS and servers. Thanks for your patience.
I will try to 'reply' to your feedback one by one.
1 Like
Alright, let's eliminate this easy one. There is no record of a past cert for www.dev.zunuzi in the public Certificate Transparency (CT) logs. And, there is no A or AAAA record in the public DNS for that name. This looks like an internal use only name. We don't have to worry about a cert for that.
The www-dev.zunuzi.com domain does have a history in the CT logs. And, also has a series of A records that point to an AWS CloudFront endpoint. All the certs were issued by AWS as part of CloudFront. Since the email you got did not mention this domain name we can ignore this for now too. It is possible you have some kind of cert for your Origin server behind CloudFront, that involves more work for you to know the AWS setup.
To recap, for Let's Encrypt purposes, we can ignore those domains even though you have more work to understand what you have inherited.
See my next post about the specific domain from the email.
4 Likes
Did you run that Certbot command on the server that hosts dev-classroom.zunuzi.com? I will assume so.
There is an A record in the public DNS for that domain pointing to an EC2 instance.
But, right now it cannot be reached from the public internet on port 80 or 443 (http or https). So, I can't tell anything about what is running there.
Certbot has no record of current certs but another ACME Client may have been used. Or, even a cert gotten somewhere else and manually copied here.
We need to look at the service that would use that domain's cert. Do you know what is running on that server that uses the cert? Like Apache, nginx, or some other service? We can look at its config and see where the cert files are. From that path we can make good guesses about where they came from.
Or, just start it up and we can poke at it and possibly save some time
Let us know what you can.
4 Likes
Thanks to all ---
We made some progress.
My new DevOP helped me to renew the certificate. Please see below.
Our question is how to verify it?
-=-=-=
sudo certbot renew
-=-=-=-=-=-=the output is
Processing /etc/letsencrypt/renewal/dev-classroom.zunuzi.com.conf
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for dev-classroom.zunuzi.com
Using the webroot path /var/www/bigbluebutton-default for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Running deploy-hook command: systemctl reload nginx
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/dev-classroom.zunuzi.com/fullchain.pem
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/dev-classroom.zunuzi.com/fullchain.pem (success)
ubuntu@ip-172-31-80-244:/etc/letsencrypt/renewal$
2 Likes
Good progress. Connections to that domain from the public internet fail. So, you must connect to it from your local network and check which cert your nginx server returns.
Of course, if you expect this to be on the public internet you need to fix the communications config to allow that.
There are various ways to test from your local network. One is with this:
echo | openssl s_client -connect dev-classroom.zunuzi.com:443 | head -20
Then view the detailed cert info returned. Should be one dated today
3 Likes