Can't renew - manual mode errors, but the logs say the error is wrong


#1

Just under three months ago I generated and installed SSL Certs on my website & now it’s time to renew them, but it isn’t working.

I first tried to run “certbot renew” but I got an error that said:

Could not choose appropriate plugin: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('Running manual mode non-interactively is not supported',)
Attempting to renew cert from /etc/letsencrypt/renewal/andrewpometti.com.conf produced an unexpected error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('Running manual mode non-interactively is not supported',). Skipping.

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

Then I tried to run “certbot certonly --manual” that produced this error:

Failed authorization procedure. www.andrewpometti.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to www.andrewpometti.com, andrewpometti.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to andrewpometti.com

HOWEVER, the log file says that it did connect & get the correct verification strings (I redacted the verification strings below):

2017-02-10 21:27:54,154:INFO:certbot.auth_handler:Performing the following challenges:
2017-02-10 21:27:54,163:INFO:certbot.auth_handler:http-01 challenge for andrewpometti.com
2017-02-10 21:27:54,173:INFO:certbot.auth_handler:http-01 challenge for www.andrewpometti.com
2017-02-10 21:28:22,390:DEBUG:acme.challenges:Verifying http-01 at http://andrewpometti.com/.well-known/acme-challenge/[REDACTED]...
2017-02-10 21:28:22,391:INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): andrewpometti.com
2017-02-10 21:28:22,622:DEBUG:requests.packages.urllib3.connectionpool:"GET /.well-known/acme-challenge/[REDACTED] HTTP/1.1" 301 304
2017-02-10 21:28:22,625:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): andrewpometti.com
2017-02-10 21:28:23,283:DEBUG:requests.packages.urllib3.connectionpool:"GET /.well-known/acme-challenge/[REDACTED] HTTP/1.1" 200 107
2017-02-10 21:28:23,358:DEBUG:acme.challenges:Received <Response [200]>: [REDACTED].[REDACTED]. Headers: {'Content-Length': '107', 'Content-Encoding': 'gzip', 'Accept-Ranges': 'bytes', 'Vary': 'Accept-Encoding,User-Agent', 'Keep-Alive': 'timeout=5', 'Server': 'Apache/2.4.23', 'Last-Modified': 'Fri, 10 Feb 2017 21:28:21 GMT', 'Connection': 'Keep-Alive', 'ETag': '"dc1617-57-54833c6e54740-gzip"', 'Date': 'Fri, 10 Feb 2017 21:28:24 GMT'}
2017-02-10 21:28:40,982:DEBUG:acme.challenges:Verifying http-01 at http://www.andrewpometti.com/.well-known/acme-challenge/[REDACTED]...
2017-02-10 21:28:40,984:INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): www.andrewpometti.com
2017-02-10 21:28:46,256:DEBUG:requests.packages.urllib3.connectionpool:"GET /.well-known/acme-challenge/[REDACTED] HTTP/1.1" 301 308
2017-02-10 21:28:46,259:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): www.andrewpometti.com
2017-02-10 21:28:46,751:DEBUG:requests.packages.urllib3.connectionpool:"GET /.well-known/acme-challenge/[REDACTED] HTTP/1.1" 200 107
2017-02-10 21:28:46,757:DEBUG:acme.challenges:Received <Response [200]>: [REDACTED].[REDACTED]. Headers: {'Content-Length': '107', 'Content-Encoding': 'gzip', 'Accept-Ranges': 'bytes', 'Vary': 'Accept-Encoding,User-Agent', 'Keep-Alive': 'timeout=5', 'Server': 'Apache/2.4.23', 'Last-Modified': 'Fri, 10 Feb 2017 21:28:40 GMT', 'Connection': 'Keep-Alive', 'ETag': '"dc1619-57-54833c8073200-gzip"', 'Date': 'Fri, 10 Feb 2017 21:28:47 GMT'}
2017-02-10 21:28:46,758:INFO:certbot.auth_handler:Waiting for verification...

I was able to access the verification files manually. Anyone have any ideas?


#2

It may be that the response isn’t pure text. Tan you add a file called “test” with no extension and only text in it’s content straight text so that it can be reached at http://www.andrewpometti.com/.well-known/acme-challenge/test then confirm that it’s pure text response ( let us know when it’s there so we can test as well ) .


#3

File placed.

Contents of file is “This is test text… this is test text”

The site is setup to redirect HTTP to HTTPS, so this will redirect as well.


#4

Thanks.

The redirect is fine (Let’s Encrypt should follow that).

Can you add

            <LocationMatch "/.well-known/acme-challenge/*">
                Header set Content-Type "text/plain"
            </LocationMatch>

to your apache config, as the reply isn’t currently going out as plain text, then reload apache


#5

It’s GoDaddy shared hosting… I’m pretty sure I can’t reload apache.

Any other way to make sure the file is text?

I just tried to make the file locally & then upload it using different methods

text: http://www.andrewpometti.com/.well-known/acme-challenge/test1
binary: http://www.andrewpometti.com/.well-known/acme-challenge/test2

