Unexpected Error during renew - Again

Help
1

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:
kriebel.mooo.com

I ran this command:
sudo certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/kriebel.mooo.com.conf

Failed to renew certificate kriebel.mooo.com with error: Account at /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/xxxx does not exist

All renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/kriebel.mooo.com/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version):
apache2 -v
Server version: Apache/2.4.56 (Raspbian)
Server built: 2023-04-02T03:06:01

The operating system my web server runs on is (include version):
lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

My hosting provider, if applicable, is:
I run this on my own local server (raspberry pi) via dsl router port forwarding from 80 to 62080

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'm using a ssh terminal to connect to the RPi

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot --version
certbot 2.8.0

Additional Infos:

I had a very similar issue in Jan 7th (Unexpected Error during renew). I'm facing the same issue again.
I renewed the certificate on Jan 7th. The next 2 months the cronjob tried to renew twice a day, saying it is too early - as expected. Now it's time to renew and it fails.

Again, same as on Jan 7th the error message saying .../acme-v01.api.letsencrypt.org.. cannot be reached. Of course this fails because this directory doesn't exist. I'm using v02.
This is the content of my kriebel.mooo.com.conf:

version = 2.7.4
archive_dir = /etc/letsencrypt/archive/kriebel.mooo.com
cert = /etc/letsencrypt/live/kriebel.mooo.com/cert.pem
privkey = /etc/letsencrypt/live/kriebel.mooo.com/privkey.pem
chain = /etc/letsencrypt/live/kriebel.mooo.com/chain.pem
fullchain = /etc/letsencrypt/live/kriebel.mooo.com/fullchain.pem

[renewalparams]
account = xxx
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa
http01_port = 62080

This is in the accounts folder:
root@RPi2B:/etc/letsencrypt/accounts# ls
acme-staging-v02.api.letsencrypt.org acme-v02.api.letsencrypt.org

And the last info, not to forget, dryrun works!
sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/kriebel.mooo.com.conf

Simulating renewal of an existing certificate for kriebel.mooo.com

Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/kriebel.mooo.com/fullchain.pem (success)

1 Like
2

@StefanKr using the online tool Let's Debug yields these results https://letsdebug.net/kriebel.mooo.com/1839546

ANotWorking
ERROR
kriebel.mooo.com has an A (IPv4) record (79.202.209.28) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.
Get "http://kriebel.mooo.com/.well-known/acme-challenge/letsdebug-test": dial tcp 79.202.209.28:80: connect: connection refused

Trace:
@0ms: Making a request to http://kriebel.mooo.com/.well-known/acme-challenge/letsdebug-test (using initial IP 79.202.209.28)
@0ms: Dialing 79.202.209.28
@43ms: Experienced error: dial tcp 79.202.209.28:80: connect: connection refused

IssueFromLetsEncrypt
ERROR
A test authorization for kriebel.mooo.com to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.
79.202.209.28: Fetching http://kriebel.mooo.com/.well-known/acme-challenge/Tcp-q9_0iamoWsFJ8faDimsOGZxGm_fhKL2sHicLhkY: Connection refused

Using nmap I see Port 80 is CLOSED; Best Practice - Keep Port 80 Open
The HTTP-01 challenge, of the Challenge Types - Let's Encrypt, REQUIRES access to Port 80.
"The HTTP-01 challenge can only be done on port 80."

