[solved] RaspberryPi The server could not connect to the client to verify the domain

l installed lets’encrypt on a raspberry pi 2 running raspbian
I launch :

sudo ~/.local/share/letsencrypt/bin/letsencrypt certonly --webroot -w /var/www/wordpress/ -d sebbane.xyz --email sebbane.ismail@gmail.com

i got the error :

Failed authorization procedure. sebbane.xyz (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://sebbane.xyz/.well-known/acme-challenge/ldsUurkhO4HZx0D4pMvMkmKJTmyCwB1vm6fXhYzcv8c

IMPORTANT NOTES:

  • The following ‘urn:acme:error:connection’ errors were reported by
    the server:

    Domains: sebbane.xyz
    Error: The server could not connect to the client to verify the
    domain

2016-01-05 14:41:01,253:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/ch0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4. args: (), kwargs: {}
2016-01-05 14:41:01,262:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-01-05 14:41:01,631:DEBUG:requests.packages.urllib3.connectionpool:“GET /acme/authz/ch0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4 HTTP/1.1” 200 1056
2016-01-05 14:41:01,653:DEBUG:root:Received <Response [200]>. Headers: {‘Content-Length’: ‘1056’, ‘Expires’: ‘Tue, 05 Jan 2016 14:41:01 GMT’, ‘Strict-Transport-Security’: ‘max-age=604800’, ‘Server’: ‘nginx’, ‘Connection’: ‘keep-al
ive’, ‘Link’: ‘https://acme-v01.api.letsencrypt.org/acme/new-cert;rel=“next”’, ‘Pragma’: ‘no-cache’, ‘Cache-Control’: ‘max-age=0, no-cache, no-store’, ‘Date’: ‘Tue, 05 Jan 2016 14:41:01 GMT’, ‘X-Frame-Options’: ‘DENY’, ‘Content-
Type’: ‘application/json’, ‘Replay-Nonce’: ‘GNA24lT0zZ_ewj4j7jR_OnGWTS4XzoTETQEFASGfgVY’}. Content: '{“identifier”:{“type”:“dns”,“value”:“sebbane.xyz”},“status”:“invalid”,“expires”:“2016-01-12T14:40:57Z”,“challenges”:[{“type”:“tls
-sni-01”,“status”:“pending”,“uri”:“https://acme-v01.api.letsencrypt.org/acme/challenge/ch0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4/4623273",“token”:“Qggl2rgeyP_kfsFGAe34sNIdfpG7Nl55-zIwm-I3spo”},{“type”:“http-01”,“status”:"invalid
”,“error”:{“type”:“urn:acme:error:connection”,“detail”:“Could not connect to http://sebbane.xyz/.well-known/acme-challenge/tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw"},“uri”:"https://acme-v01.api.letsencrypt.org/acme/challenge/ch
0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4/4623274”,“token”:“tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw”,“keyAuthorization”:“tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw.I1egLg6lOhJSqGIzaWWgyd3_2U_5shbzIY_vUhPW8Gk”,“validationRecor
d”:[{“url”:“http://sebbane.xyz/.well-known/acme-challenge/tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw",“hostname”:“sebbane.xyz”,“port”:“80”,“addressesResolved”:[“69.64.147.243”],“addressUsed”:“69.64.147.243”}]}],"combinations”:[[1
],[0]]}'
2016-01-05 14:41:01,659:DEBUG:acme.client:Received response <Response [200]> (headers: {‘Content-Length’: ‘1056’, ‘Expires’: ‘Tue, 05 Jan 2016 14:41:01 GMT’, ‘Strict-Transport-Security’: ‘max-age=604800’, ‘Server’: ‘nginx’, ‘Conne
ction’: ‘keep-alive’, ‘Link’: ‘https://acme-v01.api.letsencrypt.org/acme/new-cert;rel=“next”’, ‘Pragma’: ‘no-cache’, ‘Cache-Control’: ‘max-age=0, no-cache, no-store’, ‘Date’: ‘Tue, 05 Jan 2016 14:41:01 GMT’, ‘X-Frame-Options’: ‘
DENY’, ‘Content-Type’: ‘application/json’, ‘Replay-Nonce’: ‘GNA24lT0zZ_ewj4j7jR_OnGWTS4XzoTETQEFASGfgVY’}): '{“identifier”:{“type”:“dns”,“value”:“sebbane.xyz”},“status”:“invalid”,“expires”:“2016-01-12T14:40:57Z”,“challenges”:[{“ty
pe”:“tls-sni-01”,“status”:“pending”,“uri”:“https://acme-v01.api.letsencrypt.org/acme/challenge/ch0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4/4623273",“token”:“Qggl2rgeyP_kfsFGAe34sNIdfpG7Nl55-zIwm-I3spo”},{“type”:“http-01”,"status”:
“invalid”,“error”:{“type”:“urn:acme:error:connection”,“detail”:“Could not connect to http://sebbane.xyz/.well-known/acme-challenge/tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw"},“uri”:"https://acme-v01.api.letsencrypt.org/acme/chal
lenge/ch0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4/4623274”,“token”:“tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw”,“keyAuthorization”:“tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw.I1egLg6lOhJSqGIzaWWgyd3_2U_5shbzIY_vUhPW8Gk”,“validat
ionRecord”:[{“url”:“http://sebbane.xyz/.well-known/acme-challenge/tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw",“hostname”:“sebbane.xyz”,“port”:“80”,“addressesResolved”:[“69.64.147.243”],“addressUsed”:“69.64.147.243”}]}],"combinati
ons”:[[1],[0]]}'
2016-01-05 14:41:01,667:INFO:letsencrypt.reporter:Reporting to user: The following ‘urn:acme:error:connection’ errors were reported by the server:

Domains: sebbane.xyz
Error: The server could not connect to the client to verify the domain
2016-01-05 14:41:01,669:INFO:letsencrypt.auth_handler:Cleaning up challenges
2016-01-05 14:41:01,670:DEBUG:letsencrypt.plugins.webroot:Removing /var/www/wordpress/.well-known/acme-challenge/tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw
2016-01-05 14:41:02,500:DEBUG:letsencrypt.cli:Exiting abnormally:
Traceback (most recent call last):
File “/home/pi/.local/share/letsencrypt/bin/letsencrypt”, line 11, in
sys.exit(main())
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/cli.py”, line 1396, in main
return args.func(args, config, plugins)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/cli.py”, line 598, in obtain_cert
_auth_from_domains(le_client, config, domains)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/cli.py”, line 402, in _auth_from_domains
lineage = le_client.obtain_and_enroll_certificate(domains)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/client.py”, line 283, in obtain_and_enroll_certificate
certr, chain, key, _ = self.obtain_certificate(domains)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/client.py”, line 266, in obtain_certificate
return self._obtain_certificate(domains, csr) + (key, csr)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/client.py”, line 224, in _obtain_certificate
authzr = self.auth_handler.get_authorizations(domains)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/auth_handler.py”, line 84, in get_authorizations
self._respond(cont_resp, dv_resp, best_effort)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/auth_handler.py”, line 142, in _respond
self._poll_challenges(chall_update, best_effort)
File “/home/pi/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/auth_handler.py”, line 204, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. sebbane.xyz (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://sebbane.xyz/.well-known/acme-chal
lenge/tJpW_ar1GYopR3S0Kz4xgeB3Htom9WkbUG8IYauHcZw

thks for your help

Is your raspberry serving sebbane.xyz and is /var/www/wordpress/ the webroot for that site? Response headers of sebbane.xyz seem to indicate that it’s running an IIS server, and not something on your raspberry (unless you have some kind of reverse proxy setup).

To explain what the CA server needs to see in order to verify your ownership of your domain:
--webroot mode will put a certain file in your webroot under /.well-known/acme-challenge/{random}. Let’s Encrypt then requests this file via HTTP, and verifies that it’s serving the correct challenge token. So in order to verify ownership you need to put the file on your actual web server under /.well-known/acme-challenge/{random}. If you’re using IIS, this might be easier using manual mode (or look into alternative clients).

The domain sebbane.xyz points to the ip 78.193.56.143 of my router and my router redirect ports 80 and 443 to the raspberry pi.
/var/www/wordpress/ is the webroot of my site
Rasbian and apache2 are installed on my raspberrypi.
I don’t use IIS or a proxy.
I have a folder that has been created but does not contain files!
pi@raspberrypi ~ $ ls -al /var/www/wordpress/.well-known/acme-challenge/
total 8
drwxrwxrwx 2 www-data www-data 4096 janv. 5 20:21 .
drwxrwxrwx 3 www-data www-data 4096 janv. 5 12:09 …

The domain previously resolved to 69.64.147.243 according to the challenge object in your log:
https://acme-v01.api.letsencrypt.org/acme/challenge/ch0MkBN8EdIV1_TE57_TLRwpbe5aJUcfV_1LJfKvuC4/4623274

--webroot mode will delete the temporary files after a successful or failed validation. I would suggest manually creating a test file and verifying it is properly served when accessed from outside your network.

1 Like

It still does sometimes.

The DNS servers for the xyz TLD ({x,y,z}.nic.xyz) give an extra NS record as a result during the lookup:

sebbane.xyz.		3600	IN	NS	ns4.hostinger.fr.
sebbane.xyz.		3600	IN	NS	ns3.hostinger.fr.
sebbane.xyz.		3600	IN	NS	ns2.hostinger.fr.
sebbane.xyz.		3600	IN	NS	dns1.name-services.com.
1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN NSEC3 1 1 1 - 1H9NL1J8IMJ93NV6DIUV53QRT58HP3B7 NS SOA RRSIG DNSKEY NSEC3PARAM
1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20160127140015 20151228033548 62230 xyz. jhGt4+JsPR+Au47iFKiFM4CgIUnUX17sJr1BuM5Szi8/C3XK0kT8jwnn 8a8Qff7evARAgH05zdrZhWxFFIzSeJ29NmTjDUKuPVQ8RaaHsg/oREDZ USpPSswEfo7lr9y3TF7Po2GRKJdbBbTIC0uQTQEndRR/F++GqYRaivWv /5o=
44aqt9nu7v60jljlmqbcr9n5krbr2red.xyz. 3600 IN NSEC3 1 1 1 - 44MGIQ1TQ11MISA1K3IMR12K8VD3NCLH NS DS RRSIG
44aqt9nu7v60jljlmqbcr9n5krbr2red.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20160113062807 20151214013032 62230 xyz. Z7ydCHPklgJVcHW0lCAMLeAQuGG3jRMG2/caEFLP1fWrT0NAANVX19Q4 ulpqOT1QmIhmuR/0fyJe+DbHxCs/kcUXRUBT0GYRvzkcT5SN5/AzJcfT HZmaVyDiMopWqSeq60e9IFTImlj4tw/MfhxhXxVouXIXh1h3dmNN/jAE yOY=
;; Received 627 bytes from 212.18.248.42#53(z.nic.xyz) in 304 ms

@solidleon uses ns{1,2,3,4}.hostinger.fr for his domain (correct), that dns1.name-services.com. is an extra record (not correct).

This "rogue" DNS server gives 69.64.147.243 as a result..

2 Likes

After resetting the DNS problem solved.
Thank you