Do either of those work?


#6

It may be possible in the .htaccess file ( depends if it’s enabled )

can you try adding

<IfModule mod_headers.c>
  Header set Content-Type text/plain
</IfModule>

in the .well-known/acme-challenge/.htaccess


#7

Added /.well-known/acme-challenge/.htaccess containing the specified info.

Did changing the upload mode not work?


#8

That’s showing as plain text now :slight_smile: :slight_smile:

The upload method didn’t make a difference - no.

If you test now obtaining a new cert - what’s the result ? ( if still an error - can you run it with debug option -d ) and paste the letsencrypt debug log ( pastebin.com is probably easiest, then it can just be posted for a short period ).


#9

It didn’t work…

Failed authorization procedure. www.andrewpometti.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to www.andrewpometti.com, andrewpometti.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to andrewpometti.com
IMPORTANT NOTES:
 - The following errors were reported by the server:
   Domain: www.andrewpometti.com
   Type:   connection
   Detail: Could not connect to www.andrewpometti.com
   Domain: andrewpometti.com
   Type:   connection
   Detail: Could not connect to andrewpometti.com
   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.

Log File: http://pastebin.com/kfhd8Gi4


#10
  File "/usr/bin/certbot", line 9, in <module>
    load_entry_point('certbot==0.9.3', 'console_scripts', 'certbot')()
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 776, in main
    return config.func(config, plugins)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 563, in obtain_cert
    action, _ = _auth_from_domains(le_client, config, domains, lineage)
  File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 96, in _auth_from_domains
    renewal.renew_cert(config, domains, le_client, lineage)
  File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 238, in renew_cert
    new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
  File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 253, in obtain_certificate
    self.config.allow_subset_of_names)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 78, in get_authorizations
    self._respond(resp, best_effort)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 135, in _respond
    self._poll_challenges(chall_update, best_effort)
  File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 199, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. www.andrewpometti.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to www.andrewpometti.com, andrewpometti.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to andrewpometti.com
IMPORTANT NOTES:
 - The following errors were reported by the server:
   Domain: www.andrewpometti.com
   Type:   connection
   Detail: Could not connect to www.andrewpometti.com
   Domain: andrewpometti.com
   Type:   connection
   Detail: Could not connect to andrewpometti.com
   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.

#11

Yes, the detailed debug log seems to be saying the same - it couldn’t connect. Have you got a firewall that could be blocking access to certain IP’s ?


#12

There shouldn’t be any IP filtering on the webhost (GoDaddy). cPanel shows No IPs being blocked.

What IPs/ranges should I look in the log files for?

Can you tell where in the process the error is happening? Is it between the virtual machine I’m running at home to generate the certificates and GoDaddy? Between the VM & LetsEncrypt? Between LetsEncrypt & GoDaddy?


#13

What is your setup between the VM that you are using and the actual web pages on godaddy ? I hadn’t spotted you were using a VM - you are copying the token manually to the server are you ?

Let’s Encrypt is trying to connect to 23.229.229.130 (the godaddy server I assume )

Can you see the access logs on godaddy ? can you see any attempts to reach .well-known/acme-challenge …

The check can be done from any IP address.


#14

23.229.229.130 is the GoDaddy Server

When I created the original certificates, I did a copy & paste from the cert into the fields GoDaddy provides for the text of the Certificate (CRT) & Private Key (KEY).

I’m running a Debian 8.7 VM at home. Running “certbot certonly --manual” because “certbot renew” generates the error in the first post. Same VM I used 3 months ago.

I do see hits on the correct file names from yesterday (awstats will update overnight).

The Apache Logs from today
Apache Log: http://pastebin.com/ai6acx5F
Apache SSL Log: http://pastebin.com/tVZjmcrL


#15

That all fits with what I’m seeing in the logs - Let’s Encrypt is connecting on port 80

at 08:22:24 for the recent attempt - and getting a redirect (301)

Looking at the certbot log it get’s the correct redirect.

Yet it fails to connect to your domain on port 443 (https) and doesn’t appear in the log.

@cpu can you see anything from the Let’s Encrypt logs ?

You have until the 22nd before your certificate expires. so there is plenty of time yet.


#16

I’ll put this into my queue but I’m afraid I’m quite backlogged from being out of the office. I’d suggest that @pometti continue to investigate from their side in the meantime. Unfortunately it may be a day or two before I can help. Apologies!


#17

@pometti - are you still having trouble renewing this certificate? I can try to take a look but I want to confirm its still a problem since so much time has passed since you reported. Thanks!


#18

I just tried it again and it worked with zero problems. Installed on the site and running now.

Could I have been trying to renew/re-create too early? I tried to do this on February 10th, but the certificate didn’t expire until the 22nd.

@serverco & @cpu Thanks for all your help. :thumbsup:


#19

Woo hoo! :stars:

Hmm. Doubtful. From the server-side perspective Let’s Encrypt doesn’t have any rules about how soon you can renew a certificate, we just enforce the rate limits.


#20

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