For some reason could not reach XXX - please check it manually

Hi!
I’m trying to renew my LE certificates but somehow I always get this error.

for some reason could not reach http://dummy.pflegeplus24.de/.well-known/acme-challenge/nPamzM4Mmoc60m-EDblD-IvqON_6M9bry-HR9iECBEU - please check it manually

I tested this with curl / hideme proxy and there is no problem accessing the file.

How could this possibly happen?
Hope someone can help :expressionless:

It is happening to me ,
it seems DNS problem.
After 5 retries i got rate limited and now my server is down totally.
that is really horrible for me since it is a startup’s production system.

Do you still have this problem? It is killing my server…

Hi @rawk,

Please fill out the template questions. It’s much harder to get help without the information we request being provided.

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

Notably, the Let’s Encrypt client software that you used should be able to display error messages from the certificate authority explaining more about why the challenge could not be validated.

Not sure if this is relevant…
But the “dummy” FQDN returns a FAKE LE cert for:
DNS Name=autodiscover.pflegeplus24.de
DNS Name=mail.pflegeplus24.de
DNS Name=utm.pflegeplus24.de
DNS Name=webmail.pflegeplus24.de

can you show the :80 vhost for dummy?

Hi! Sorry for my late reply!

CPU:
My domain is: amagno.pflegeplus24.de

I ran this command: ./getssl -a (running it from an UTM9)

It produced this output:
for some reason could not reach http://amagno.pflegeplus24.de/.well-known/acme-challenge/xxx - please check it manually

My web server is (include version): IIS 6.2

The operating system my web server runs on is (include version): Windows Server 2012 R2

My hosting provider, if applicable, is: -

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

All those request are routed internally to one server. Like I said, there’s no problem to reach the site from WAN…

@schoen:

Verifying amagno.pflegeplus24.de

url https://acme-v01.api.letsencrypt.org/acme/new-authz

payload {“resource”:“new-authz”,“identifier”:{“type”:“dns”,“value”:“amagno.pflegeplus24.de”}}

payload64 eyJyZXNvdXJjZSI6Im5ldy1hdXRoeiIsImlkZW50aWZpZXIiOnsidHlwZSI6ImRucyIsInZhbHVlIjoiYW1hZ25vLnBmbGVnZXBsdXMyNC5kZSJ9fQ

nonce h6u7DrCsSMAlhMZXsDK-VxV2HBpbXTsTA1w3oZGzNk0

