Renew certificate with : connection refused


I have an issue when trying to renew a certificate for a subdomain.

The subdomain is The DNS is configured with a A field pointing to the IPV4 of the server, and a AAAA field pointing to the IPV6 of the server.

I run the following command:

# "/root/"/ --cron --home "/root/" 
[Sun 29 Oct 18:03:08 UTC 2017] ===Starting cron===
[Sun 29 Oct 18:03:08 UTC 2017] Renew: ''
[Sun 29 Oct 18:03:08 UTC 2017] Standalone mode.
[Sun 29 Oct 18:03:08 UTC 2017] Single domain=''
[Sun 29 Oct 18:03:08 UTC 2017] Getting domain auth token for each domain
[Sun 29 Oct 18:03:08 UTC 2017] Getting webroot for domain=''
[Sun 29 Oct 18:03:08 UTC 2017] Getting new-authz for domain=''
[Sun 29 Oct 18:03:09 UTC 2017] The new-authz request is ok.
[Sun 29 Oct 18:03:09 UTC 2017]
[Sun 29 Oct 18:03:09 UTC 2017] Standalone mode server
[Sun 29 Oct 18:03:13 UTC 2017] error:Fetching Connection refused
[Sun 29 Oct 18:03:13 UTC 2017] Please check log file for more details: /root/
[Sun 29 Oct 18:03:13 UTC 2017] Error renew
[Sun 29 Oct 18:03:13 UTC 2017] ===End cron===

I checked that the ports 80 and 443 where not opened before issuing the command.
I ran with ‘debug 2’, and it seems that the IPV4 and IPV6 addresses are resolved correctly:

[Sun 29 Oct 17:18:01 UTC 2017] original='{
  "type": "http-01",
  "status": "invalid",
  "error": {
	"type": "urn:acme:error:connection",
	"detail": "Fetching Connection refused",
	"status": 400
  "uri": "",
  "token": "xIyx8EAZZqEgXQ1Xsht_PMuha9S9Wsgk69CuulqjxaM",
  "keyAuthorization": "xIyx8EAZZqEgXQ1Xsht_PMuha9S9Wsgk69CuulqjxaM.tKMlECTPj2H-biJgbo-EPVlhR1R_hWApIyzzQ5XSi8M",
  "validationRecord": [
	  "url": "",
	  "hostname": "",
	  "port": "80",
	  "addressesResolved": [
	  "addressUsed": "",
	  "addressesTried": [

Do you have any idea why the certificate can’t be renewed?


Hi @JF002,

Maybe @Neilpang can help with the issue. I’m wondering why you’re using standalone mode, since it appears you have an nginx server running on this host and listening on port 80. Standalone mode is intended for use on machines that are not running a web server at all, or where the web server has been shut down temporarily. However, I don’t know how to get this problem to correspond to the actual error message you received.

I’m guessing that it may have something to do with the characters in the auth file name. Like maybe the underscore.
Given this should not be a problem.
But your system may be set to handle URLs with certain characters differently or maybe just strips them out.
Of course, any modification would be bad.
So, you can test out that guess by creating a couple of test files and place them in the challenge folder:

  1. test.txt (regular access test)
  2. under_score.txt (special access test)

Be sure to check access from the Internet (and ideally via both IPv6 and IPv4).
If both fail, then the system is not looking for them where you placed them (this is unlikely as it would have returned 404 not 400).
If both work, then my guess was incorrect and I’m out of ideas/guesses (for now).
If the first works and the second fails, then my guess was correct.

But if it’s really using standalone mode, it might not be using the existing web server to serve challenge files at all!

Yes, there is definitely something strange going on here.

It seems that you already have a website on

How can you use the standalone mode ?

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