Failed authorization procedure Connection refused

What command did you run to get the single name cert?

Hi, i run

certbot certonly --standalone -d cupon2go.com

hi i run
certbot certonly --standalone -d cupon2go.com

(please retype them new or copy from this screen - do not reuse your pre-existing code)
Please try:
certbot certonly --standalone -d www.cupon2go.com
and also:
certbot certonly --standalone -d cupon2go.com -d cupon2go.com

Hi i run the following commmands:

sudo certbot certonly --standalone -d www.cupon2go.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for www.cupon2go.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.cupon2go.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.cupon2go.com
    Type: connection
    Detail: Timeout

    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.

sudo certbot certonly --standalone -d cupon2go.com

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t clos
e to expiry.
(ref: /etc/letsencrypt/renewal/cupon2go.com.conf)
What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for cupon2go.com
Waiting for verification…
Cleaning up challenges
IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/cupon2go.com/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/cupon2go.com/privkey.pem
    Your cert will expire on 2018-01-28. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    "certbot renew"
  • If you like Certbot, please consider supporting our work by:
    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

I have never seen this before!

@cpu, could you see what it looks like from the server side (do these names resolve to the same IP address?)? You wouldn’t be able to test the actual TCP connection because @mexicanobermudez is using standalone, so the listener isn’t active all of the time.

Maybe there’s something from the existing settings that’s different when you do the renewal as opposed to getting a fresh certificate. Could you post the contents of the file /etc/letsencrypt/renewal/cupon2go.com.conf?

Sure

The content of /etc/letsencrypt/renewal/cupon2go.com.conf:

renew_before_expiry = 30 days
version = 0.18.1
archive_dir = /etc/letsencrypt/archive/cupon2go.com
cert = /etc/letsencrypt/live/cupon2go.com/cert.pem
privkey = /etc/letsencrypt/live/cupon2go.com/privkey.pem
chain = /etc/letsencrypt/live/cupon2go.com/chain.pem
fullchain = /etc/letsencrypt/live/cupon2go.com/fullchain.pem

Options used in the renewal process
[renewalparams]
authenticator = standalone
installer = None
account = 2c69d1d1f5d5246e139933435ddfc3f2

@bmw, can you think of a reason why Certbot would start a different kind of standalone listener with the certbot certonly renewal here vs. with the certbot certonly fresh cert issuance? I can’t think of a plausible reason, but the CA seems to find a TCP listener listening in one case and not in the other, on the same host with names that resolve to the same address.

FYI i add the trace for resolution of each domain

Tracing DNS delegation for “www.cupon2go.com”:

Loading root server list (static data):
-> a.root-servers. net (198.41.0.4)
-> b.root-servers. net (192.228.79.201)
-> c.root-servers. net (192.33.4.12)
-> d.root-servers. net (128.8.10.90)
-> e.root-servers. net (192.203.230.10)
-> f.root-servers. net (192.5.5.241)
-> g.root-servers. net (192.112.36.4)
-> h.root-servers. net (128.63.2.53)
-> i.root-servers. net (192.36.148.17)
-> j.root-servers. net (192.58.128.30)
-> k.root-servers. net (193.0.14.129)
-> l.root-servers. net (199.7.83.42)
-> m.root-servers. net (202.12.27.33)
Sending request to “k.root-servers. net” (193.0.14.129)
Received referral response - DNS servers for “com”:
-> a.gtld-servers. net (192.5.6.30)
-> b.gtld-servers. net (192.33.14.30)
-> c.gtld-servers. net (192.26.92.30)
-> d.gtld-servers. net (192.31.80.30)
-> e.gtld-servers. net (192.12.94.30)
-> f.gtld-servers. net (192.35.51.30)
-> g.gtld-servers. net (192.42.93.30)
-> h.gtld-servers. net (192.54.112.30)
-> i.gtld-servers. net (192.43.172.30)
-> j.gtld-servers. net (192.48.79.30)
-> k.gtld-servers. net (192.52.178.30)
-> l.gtld-servers. net (192.41.162.30)
-> m.gtld-servers. net (192.55.83.30)
Sending request to “l.gtld-servers. net” (192.41.162.30)
Received referral response - DNS servers for “cupon2go.com”:
-> ns-cloud-c1.googledomains. com (216.239.32.108)
-> ns-cloud-c2.googledomains .com (216.239.34.108)
-> ns-cloud-c3.googledomains. com (216.239.36.108)
-> ns-cloud-c4.googledomains .com (216.239.38.108)
Sending request to “ns-cloud-c4.googledomains. com” (216.239.38.108)
Received authoritative (AA) response:
-> Answer: A-record for www.cupon2go.com = 35.202.242.4

Tracing DNS delegation for “cupon2go.com”:

