Certbot renew fails, dry-run works. 403 permission?

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: www.hokyi.com

I ran this command: certbot renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/hokyi.com.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Running pre-hook command: service nginx stop
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for hokyi.com
http-01 challenge for www.hokyi.com
Waiting for verification…
Cleaning up challenges
Attempting to renew cert (hokyi.com) from /etc/letsencrypt/renewal/hokyi.com.conf produced an unexpected error: Failed authorization procedure. hokyi.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://hokyi.com/.well-known/acme-challenge/SesNzbgXopmtehsMx8pKQp9Oe1lvDWhvvys1A41Cc0A: Connection refused, www.hokyi.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.hokyi.com/.well-known/acme-challenge/06oPiJFwN5zEcsJgcETb-4Za4bFNKmBAS72OWUw5fJo: Connection refused. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/hokyi.com/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/hokyi.com/fullchain.pem (failure)


Running post-hook command: service nginx start
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

My web server is (include version):

nginx -v
nginx version: nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version):

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

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 0.31.0

===

dry-run works fine:

certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/hokyi.com.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Running pre-hook command: service nginx stop
Renewing an existing certificate


new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/hokyi.com/fullchain.pem



** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/hokyi.com/fullchain.pem (success)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


===

A file placed in webroot (/var/www/html/ttt) can be retrieved:
https://hokyi.com/.well-known/acme-challenge/ttt

1 Like

Hi @dtdt

looks like a blocking firewall or a geoblocking.

Check your system if there is such a thing.

Letsencrypt doesn’t see the redirect http -> https, so the first connect is impossible.

1 Like

thanks @JuergenAuer,
not geoblocking; using firewall, port 80 open.

ufw status | grep '^80 '
80                         ALLOW       Anywhere                  
80 (v6)                    ALLOW       Anywhere (v6)  

even with http -> https redirect turned off in nginx, same pattern is true - that is dry-run works, actual renew fails.

server {
        listen 80;
        listen [::]:80;
        server_name hokyi.com www.hokyi.com;
        location ~ /\.well-known/acme-challenge/ {
            allow all;
            root /var/www/html;
        }
}
1 Like

local_path unix_permissions
/var/www drwxr-xr-x
/var/www/html drwxr-xr-x
/var/www/html/.well-known drwxr-xr-x
/var/www/html/.well-known/acme-challenge drwxrwxrwx
/var/www/html/.well-known/acme-challenge/ttt -rw-r–r--

===

main differences between verbose logs of dry-run and prod:

POST to acme/new-order acme-staging-v02.api vs acme-v02.api
dry-run: status: ready
prod: status: pending

POST to acme/authz-v3 acme-staging-v02.api vs acme-v02.api
dry-run: status: valid, with validationRecord (addressResolved) for http-01, no challenges for dns or tls
prod: status: pending for http-01, dns-01, and tls-alpn-01 challenges, no addressResolved

staging next POST is to acme/finalize, prod to acme/chall-v3
staging: valid
prod: pending

prod next POST to acme/auth-v3 again
this time, status invalid, connection refused fetching .well-known/acme-challenge: 400, addressResolved,

http-01 for staging is “valid”, with url in validationRecord that includes .well-known/acme-challenge. http-01 for prod is “pending” then “invalid”

1 Like

The webroot plugin requires that a web server be running.

1 Like

got new machine with upgraded os. created new cert. dry-run renew looks fine.

1 Like

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