$ nmap -Pn -p80,443 kriebel.mooo.com
Starting Nmap 7.80 ( https://nmap.org ) at 2024-03-17 18:47 UTC
Nmap scan report for kriebel.mooo.com (79.202.209.28)
Host is up (0.18s latency).
rDNS record for 79.202.209.28: p4fcad11c.dip0.t-ipconnect.de

PORT    STATE  SERVICE
80/tcp  closed http
443/tcp open   https

Nmap done: 1 IP address (1 host up) scanned in 0.86 seconds
1 Like
3

I suspect the issue is here:
Continuing the discussion from Unexpected Error during renew:

I bet your dsl router presently has Port 80 Closed, it needs to be Open every renewal.

1 Like
4

Hmm. My router forwards requests to port 80 to the RPi Port 62080. If you try to access port 80 on kriebel.mooo.com you certainly won't get an answer because normally there is no service active on RPi on port 62080. Only certbot with option http-port 62080 enables temporary this service.
Were the listed requests extracts from letsencrypt logging, showing the accesses during my renew process?
Doesn't "certbot renew --dry-run" test these accesses? As I wrote this works.

1 Like
5

Yes it would and you are correct about --standalone only being connected when running.

The connection isn't the problem though it is the odd confusion about v01 and v02.

You showed 2 folders with v02 in accounts. Was there also a v01 folder?

Do you have multiple certbot setups maybe with custom locations for things?

There was a bug a while back where if you had a v01 account file around Certbot got confused and used that instead of the v02 one. I don't have any good ideas otherwise I would have posted earlier :slight_smile:

The --dry-run uses the Staging system so uses that account. That only your production cert request fails points to a stray v01 account folder(file).

3 Likes
6

No, I don't have a 01 folder. I remember on my previous error report I had exactly the same issue. It looked like it had been solved by replacing the very old certbot version by an actual one. Unfortunately it gets me again.
I don't have any additional account - or better say: I assume I don't have. I tried so many things to get it working on January...
If you have an idea how to restart everything from scratch, to get rid of this old v1/v2 thing, pls let me know.

1 Like
7

Yeah, I saw your past thread. Didn't see any clues there.

Do you see anything odd with this? Like files with very different timestamps or names?

ls -lR /etc/letsencrypt/accounts

I have just 3 files under my acme-v02.api.letsencrypt.org folder all with same timestamps

3 Likes
8

ls -lR /etc/letsencrypt/accounts
/etc/letsencrypt/accounts:
total 8
drwxr-xr-x 3 root root 4096 Jan 8 15:19 acme-staging-v02.api.letsencrypt.org
drwxr-xr-x 3 root root 4096 Mar 7 14:30 acme-v02.api.letsencrypt.org

/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org:
total 4
drwx------ 3 root root 4096 Jan 8 15:19 directory

/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory:
total 4
drwx------ 2 root root 4096 Jan 8 15:19 xxxxx

/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/xxxxx
total 12
-rw-r--r-- 1 root root 65 Jan 8 15:19 meta.json
-r-------- 1 root root 1632 Jan 8 15:19 private_key.json
-rw-r--r-- 1 root root 87 Jan 8 15:19 regr.json

/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org:
total 4
drwx------ 2 root root 4096 Mar 7 14:30 directory

/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory:
total 0

1 Like
9

Okay I think we found the problem.

The staging folders look correct. But, production has nothing below the directory level. There should be a folder with the same name as in the account= setting in your renewal conf file. And, then similar json files as you see with staging.

In short, the production account info is gone. I think Certbot looked for a v01 after not finding a v02 account which is why the message said v01 was missing.

Failed to renew certificate kriebel.mooo.com with error: Account at /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/xxxx does not exist

The easiest way to correct would be to restore those files from a backup. Do you have one to recover from?

Having to delete files and start over might become messy so before we discuss that let us know about the backups.

2 Likes
10

sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/kriebel.mooo.com.conf

Renewing an existing certificate for kriebel.mooo.com

Congratulations, all renewals succeeded:
/etc/letsencrypt/live/kriebel.mooo.com/fullchain.pem (success)

Thanks a lot! I wonder why it worked in January. I haven't deleted the missing files. Anyway, it works now, hopefully it remains solved. Lets see in about 80 days ...

2 Likes
11

Do the account files show up now?

Hopefully it works in 61 days. The default is to renew with 1/3 of life left with 90 day certs.

2 Likes
12

everything is working now. An additional "certbot renew" says "it's not due" - as expected. Let's see in 61 days. Thanks again!

Do the account files show up now?

What do you mean, which files?

13

The ones that should be in /etc/letsencrypt/accounts that I described as missing earlier

2 Likes
14

Ah ... of course. I recovered them from an old archive. After that it worked.

1 Like
15

You should use the ls command to periodically check that they still exist. It is very strange that they disappeared.

On your prior thread you were running a very old Certbot (very old). I see you upgraded but just make sure you don't accidentally run that old one like using a wrong path or something. If you didn't delete those files that's the only other thing possibly related.

2 Likes
16

I guess it happened all in January during my tests. It could be that I have used accidently an old certbot at after the successful update. All checks I did afterwards where useless because either it said "to early" or used the staged parameters with dry-run. So I was not able to detect that there was still something wrong. Next time it should definitely work. There is no old certbot version anymore on the server, I searched with "find".
Perhaps this is an improvement idea for dry-run: check the neighborhood directory if a real renew would be successful.

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.