Certbot SSL Renewal - same expiration date

Help
1

Hello. Attempting to renew a certificate with an upcoming expiration date of January 28, 2023. I ran the certbot renewal request, certificate came back without error but the renewal date is the same expiration date I already have. Why? Thanks.

My domain is:
allanimals.info

I ran this command:
sudo certbot certonly --force-renewal --key-type rsa --preferred-chain "ISRG Root X1"

It produced this output:
Successfully received certificate.
Renewal date: 2023-01-28 (this was the previous date, renewing to get a new date)

I can login to a root shell on my machine (yes or no, or I don't know):
Yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
1.32.2

2

Please don't use that option without proper knowledge: if Certbot said it was successful earlier, but you think something went wrong, forcing another renewal is not going to change anything at all. Only add more load on the Let's Encrypt systems and risk running into rate limits.

Please show the output of:

certbot certificates
4 Likes
3

Thank you for your reply Osiris.

It was my understanding that was the option you use to renew a certificate. My current certificate is fine, no errors, website works, etc. I was just attempting to renew early, as requested by the automated email system.

certbot certificates output:

Renewal configuration file /etc/letsencrypt/renewal/mail.allanimals.info-0001.conf produced an unexpected error: expected /etc/letsencrypt/live/mail.allanimals.info-0001/cert.pem to be a symlink. Skipping.
Renewal configuration file /etc/letsencrypt/renewal/mail.allanimals.info.conf produced an unexpected error: fullchain does not match cert + chain for mail.allanimals.info!. Skipping.

The following renewal configurations were invalid:
/etc/letsencrypt/renewal/mail.allanimals.info-0001.conf
/etc/letsencrypt/renewal/mail.allanimals.info.conf

4

If you do want to renew a specific certificate manually, you can use certbot certonly --force-renew and specify all of the associated domain names with -d (e.g., certbot certonly --force-renew -d example.com -d www.example.com if both of those names are part of the certificate).

5

For regular renewals, you can just run sudo certbot renew, which ideally should be done twice a day using a cronjob or systemd timer. If the cert is up for renewal, it will renew. If not, certbot will continue without renewing.

What do you call "early"? If Let's Encrypt send you an expiry warning, you are already late. Let's Encrytpt recommends to renew 30 days before expiry, i.e., 60 days into the certificate, so you have enough days left to fix a possible problem. Certbot will start to try to renew 30 days before expiry too when using certbot renew.

That doesn't look very good.

That's a very specific situation (different than just renewing) and might not even be required any longer with up to date versions of Certbot.

4 Likes
6

  1. sudo certbot renew - ok, I will try that

  2. Early = 30 days prior to expiration. Let's Encrypt sent me an email saying it will expire 1/28/23 (obviously not 30 days anymore, but still early)

  3. Renewal configuration files - please elaborate - why do I have those errors when everything is working? Could it be due to the force-renewal or failed renewal? If so, why did the force-renewal succeed (just with the same date)?

  4. I have not looked yet, but if you care to explain the harm "--force-renewal" poses I would be interested.

  5. Why run sudo certbot renew twice a day? That seems like overkill and a definite load on Let's Encrypt servers. Millions of hits a day (from all those that use Let's Encrypt) just to see if the cert has expired or is up for renewal? Just set a cronjob to run it once a day ** starting ** 30 days before. That should be plenty of time to perform the renewal, no?

Thanks. :slight_smile:

1 Like
7

certbot itself loop though certificate it manage and won't call LE server unless there is certificate running out of time (not sure what exactly they check: but in effect 30 days before expire i think)

BTW your certbot config dir is tainted (broken symlink)
@_az is there a command for recover or reset from such state?

4 Likes
8

30 days prior to expiration is right on time. See When to Renew.

I have no idea, but it looks like everything is not working? Usually the sudo certbot certificates command provides a list of certificates known to Certbot. Not a bunch of errors.

Maybe you needed to use sudo in front of it, I dunno, you could try that again.

No, such errors are not due to something Certbot did itself.

Maybe because sudo was lacking in front of the command, worth a try to try again with sudo.

See Rate Limits - Let's Encrypt.