Loading root server list (static data):
-> a.root-servers. net (198.41.0.4)
-> b.root-servers. net (192.228.79.201)
-> c.root-servers. net (192.33.4.12)
-> d.root-servers. net (128.8.10.90)
-> e.root-servers. net (192.203.230.10)
-> f.root-servers. net (192.5.5.241)
-> g.root-servers. net (192.112.36.4)
-> h.root-servers. net (128.63.2.53)
-> i.root-servers. net (192.36.148.17)
-> j.root-servers. net (192.58.128.30)
-> k.root-servers. net (193.0.14.129)
-> l.root-servers. net (199.7.83.42)
-> m.root-servers. net (202.12.27.33)
Sending request to “f.root-servers. net” (192.5.5.241)
Received referral response - DNS servers for “com”:
-> l.gtld-servers. net (192.41.162.30)
-> b.gtld-servers. net (192.33.14.30)
-> c.gtld-servers. net (192.26.92.30)
-> d.gtld-servers. net (192.31.80.30)
-> e.gtld-servers. net (192.12.94.30)
-> f.gtld-servers. net (192.35.51.30)
-> g.gtld-servers. net (no IP address)
-> a.gtld-servers. net (no IP address)
-> h.gtld-servers. net (no IP address)
-> i.gtld-servers. net (no IP address)
-> j.gtld-servers. net (no IP address)
-> k.gtld-servers. net (no IP address)
-> m.gtld-servers. net (no IP address)
Sending request to “c.gtld-servers. net” (192.26.92.30)
Received referral response - DNS servers for “cupon2go.com”:
-> ns-cloud-c1.googledomains. com (216.239.32.108)
-> ns-cloud-c2.googledomains. com (216.239.34.108)
-> ns-cloud-c3.googledomains. com (216.239.36.108)
-> ns-cloud-c4.googledomains. com (216.239.38.108)
Sending request to “ns-cloud-c1.googledomains. com” (216.239.32.108)
Received authoritative (AA) response:
-> Answer: A-record for cupon2go.com = 35.202.242.4

Could you post the log files from /var/log/letsencrypt for both the successful and unsuccessful attempts?

The same IP address was used by the VA. Only the www. timed out.

Thanks for checking, @cpu. So it seems like somehow Certbot must not have started the listener in the same way in these two cases, which is surprising to me.

I cant attach the log because i newer user.

I paste the log in this url

https://www.pastiebin.com/59f77ec00d8df

Hi @mexicanobermudez,

Checking the log, seems certbot can’t start the web server on port 443

2017-10-30 19:27:45,346:DEBUG:acme.standalone:Failed to bind to :443 using IPv4

Are you sure you don’t have another service listening on port 443?

sudo netstat -ptanu | grep ':443'

I can see you have issued 3 certs for coupon2go.com so I suppose whatever is the service listening on your machine on port 443, the first day it was not there so you could issue your cert and now it is working for this domain because Let’s Encrypt is not trying to validate it again (Let’s Encrypt caches the validation for 30 days) but now you can issue a cert for www.coupon2go.com because you have a service listening on port 443… just guessing :wink:

Cheers,
sahsanu

1 Like

Thanks for advance but i dont have any service listening on port 443

sudo netstat -ptanu | grep ‘:443’

result:
NOTHING

i try with a port i know have a service

sudo netstat -ptanu | grep ‘:8080’

result:

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 765/java

Unfortunately this is misleading and I don’t think this is the problem here. To automatically handle IPv4 and IPv6 traffic on most systems, Certbot’s standalone plugin first attempts to bind to the port for all interfaces using IPv6 and then bind to the port using IPv4. On most Linux systems, binding using IPv4 fails as IPv4 traffic is routed to the IPv6 port, but since this isn’t the case on all systems like the BSDs, Certbot tries with both protocols and continues execution if at most one fails.

It’s not clear to me what’s causing the challenge to fail, but I think what’s causing requests for cupon2go.com to succeed is authz reuse. Let’s Encrypt has already validated that domain so it’s not checking again. I suspect if you run sudo certbot certonly --standalone -d cupon2go.com --dry-run, the command will fail.

1 Like

Hi bmw, this is the result of the execution

sudo certbot certonly --standalone -d cupon2go.com --dry-run

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

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 www.cupon2go.com --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
challenges.
-------------------------------------------------------------------------------
Press Enter to Continue

When you see this, on another machine run:

openssl s_client -connect www.cupon2go.com:443 -servername foo

You should see something like the following output from Certbot:

Performing handshake with ('::ffff:1.2.3.4', 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": "www.cupon2go.com"
  },  
  "status": "pending",
  "expires": "2017-11-06T20:59:13.60235025Z",
  "challenges": [
    {   
      "type": "dns-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/M2a96xHX6lrhkxevtKjks0Q4YqH9W97TszZAmzAtPFKa/72641828",
      "token": "sbPnxEw5_48Zv9UQ7ZBpkewasUKicGw_ffX4MIh6y3g"
    },  
    {   
      "type": "http-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/M2a96xHX6lrhkxevtKjks0Q4YqH9W97TszZAmzAtPFKa/72641829",
      "token": "n-yKedsuggIzArF18wOXD211bpJ4u9rtVCjSb_xH8WM"
    },  
    {   
      "type": "tls-sni-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/M2a96xHX6lrhkxevtKjks0Q4YqH9W97TszZAmzAtPFKa/72641830",
      "token": "N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI"
    }   
  ],  
  "combinations": [
    [   
      2   
    ],  
    [   
      0   
    ],  
    [   
      1   
    ]   
  ]
}

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:

N4ZbiR5GbQnOD_ggNkHbyM53HtJi57FAa1l35oYMnDI.qlCO-llhghLuz3W3Wk82B6PmWgycWFnRHW0Y76uixHA

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:

c89a9958936426b77bc1fe3b28bbf022.2c79bc847b1edfec64d62a58ec14fbc0.acme.invalid

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

openssl s_client -connect www.cupon2go.com:443 -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:1.2.3.4', 123456, 0, 0)
::ffff:1.2.3.4 - - Incoming request

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

CONNECTED(00000003)
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!

3 Likes

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