Failed authorization procedure Connection refused

Hi bmw, this is the result of the execution

sudo certbot certonly --standalone -d --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1):
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for
Waiting for verification…
Cleaning up challenges

The dry run was successful.
Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.

Well that’s interesting! Thanks for the additional info. I have one idea for a way to work around the problem and another idea on how to debug it further.

The workaround is to try adding --preferred-challenges http to the command line. This will cause Certbot to use a different challenge type which might work better for your setup.

My best solution to help debug the problem is a little trickier. First, run sudo certbot certonly --standalone -d --debug-challenges --verbose. This will cause to print a lot of output to the terminal as well as stop with the message:

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
Press Enter to Continue

When you see this, on another machine run:

openssl s_client -connect -servername foo

You should see something like the following output from Certbot:

Performing handshake with ('::ffff:', 12345, 0, 0)
Server name (foo) not recognized, dropping SSL

If you don’t, something is preventing the request from getting to Certbot.

If you see that output, hit enter on your terminal running Certbot to have it continue. In the output immediately after pressing enter, you should see output like:

JWS payload:
  "keyAuthorization": "WKzRwxWSbT8sXWbP0Uza8Whb5i69VdGch26BFrvt6qM.qlCO-llhghLuz3W3Wk82B6PmWgycWFnRHW0Y76uixHA", 
  "type": "tls-sni-01", 
  "resource": "challenge"

You’ll probably have to scroll back up to see this because Certbot generates a lot of output in this mode. What you want here is the value of the keyAuthorization after the . character. For the above value, this is qlCO-llhghLuz3W3Wk82B6PmWgycWFnRHW0Y76uixHA.

Make a note of this value and run Certbot again with the same command. In the output shortly before Certbot stops again, you should see output like:

  "identifier": {
    "type": "dns",
    "value": ""
  "status": "pending",
  "expires": "2017-11-06T20:59:13.60235025Z",
  "challenges": [
      "type": "dns-01",
      "status": "pending",
      "uri": "",
      "token": "sbPnxEw5_48Zv9UQ7ZBpkewasUKicGw_ffX4MIh6y3g"
      "type": "http-01",
      "status": "pending",
      "uri": "",
      "token": "n-yKedsuggIzArF18wOXD211bpJ4u9rtVCjSb_xH8WM"
      "type": "tls-sni-01",
      "status": "pending",
      "uri": "",
      "token": "N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI"
  "combinations": [

Here what you want is the token for the token for the “tls-sni-01” challenge. From the output above, that would be N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI.

Using these two values, you can construct what name Let’s Encrypt is looking for in the certificate. Concatenate this token value to the value you obtained before, adding a “.” in the middle. Using these example values, this would be:


Now to construct the value Let’s Encrypt is looking for, run the following command replacing <ka> with the long value you just constructed:

 echo -n <ka> | sha256sum | cut -f 1 -d ' ' | sed -e 's/^\(.\{32\}\)/\1./' -e 's/$/.acme.invalid/'

Continuing with the example values, this would give you:


This would be the name Let’s Encrypt is looking for in the certificate. On another machine, run:

openssl s_client -connect -servername <domain>

where domain is the output of the shell command above. When you do this, if you haven’t made any mistakes and I haven’t made any mistakes in my explanation, you should see something like:

Performing handshake with ('::ffff:', 123456, 0, 0)
::ffff: - - Incoming request

output from Certbot and output from openssl s_client that starts with:

depth=0 CN = dummy

Hopefully the --preferred-challenges workaround is enough, however, I would be interested in knowing where you start seeing different output when following my lengthy debugging process.

I hope this helps!


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