Also, every issuance of a certificate costs load on the Let's Encrypt systems. Not only at issuance itself, but also for the OCSP status which need to be updated regularly. If a forced renewal isn't necessary, then the increased costs on the LE systems was also not necessary. So one shouldn't renew forcibly unnecessarily.

As orangepizza already stated: Certbot won't connect to the LE systems unless a certificate is actually due for renewal if you use sudo certbot renew. You shouldn't use sudo certbot certonly ... for renewal, especially not in a cronjob or systemd timer. By the way, depending on how you installed Certbot, most distributions automatically install a cronjob or systemd timer.

5 Likes
9

We seem to have different meanings for "early".
Early = prior to expiry?
Early = prior to normal renewal?

If your web service is using the cert associated with that broken one, then it will continue to show the wrong cert [not the one being updated].
You need to show which is the location of the updated cert:
sudo certbot certificates
Then you need to find the location being used by your web server:
[presumably Apache - if so, start with]
apachectl -t -D DUMP_VHOSTS
[otherwise, if nginx, try]
nginx -T | grep -i ssl_certificate_key
[otherwise, refer to your software documentation]

3 Likes
10

Hello again. Thanks for your help in our previous conversation.

I had tried "certbot renew" and it failed saying the config was invalid (as mentioned previously). So, I renamed the "letsencrypt" directory in an attempt to "start fresh" and attempted to renew the certificate with the --force-renewal we had talked about previously. I received the following error.

===================
2023-01-25 10:09:30,118:ERROR:certbot._internal.log:Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: mail.allanimals.info, retry after 2023-01-23T01:56:09Z: see Duplicate Certificate Limit - Let's Encrypt

This was last week. I waited until just now (1/25/23) to attempt it again. I received the same error (only tried it once) with the date now updated to 2023-01-26.

The expiration date is 2023-01-28. I could wait until then (which luckily is the weekend) and a) try it on 2023-01-29 AFTER the expiration OR revoke the certificate(s) and attempt to get a new one.

The problem I forsee is a continual error of too many certificates and then having none, which would cause problems.

I would appreciate any insight into a) fixing the certificate problems I currently have, somehow resetting them? or b) telling me how to restart this process properly and then in the future just using "certbot renew" as I should have in the first place.

Thanks for your help. :slight_smile:

12

Revoking will NOT reset anything.
[it will only nullify an existing cert]

You misunderstand where the certs are being counted.
The count is of issued certs.
If you delete them, OR even format your server, they are still issued.
Nothing can change that,

You should do all your testing on the staging environment - not on the production environment.

A cert was issued yesterday...
Where did that one go?
crt.sh | allanimals.info

4 Likes
13

I don't think anybody advised the use of --force-renewal? Unfortunately, you clearly don't yet understand the function of this option. Please explain, so I can understand the thought process better, how the use of --force-renewal would help if you started "fresh", i.e., there was nothing to renew yet?

I'd advice to put back the renamed letsencrypt directory and simply use the cert issued yesterday.

3 Likes
14

Great question rg305, I have no idea where it went nor that it was even issued.

Last week I attempted to renew the certificate incorrectly, as Osiris indicated. The "certbot renew" didn't work because of broken path (as shown above) and the "forced renewal" indicated too many certs issued so I had to wait until 2023-01-23. I did nothing else with that server until today.

