My domain is: synberc-registry.jbei.org
I ran this command: certbot renew --webroot --agree-tos -w /var/www/letsencrypt
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Processing /etc/letsencrypt/renewal/synberc-registry.jbei.org.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 synberc-registry.jbei.org
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (synberc-registry.jbei.org) from /etc/letsencrypt/renewal/synberc-registry.jbei.org.conf produced an unexpected error: Failed authorization procedure. synberc-registry.jbei.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: During secondary validation: Fetching http://synberc-registry.jbei.org/.well-known/acme-challenge/hIUfbqtJ-F9tBowGfAyGxfmu3c4T4lXW9moGHnyJ3Fk: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/synberc-registry.jbei.org/fullchain.pem (failure)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/synberc-registry.jbei.org/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
-
The following errors were reported by the server:
Domain: synberc-registry.jbei.org
Type: connection
Detail: During secondary validation: Fetching
http://synberc-registry.jbei.org/.well-known/acme-challenge/hIUfbqtJ-F9tBowGfAyGxfmu3c4T4lXW9moGHnyJ3Fk:
Timeout during connect (likely firewall problem)To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My web server is (include version): nginx/1.10.3
The operating system my web server runs on is (include version): debian 9.12
My hosting provider, if applicable, is: N/A
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.28.0
Other notes:
- I am able to connect to http://synberc-registry.jbei.org/.well-known/acme-challenge and retrieve a test file (test.html) from completely outside the environment / firewalls / domain (using curl). Thus it does not, in fact, appear to be a firewall problem, though I cannot completely rule that out.
- We are having an identical issue on multiple hosts, all configured the same (this is the complete nginx config for this host):
=== BEGIN nginx config ===
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80 default_server;
server_name synberc-registry.jbei.org;
location ~ /\.well-known/acme-challenge/ {
root /var/www/letsencrypt;
allow all;
try_files $uri =404;
break;
}
location / { return 301 https://$server_name$request_uri; }
}
server {
listen 443 ssl http2;
server_name synberc-registry.jbei.org;
ssl_certificate /etc/letsencrypt/live/synberc-registry.jbei.org/fullchain.pem;
ssl_trusted_certificate /etc/letsencrypt/live/synberc-registry.jbei.org/chain.pem;
ssl_certificate_key /etc/letsencrypt/live/synberc-registry.jbei.org/privkey.pem;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m; # about 40000 sessions
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
ssl_prefer_server_ciphers off;
ssl_ecdh_curve secp384r1;
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
client_max_body_size 100M;
root /var/www/html;
error_page 502 503 504 /Site_Temporarily_Unavailable.html;
location /Site_Temporarily_Unavailable.html { internal; }
location ~ /\. { return 404; }
location / {
proxy_pass http://tomcat/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
=== END nginx config ===
- a dry-run works fine:
certbot renew --webroot --agree-tos -w /var/www/letsencrypt --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Processing /etc/letsencrypt/renewal/synberc-registry.jbei.org.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 synberc-registry.jbei.org
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Dry run: skipping deploy hook command: /bin/systemctl reload nginx
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/synberc-registry.jbei.org/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/synberc-registry.jbei.org/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- We are also having a similar (identical?) problem with docker nginx instances using the 'jrcs/letsencrypt-nginx-proxy-companion' image
- These renewals have worked in the past
Any help will be most appreciated. Please let me know if you have any questions or need further information.
Thanks / best,
--
Steve Lane
Lawrence Berkeley National Lab