Letsencrypt-auto renew -- All renew attempts failed


#1

Please fill out the fields below so we can help you better.

My domain is:
moneytime.wattstelesales.com

I ran this command:
letsencrypt-auto renew --webroot -w /srv/www/htdocs

It produced this output:

Processing /etc/letsencrypt/renewal/moneytime.wattstelesales.com.conf

2016-07-18 01:31:23,935:WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/moneytime.wattstelesales.com.conf produced an unexpected error: Failed authorization procedure. moneytime.wattstelesales.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://moneytime.wattstelesales.com/.well-known/acme-challenge/tmz6YSb7Vi7TpUZ6BDFSp5hL032Wg6n68lrx2JMf5Xc. Skipping.

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/moneytime.wattstelesales.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: moneytime.wattstelesales.com
    Type: connection
    Detail: Could not connect to
    http://moneytime.wattstelesales.com/.well-known/acme-challenge/tmz6YSb7Vi7TpUZ6BDFSp5hL032Wg6n68lrx2JMf5Xc

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A 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 operating system is (include version):
NAME="openSUSE Leap"
VERSION="42.1"
VERSION_ID="42.1"
PRETTY_NAME="openSUSE Leap 42.1 (x86_64)"
ID=opensuse

My web server is (include version):
Apache/2.4.23 (Linux/SUSE)

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


#2

In response to the suggestion solution:

The DNS A Record is correctly pointing to the server’s public IP address, there’s no firewall (except the server’s own iptables, which is set to allow both port 80 and 443). Browsing to the subdomain in chrome for both http and https works (http redirects to https, though, as per the original setup with letsencrypt)

The cert is now expired, but was working correctly before it expired…


#3

I’m thinking that it is a webroot issue, but I’m not sure how to fix/resolve the issue… This is a Vicibox 7 installation.


#4

I’m unable to connect to 97.76.180.24 on both port 80 and 443. Maybe your ISP is blocking those ports?


#5

Thank you for your response

I suppose, I should have clarified - iptables is allowing those ports for authorized IP addresses (it’s own WAN network is permitted, of course).

Does the process use a 3rd party to connect? If so, what IP address(es) need to be allowed?


#6

I temporarily put it to policy ACCEPT and ACCEPT 0.0.0.0/0 — same results.


#7

Yes, there’s a request from a validation server hosted by Let’s Encrypt. That’s necessary in order to demonstrate domain ownership.

Let’s Encrypt doesn’t publish a set of IP addresses for validation as it is bound to change. It’s possible that validation requests will be sent from multiple, unpredictable IPs in the future, in order to make it harder to spoof validation requests. If you’d like to use the webroot plugin, your domain would have to be publicly available.

As an alternative, you can use a challenge type called DNS-01 that works using TXT records that you need to add to your DNS. This is currently not supported by certbot, but a number of other clients such as the bash clients or lego do support this.

Not sure if you still had that rule up when I tested it, but I still get a timeout. I would recommend testing connectivity via some other network before attempting renewal, to verify your changes are working. You could use a VPS somewhere, or go through Tor.


#8

Try now… I’ll leave it open until your reply. Here’s the output from iptables -nL:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all – 97.76.180.16/28 0.0.0.0/0
ACCEPT all – 97.76.180.24 0.0.0.0/0
[additional ACCEPT rules for remote access]
DROP all – 0.0.0.0/0 0.0.0.0/0 match-set badips src
ACCEPT all – 0.0.0.0/0 0.0.0.0/0
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED
ACCEPT icmp – 0.0.0.0/0 0.0.0.0/0 ctstate RELATED
input_int all – 0.0.0.0/0 0.0.0.0/0
input_ext all – 0.0.0.0/0 0.0.0.0/0
LOG all – 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-IN-ILL-TARGET "
ACCEPT all – 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP)
target prot opt source destination
LOG all – 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-FWD-ILL-ROUTING "

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0

Chain forward_ext (0 references)
target prot opt source destination

Chain forward_int (0 references)
target prot opt source destination

Chain input_ext (1 references)
target prot opt source destination
DROP all – 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 recent: CHECK name: GOOD side: source mask: 255.255.255.255
ACCEPT icmp – 0.0.0.0/0 0.0.0.0/0 icmptype 4
DROP all – 0.0.0.0/0 0.0.0.0/0 PKTTYPE = multicast
DROP all – 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
LOG tcp – 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
LOG icmp – 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
LOG udp – 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 ctstate NEW LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT "
DROP all – 0.0.0.0/0 0.0.0.0/0

Chain input_int (1 references)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0

Chain reject_func (0 references)
target prot opt source destination
REJECT tcp – 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
REJECT udp – 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all – 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable


#9

Ahh found the iptables rule I had missed:

Chain input_ext (1 references)
DROP all – 0.0.0.0/0 0.0.0.0/0

removed that and got:


Processing /etc/letsencrypt/renewal/moneytime.wattstelesales.com.conf


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

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/moneytime.wattstelesales.com/fullchain.pem (success)


#10

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