protected {“alg”: “RS256”, “jwk”: {“e”:“AQAB”,“kty”:“RSA”,“n”:“u99TGuXaTndHFWy_dzGqS-UdPSKPT2D-zI4D6MuQM1hj6If4RXjamL7n-B6BUxutB7Ik-ayXhAvIupvSZTxDzhAa44RnPpSA7prQ-tkpE8F99SAwSZoioU82O21i1ugYgVABGcKcjR4WnJ-80dqLGK4v540kOA-y0_MJN3AUTTvG2QEyk6npiT2UXTum_xIaiT9NCNLTWVoBW9ubFqB5WJrV_H3CGecXpNS30ObN7bf5wTYhanZjX1tGTNGo6ENpAkA9x9btU3TkAkChXXJQO5zSDsQ4QpRNHePGhvF7L8soGBZn4683MXhd3E9bwkNmC7KJfwJAZjJno2M6-_kbvs5EgJzcm3oIQNh834FxRQaw9p1k5zHWS9XJryoYC0JLs1hsLJaY5P_vwIe_Kqa2DxxpsUUQMC6_IP7AjYXpNJpa7OgrYWJ91ZQFarj0P5_RK8owcfuRec7p6KYyvIbbKLnqGBvNOq-ycisK2Op9vMwOs62F1ngpDxynpkebMpMMt6kvhVmhCDUToSP41-RFVDId0zZ4dWpfi9M2vqMnCGWdm238IWtL5hAWAU-dAz03IlJTTAlR7tVmeg6LFrwzpsI8s-CawCGFuZPSGJhFN9Z6yHjzLABDKDQ7kb8uUtr4PIxP65IwYMOYEccdiTc5wbaizVPtAL2hszcRXdC5b_E”}, “nonce”: “h6u7DrCsSMAlhMZXsDK-VxV2HBpbXTsTA1w3oZGzNk0”, “url”: “https://acme-v01.api.letsencrypt.org/acme/new-authz”}

header, payload and signature = {“header”: {“alg”: “RS256”, “jwk”: {“e”:“AQAB”,“kty”:“RSA”,“n”:“u99TGuXaTndHFWy_dzGqS-UdPSKPT2D-zI4D6MuQM1hj6If4RXjamL7n-B6BUxutB7Ik-ayXhAvIupvSZTxDzhAa44RnPpSA7prQ-tkpE8F99SAwSZoioU82O21i1ugYgVABGcKcjR4WnJ-80dqLGK4v540kOA-y0_MJN3AUTTvG2QEyk6npiT2UXTum_xIaiT9NCNLTWVoBW9ubFqB5WJrV_H3CGecXpNS30ObN7bf5wTYhanZjX1tGTNGo6ENpAkA9x9btU3TkAkChXXJQO5zSDsQ4QpRNHePGhvF7L8soGBZn4683MXhd3E9bwkNmC7KJfwJAZjJno2M6-kbvs5EgJzcm3oIQNh834FxRQaw9p1k5zHWS9XJryoYC0JLs1hsLJaY5P_vwIe_Kqa2DxxpsUUQMC6_IP7AjYXpNJpa7OgrYWJ91ZQFarj0P5_RK8owcfuRec7p6KYyvIbbKLnqGBvNOq-ycisK2Op9vMwOs62F1ngpDxynpkebMpMMt6kvhVmhCDUToSP41-RFVDId0zZ4dWpfi9M2vqMnCGWdm238IWtL5hAWAU-dAz03IlJTTAlR7tVmeg6LFrwzpsI8s-CawCGFuZPSGJhFN9Z6yHjzLABDKDQ7kb8uUtr4PIxP65IwYMOYEccdiTc5wbaizVPtAL2hszcRXdC5b_E"}},“protected”: “eyJhbGciOiAiUlMyNTYiLCAiandrIjogeyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4iOiJ1OTlUR3VYYVRuZEhGV3lfZHpHcVMtVWRQU0tQVDJELXpJNEQ2TXVRTTFoajZJZjRSWGphbUw3bi1CNkJVeHV0QjdJay1heVhoQXZJdXB2U1pUeER6aEFhNDRSblBwU0E3cHJRLXRrcEU4Rjk5U0F3U1pvaW9VODJPMjFpMXVnWWdWQUJHY0tjalI0V25KLTgwZHFMR0s0djU0MGtPQS15MF9NSk4zQVVUVHZHMlFFeWs2bnBpVDJVWFR1bV94SWFpVDlOQ05MVFdWb0JXOXViRnFCNVdKclZfSDNDR2VjWHBOUzMwT2JON2JmNXdUWWhhblpqWDF0R1ROR282RU5wQWtBOXg5YnRVM1RrQWtDaFhYSlFPNXpTRHNRNFFwUk5IZVBHaHZGN0w4c29HQlpuNDY4M01YaGQzRTlid2tObUM3S0pmd0pBWmpKbm8yTTYtX2tidnM1RWdKemNtM29JUU5oODM0RnhSUWF3OXAxazV6SFdTOVhKcnlvWUMwSkxzMWhzTEphWTVQX3Z3SWVfS3FhMkR4eHBzVVVRTUM2X0lQN0FqWVhwTkpwYTdPZ3JZV0o5MVpRRmFyajBQNV9SSzhvd2NmdVJlYzdwNktZeXZJYmJLTG5xR0J2Tk9xLXljaXNLMk9wOXZNd09zNjJGMW5ncER4eW5wa2ViTXBNTXQ2a3ZoVm1oQ0RVVG9TUDQxLVJGVkRJZDB6WjRkV3BmaTlNMnZxTW5DR1dkbTIzOElXdEw1aEFXQVUtZEF6MDNJbEpUVEFsUjd0Vm1lZzZMRnJ3enBzSThzLUNhd0NHRnVaUFNHSmhGTjlaNnlIanpMQUJES0RRN2tiOHVVdHI0UEl4UDY1SXdZTU9ZRWNjZGlUYzV3YmFpelZQdEFMMmhzemNSWGRDNWJfRSJ9LCAibm9uY2UiOiAiaDZ1N0RyQ3NTTUFsaE1aWHNESy1WeFYySEJwYlhUc1RBMXczb1pHek5rMCIsICJ1cmwiOiAiaHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvbmV3LWF1dGh6In0”,“payload”: “eyJyZXNvdXJjZSI6Im5ldy1hdXRoeiIsImlkZW50aWZpZXIiOnsidHlwZSI6ImRucyIsInZhbHVlIjoiYW1hZ25vLnBmbGVnZXBsdXMyNC5kZSJ9fQ”,“signature”: "IwCzTCMvi-0WJNdsA2efWowsGMG3bDPvZmDQYYwBE789NK9irAfpOOsJsxIHwfAAXs08BvLmOHGLC8rSiViTNWoqaxQiFMJXxhkh_P2VukE9k_7AT3lOgAd8lBkBl5RB9UOyQqMHeLasdIxSwCeptaoufdmGdakjw9cb8VgDNyTcRgjXLkT7c-IXqoafwRRupxRi0ytJ9fKBPPet_aVF_yljLGEpFm1Yc9oJCBoP6U9PUrDtfmyfmK_wJssyE3BEMRVmmhmkKOlIQFSPS_JBwnSIsBqEkyeVan6tCy6Spye-T9IdsDsyF-ueOyUIiPPB50o6b4poR1koPEdwN_8JWZNTiva5vN90raQ_nF21P0dwtHD5qvjB8LJCalvuqc16saN2-_twDu664FVvecZRV05bmMDxJRTKtXDNxWyQadgWWpyZq3fOqBYnT2zGguYu70SA5ImsVir7vJDjal2YktqG-sXojbeEKhUzOv9tGYH4MiobJMZNKu8xZMbZL8jVQDJmEOtanmx6aQHe74HoElss7cIYk-8FgFMgwnZfoQKaZXc-Rbgnhl4SCjYo2K5Bmu5E_SL7U61tO4FDYWIXZLYXAAzRfliTcSGUxIQWINRtdylImK3wLxiEzB37rs2ZTD05zpBLzLXHCTC9xupHxTqRUQf2MjIQs5_hUNPHYg”}

responseHeaders HTTP/1.1 100 Continue
Expires: Thu, 22 Jun 2017 14:11:07 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 201 Created
Server: nginx
Content-Type: application/json
Content-Length: 1009
Boulder-Request-Id: qfEJ2iFoa17bwM6TgCQEKFvFfFamiuEgiPl1hgEnE4w
Boulder-Requester: 10868285
Link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel="next"
Location: https://acme-v01.api.letsencrypt.org/acme/authz/nTVJbQ_KnUn_P42AeLi0bJDkDKPOdBHegLbTTjsUpsc
Replay-Nonce: g9B54kOYCH4rDPklF_eg2AFRS-NHiG5a6JglGUikAPA
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Thu, 22 Jun 2017 14:11:07 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 22 Jun 2017 14:11:07 GMT
Connection: keep-alive

response {
“identifier”: {
“type”: “dns”,
“value”: “amagno.pflegeplus24.de
},
“status”: “pending”,
“expires”: “2017-06-29T14:11:07.65188136Z”,
“challenges”: [
{
“type”: “http-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/nTVJbQ_KnUn_P42AeLi0bJDkDKPOdBHegLbTTjsUpsc/1396577382”,
“token”: “MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M”
},
{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/nTVJbQ_KnUn_P42AeLi0bJDkDKPOdBHegLbTTjsUpsc/1396577389”,
“token”: “K2eNQRJOXPy6n6Kqp4sd-RI16qkArBGFUsThZD3w5zk”
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/nTVJbQ_KnUn_P42AeLi0bJDkDKPOdBHegLbTTjsUpsc/1396577391”,
“token”: “JMwXaAa0MX6x8j8S_5VOe8UlLl7dnr4SVQ-DGHe5hwk”
}
],
“combinations”: [
[
0
],
[
1
],
[
2
]
]
}

code 201

response status = pending

completed send_signed_request

token MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M

uri https://acme-v01.api.letsencrypt.org/acme/challenge/nTVJbQ_KnUn_P42AeLi0bJDkDKPOdBHegLbTTjsUpsc/1396577382

keyauthorization MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M.YO2KG9UeYJzFR_ksNcCgzdep8SFfQHttQg0mXJ5W_LY

copying file from /root/.getssl/mail.pflegeplus24.de/tmp/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M to ssh:Admin@SERVER:/cygdrive/c/inetpub/wwwroot/.well-known/acme-challenge
copying challenge token to ssh:Administrator@192.168.64.25:/cygdrive/c/inetpub/wwwroot/.well-known/acme-challenge/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M

copying from /root/.getssl/mail.pflegeplus24.de/tmp/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M to ssh:Admin@SERVER:/cygdrive/c/inetpub/wwwroot/.well-known/acme-challenge/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M

using scp scp -q /root/.getssl/mail.pflegeplus24.de/tmp/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M Admin@SERVER:/cygdrive/c/inetpub/wwwroot/.well-known/acme-challenge/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M

userid

copied /root/.getssl/mail.pflegeplus24.de/tmp/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M to ssh:Admi@SERVER:/cygdrive/c/inetpub/wwwroot/.well-known/acme-challenge/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M

wellknown_url http://amagno.pflegeplus24.de/.well-known/acme-challenge/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M
getssl: for some reason could not reach http://amagno.pflegeplus24.de/.well-known/acme-challenge/MnAX4dHHm1kZDB3RVntKhhSJuwzoquv0E67eHtMqf6M - please check it manually

That’s from the -d command of getssl…

@rg305:
Actually I removed this from the list as I didn’t need it anymore. Still the same problem though

Thanks for all your answers!

Hi @rawk,

When I look at that .well-known/acme-challenge URL with a browser, I get a 404 error, not the intended file. Do you see something different?

If not, it seems like you should look at your web server to make sure that the challenge file was actually copied into what you think was the right place by the scp command, and then look at your web server configuration to figure out why that file is then not getting served to the public.

Hey @schoen ,
sorry I changed the routing on the server because I wanted to generate the file from another PC.

This one should work. I can reach from outside the LAN with no problems…still the same error

http://amagno.pflegeplus24.de/.well-known/acme-challenge/Wbp4gs5nBOETn6fafMMXPOpd_sGc3uz8rfPOjgeSRQI

That looks like an improvement, because I can now see that particular file.

So, you’re still letting it update each individual requested challenge file before the CA tries to validate the challenge, and yet the challenges still fail? Can you confirm that each challenge file can actually be accessed from the outside world, not just the same one that you showed us, or that the sample one is totally typical of others?

@serverco, would you be willing to take a look into a getssl failure with a Windows Server host using scp?

Edit: also, is there a way to make getssl show what the actual ACME-side error message was?

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