Failed authorization procedure Connection refused

Help
1

When i execute

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

i recive the following message in console:

Performing the following challenges:
tls-sni-01 challenge for cupon2go.com
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 co
nnect to the client to verify the domain :: Connection refused
IMPORTANT NOTES:

  • The following errors were reported by the server:
    Domain: www.cupon2go.com
    Type: connection
    Detail: Connection refused
    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.

I verify and i had 2 register A for this domain in DNS one for cupon2go.com and other for www.cupon2go.com

When i trace both domain i have the following same result:

Received authoritative (AA) response:
-> Answer: A-record for cupon2go.com = 35.188.79.253

Received authoritative (AA) response:
-> Answer: A-record for www.cupon2go.com = 35.188.79.253

Can you help me, my problem is only for www.cupon2go.com, if i generate de cert only for cupon2go.com is generate succefull.

Thanks.

2

You’re using --standalone, which by default uses the tls-sni-01 challenge type, which operates over port 443. Are you certain that port 443 is open on your firewall, and forwarded to the server running certbot (if applicable)?

3

Yes, if i run only with cupon2go.com name, the certificate is generate correctly. I review the ports of my firewall and 443 port is open.

4

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

5

Hi, i run

certbot certonly --standalone -d cupon2go.com

6

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

7

(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

9

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
10

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.

11

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?

13

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

14

@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.

15

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

16

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

17

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

18

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.

19

I cant attach the log because i newer user.

I paste the log in this url

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

20

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
22

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

23

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