Using Snap, Renewal fails

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: txtechnician.com

I ran this command: sudo certbot renew --dry-run

It produced this output:

myLog.txt (101.5 KB)

2023-04-17 17:23:25,101:DEBUG:certbot._internal.display.obj:Notifying user:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2023-04-17 17:23:25,101:ERROR:certbot._internal.renewal:All simulated renewals failed. The following certificates could not be renewed:
2023-04-17 17:23:25,101:ERROR:certbot._internal.renewal:  /etc/letsencrypt/live/txtechnician.com/fullchain.pem (failure)
2023-04-17 17:23:25,101:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2023-04-17 17:23:25,101:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/snap/certbot/2913/bin/certbot", line 8, in <module>
    sys.exit(main())
  File "/snap/certbot/2913/lib/python3.8/site-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
  File "/snap/certbot/2913/lib/python3.8/site-packages/certbot/_internal/main.py", line 1864, in main
    return config.func(config, plugins)
  File "/snap/certbot/2913/lib/python3.8/site-packages/certbot/_internal/main.py", line 1636, in renew
    renewal.handle_renewal_request(config)
  File "/snap/certbot/2913/lib/python3.8/site-packages/certbot/_internal/renewal.py", line 559, in handle_renewal_request
    raise errors.Error(
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
2023-04-17 17:23:25,101:ERROR:certbot._internal.log:1 renew failure(s), 0 parse failure(s)

My web server is (include version):
nginx
nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version):
Description: Ubuntu 20.04.6 LTS

My hosting provider, if applicable, is:

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):
No

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

Looks like you managed to get a certificate earlier today? crt.sh | 9174657611 You're trying to do a --dry-run now, but for what reason? Just curious.

Also, please provide the entire letsencrypt.log file. The output currently shown does not provide any actual information about the failure unfortunately.

4 Likes

Hi @txtechnician, and welcome to the LE community forum :slight_smile:

Please show the renewal conf file.
Likely: /etc/letsencrypt/renewal/txtechnician.com.conf

3 Likes

The IPv6 path might be broken:

Name:      txtechnician.com
Addresses: 2600:3c00::f03c:93ff:fe95:c6f
           104.237.135.140
curl -Ii4 txtechnician.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 17 Apr 2023 18:25:21 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://txtechnician.com/

curl -Ii6 txtechnician.com
curl: (56) Recv failure: Connection reset by peer

[edit: IPv6 problem was on my side]

3 Likes

I had a problem with the apt version (I was getting an error associated with python, not the same as I am now). So I removed the apt version and switched to snap.

The previous apt version failed yesterday which is what prompted this change.

That is why after installing and implementing the snap version (and renewing) I wanted to test the dry run of the new install to make sure that wouldn't happen agian.

1 Like

Was the apt version fully removed?

And...

3 Likes

I think that might be your IPv6 that's broken or perhaps specifically the path between you and the server. My IPv6 works fine and so does the tests I did using letsdebug.

Makes sense, snap is the prefered method by the Certbot developers.

Anyway, still interested in letsencrypt.log

3 Likes

:man_facepalming:
my bad

2 Likes

:stuck_out_tongue:
Are other IPv6 sites also down for you yes? Or is it the path between you and OPs server specifically?

3 Likes

All IPv6 was down for me :frowning:

4 Likes

In case it was lost in the shuffle, I will ask one last time:

2 Likes
# renew_before_expiry = 30 days
version = 2.5.0
archive_dir = /etc/letsencrypt/archive/txtechnician.com
cert = /etc/letsencrypt/live/txtechnician.com/cert.pem
privkey = /etc/letsencrypt/live/txtechnician.com/privkey.pem
chain = /etc/letsencrypt/live/txtechnician.com/chain.pem
fullchain = /etc/letsencrypt/live/txtechnician.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
account = 682fa4b6352da299741f60cc37ead085
authenticator = nginx
server = https://acme-v02.api.letsencrypt.org/directory
renew_hook = systemctl reload nginx
installer = nginx
key_type = ecdsa

Sorry about the late response.

3 Likes

 

3 Likes

Sorry about that. See attached.
myLog.txt (101.5 KB)

urn:ietf:params:acme:error:serverInternal

This is usually due to some temporary internal issue with the ACME server, not something you can fix from your side.

My advice would be to try again and see what the error is this time, if any.

4 Likes

lol, thanks it works fine.

If the certbot fails in production in this same way. Does it attempt to retry?

1 Like

Check the cron [or systemd timer] entry.

They should be set to run (check) twice a day.

3 Likes

Depends what you mean with "retry". A single run of Certbot won't, but as it's recommended to try to renew twice a day and 30 days before expiry, Certbot will have 60 attempts in total.

5 Likes

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