From my understanding certbot has its own cron job that continually tries to renew, I did not shut that off (didn't even think about it at the time) but last week "certbot renew" wasn't working anyway and didn't work when I tried it a few hours ago (2023-01-25) so I wouldn't think it would have worked while I waited for time to pass.

The certificate on the site shows an expiration date of 2023-01-28 so obviously I have not applied that cert to the server even though somehow it apparently exists.

Osiris - you are correct, I am obviously not understanding this process. My concept of "--force-renewal" was to request a new certificate that was not expired yet from the Let's Encrypt server which should have no bearing on whether I have a "letsencrypt" directory on MY server (as rg305 said) which I understand. The two servers are not directly linked. Rather, per my current understanding, my server uses the certificate given to me by the Let's Encrypt server. So, if I removed (renamed) the local letsencrypt directory AND since my current certificate (so I thought since there were errors from Let's Encrypt saying I had to wait) had not yet expired, a "--force-renewal" would invalidate the current certificate (not set to expire until 2023-01-28) and give me a new one.

I hope this fully explains my thought process so you can better direct me and fix my erroneous knowledge. :slight_smile: Really. :slight_smile: I would appreciate it.

And, apparently, I now have another problem. Since there IS a new certificate I need to manually get it and manually put it into the proper place(s) on my local server to make it work.

I had tried that once when I setup this server because I had had an existing valid certificate (not Let's Encrypt) but that was not successful. I deleted it and started over, but that was 7 months ago.

Besides the above, any recommendations or step-by-step instructions on the insertion of an existing certificate would be greatly appreciated as well.

Thanks for your continued help and support! :slight_smile:

2 Likes
15

If that's not a symlink, something did changes to your certificate directory that is not Certbot. Your best option would probably really be to start fresh, which means that after removing/renaming /etc/letsencrypt, you should request a new certificate the normal way.

"manually" is almost always a bad word in conjunction with Certbot, and should you have made any changes to anything inside /etc/letsencrypt/, that's most likely the reason for your troubles. You should either make your server just use the files in /etc/letsencrypt/live/ or use a deploy-hook script to copy/convert/assemble them somewhere else.

Regarding the process, you should be aware that a certificate can not really be 'renewed' at all. It's just a term used by Certbot to request another certificate with the same options as a previous one. The closest to an actual 'renewal' you can get, is to re-use the private key. But you will always get a new certificate, with different data and fingerprint, while the old one expires.

I would say it depends on the number of domains you host on your server. If it's only a handful, running it once a week should be enough. But if you have thousands of customers you might want to run it at least twice a day to distribute the load.

3 Likes
16

Let's Debug is showing a MultipleIPAddressDiscrepancy WARNING

1 Like
17

Supplemental information

$ curl -Ii http://allanimals.info/.well-known/acme-challenge/sometestfile
HTTP/1.1 405 Not Allowed
Server: awselb/2.0
Date: Wed, 25 Jan 2023 18:02:39 GMT
Content-Length: 0
Connection: keep-alive
WAFRule: 0

$ curl http://allanimals.info/.well-known/acme-challenge/sometestfile
<!DOCTYPE HTML><html lang='en-us'><head><title>** Not Found **</title></head><body>HTTP Status: 404 (not found)</body></html>


$ curl -Ii http://allanimals.info/
HTTP/1.1 405 Not Allowed
Server: awselb/2.0
Date: Wed, 25 Jan 2023 17:57:05 GMT
Content-Length: 0
Connection: keep-alive
WAFRule: 0

$ curl http://allanimals.info/
<a href="http://www.aavh-wbac.com/">Moved Permanently</a>.

$ curl -Ii http://www.aavh-wbac.com/
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://www.aavh-wbac.com/
Strict-Transport-Security: max-age=3600
X-Wix-Request-Id: 1674669499.39710970061629501
Cache-Control: public,max-age=0,must-revalidate
X-Content-Type-Options: nosniff
Server: Pepyaka/1.19.10
Accept-Ranges: bytes
Date: Wed, 25 Jan 2023 17:58:19 GMT
Age: 141
X-Served-By: cache-bfi-krnt7300108-BFI
X-Cache: MISS
Server-Timing: cache;desc=hit, varnish;desc=hit_miss, dc;desc=fastly_g
X-Seen-By: yvSunuo/8ld62ehjr5B7kA==,hb2+EPh7fPdW2+vqbvCmcanPWIDxfKj16yM6xXYJ3IE=,GXNXSWFXisshliUcwO20NRcK6V7vsjtRMMlpoARJlDRwfzADlQ/r2n59vfTm4/t0,m0j2EEknGIVUW/liY8BLLsF6ZK0ExZ9qybsUJ5Iw3hMm++C2XkuTvnlRFg2XiSDL,2d58ifebGbosy5xc+FRalj1D5o1b/ULQ8AVr+i7HANTX4Tzd14TkZSlnzn0mDSdwLkHxEguY+tPF7wgKjEJ4QQ==,2UNV7KOq4oGjA5+PKsX47O/TogA2Hpa7nDF3Wje4FGVjPZTuGyYqVhtmEIgJUb4w
Via: 1.1 google


$ curl -Ii https://www.aavh-wbac.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
link: <https://static.parastorage.com/>; rel=preconnect; crossorigin;,<https://static.parastorage.com/>; rel=preconnect;,<https://static.wixstatic.com/>; rel=preconnect; crossorigin;,<https://static.wixstatic.com/>; rel=preconnect;,<https://siteassets.parastorage.com>; rel=preconnect; crossorigin;,
etag: W/"b9a7e00a4d22e39ed9b91bd89018e38d"
content-language: en
strict-transport-security: max-age=3600
x-wix-request-id: 1674669514.0041097011042717680
cache-control: public,max-age=0,must-revalidate
x-content-type-options: nosniff
server: Pepyaka/1.19.10
accept-ranges: bytes
date: Wed, 25 Jan 2023 17:58:34 GMT
age: 141151
x-served-by: cache-bfi-krnt7300103-BFI
x-cache: MISS
vary: Accept-Encoding
server-timing: cache;desc=hit, varnish;desc=hit_miss, dc;desc=fastly_g
set-cookie: ssr-caching=cache#desc=hit#varnish=hit_miss#dc#desc=fastly_g; max-age=20
x-seen-by: yvSunuo/8ld62ehjr5B7kA==,tHzHG6QeSsyukPkElY9D5KnPWIDxfKj16yM6xXYJ3IE=,GXNXSWFXisshliUcwO20NRcK6V7vsjtRMMlpoARJlDQpGwmKW1/FIGVl292+hbWq,m0j2EEknGIVUW/liY8BLLrKlzeGrau08OveYR7mXfKcG/hKs8AeY1T4OIbgnD+yx,2d58ifebGbosy5xc+FRalj1D5o1b/ULQ8AVr+i7HANTX4Tzd14TkZSlnzn0mDSdwLkHxEguY+tPF7wgKjEJ4QQ==,2UNV7KOq4oGjA5+PKsX47O6uVG6buAunlWjI2L90d5VjPZTuGyYqVhtmEIgJUb4w
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
1 Like
18

Are you only interested in a cert for mail.allanimals.info ?

Because that is the only cert I see for your domain that expires on that date (crt.sh link here)

And, there are more than 10 certs for that name more recent than that. You are getting them nearly daily since Jan15. You have no trouble getting certs but are not correctly updating your mail server to use them.

4 Likes
19

Here is some info on the mail certificate: Hardenize Report: mail.allanimals.info and SSL Server Test: mail.allanimals.info (Powered by Qualys SSL Labs)

1 Like
20

Thank you for your replies.

  1. I have nothing running, to my knowledge, that is continually requesting new certificates for the domain "mail.allanimals.info" I don't know how those certificates are being requested.

  2. The only domain I need a certificate for is "mail.allanimals.info"

  3. The are two servers, one is a self-hosted email server "mail.allanimals.info" and the other is a webserver on a cloud hosting account. The mailserver does NOT have port 80 open except when having to fire up a standalone webserver for verification purposes by certbot/let's encrypt.

Requests:

  1. I would be happy to take the latest valid certificate and use that one, if someone could direct me to the information I need to "install" it properly.

  2. How do I find out how my server (assuming it is my server) is making these nearly daily requests and stop it? Just yesterday I disabled the snapd service/dameon so certbot would not run automatically. Maybe that is what has been running? Maybe it is attempting to renew on a cron job, the renewal fails, it thinks the failure is external so it does it again?

Thanks.

2 Likes
22

#1 I'd check cron jobs, systemd timers, and certbot log file to ensure the system responding to port 80 at the IP for "mail.allanimals.info" is not somehow still renewing that cert via HTTP-01 authentication.

#2 that makes this simple[r].

#3 they have nothing to do with each other's cert requests [unless they do so via DNS-01 authentication].

#4 install it where?

#5 see answer #1

2 Likes