Challenge failed

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:cdo-tst.lenovo.com

I ran this command:certbot --nginx

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

Which names would you like to activate HTTPS for?

1: cdo-tst.lenovo.com

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cdo-tst.lenovo.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. cdo-tst.lenovo.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://cdo-tst.lenovo.com/.well-known/acme-challenge/-eJu_BVeU-qZulM3IxpEjRgRuuh8ocroIus4VQASrYk: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: cdo-tst.lenovo.com
    Type: connection
    Detail: Fetching
    http://cdo-tst.lenovo.com/.well-known/acme-challenge/-eJu_BVeU-qZulM3IxpEjRgRuuh8ocroIus4VQASrYk:
    Timeout during connect (likely firewall problem)

    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.
    My web server is (include version): nginx/1.14.0

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):certbot 0.25.1

Pre-thanks anyone that would help me on this.:worried:

1 Like

There are issues connecting to your site.

curl -Iki cdo-tst.lenovo.com
HTTP/1.1 403 Forbidden     < < < < < FORBIDDEN
Server: nginx/1.14.0
Date: Sun, 17 Nov 2019 23:05:58 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive

Also:

may need some updating.

Yeah, I was just reinstalling every thing, I will update later

1 Like

Afater I update certbot to 0.39.0, I still failed.

[root@shelnnrii01 conf.d]# certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

Which names would you like to activate HTTPS for?


1: cdo-tst.lenovo.com


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cdo-tst.lenovo.com
Waiting for verification…
Challenge failed for domain cdo-tst.lenovo.com
http-01 challenge for cdo-tst.lenovo.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: cdo-tst.lenovo.com
    Type: connection
    Detail: Fetching
    http://cdo-tst.lenovo.com/.well-known/acme-challenge/KFPM-_5XJVmIpx3V3-MY8DDNwgLrfEJ10HsLXBySzgE:
    Timeout during connect (likely firewall problem)

    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.

Also I checked the DNS lookup, and I can get the A address for the domain.

Is there some GeoLocation filter or IPS in place that might be blocking LE?
[I get to your site (although it returns 404 not timeout)]

Let's Debug returns the same error: Let's Debug

That’s the point confusing me too, I’ve been using certbot auto renew for almost one and half year, this time it stop working suddenly. I really cant find out why? :cry:

This tool (by a community leader) shows a couple of interesting… things:
https://check-your-website.server-daten.de/?q=cdo-tst.lenovo.com

  1. HTTP content accessible via port 443: http://cdo-tst.lenovo.com:443/
  2. Inconsistent DNS domain SOA records found.
    Serial: 1574053566
    Serial: 1574053581
    Serial: 1564393130

[I think I may have read the SOA part wrong]

1 Like

I was just testing the firewall policy, so I changed the http port to 443, now it’s back to 80.

And yet HTTP content is still visible (unencrypted) via port 443:

curl http://cdo-tst.lenovo.com:443/
<!doctype html><html lang="zh"><head><meta charset="utf-8"/><link rel="shortcut icon" href="./favicon.ico"/><meta name="viewport" content="width=device-width,initial-scale=1"/><meta name="theme-color" content="#000000"/><link rel="manifest" href="./manifest.json"/><link rel="stylesheet" href="https://at.alicdn.com/t/font_1316242_mydwcfwcsqb.css"/><title>CSDC消费销售数据中心</title><link href="./static/css/2.f98bc5d6.chunk.css" rel="stylesheet"><link href="./static/css/main.807b3edd.chunk.css" rel="stylesheet"></head><body><noscript>You need to enable JavaScript to run this app.</noscript><div id="root"></div><script>!function(l){function e(e){for(var r,t,n=e[0],o=e[1],u=e[2],f=0,i=[];f<n.length;f++)t=n[f],p[t]&&i.push(p[t][0]),p[t]=0;for(r in o)Object.prototype.hasOwnProperty.call(o,r)&&(l[r]=o[r]);for(s&&s(e);i.length;)i.shift()();return c.push.apply(c,u||[]),a()}function a(){for(var e,r=0;r<c.length;r++){for(var t=c[r],n=!0,o=1;o<t.length;o++){var u=t[o];0!==p[u]&&(n=!1)}n&&(c.splice(r--,1),e=f(f.s=t[0]))}return e}var t={},p={1:0},c=[];function f(e){if(t[e])return t[e].exports;var r=t[e]={i:e,l:!1,exports:{}};return l[e].call(r.exports,r,r.exports,f),r.l=!0,r.exports}f.m=l,f.c=t,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(r,e){if(1&e&&(r=f(r)),8&e)return r;if(4&e&&"object"==typeof r&&r&&r.__esModule)return r;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:r}),2&e&&"string"!=typeof r)for(var n in r)f.d(t,n,function(e){return r[e]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,"a",r),r},f.o=function(e,r){return Object.prototype.hasOwnProperty.call(e,r)},f.p="./";var r=window.webpackJsonp=window.webpackJsonp||[],n=r.push.bind(r);r.push=e,r=r.slice();for(var o=0;o<r.length;o++)e(r[o]);var s=n;a()}([])</script><script src="./static/js/2.97d934b8.chunk.js"></script><script src="./static/js/main.f2c3bdce.chunk.js"></script></body></html>

Now it’s connection refused.

Yeah, you actioned so quickly

1 Like

But back to my issue, what should I do now?

OK the issue is not the “firewall” per se (not incorrect port forwarding).
It is more about GeoLocation blocking maybe or some other ACLs.

My server located at China, so you mean there may be sth to do with Trump?

1 Like

I think it may be more like the error message is a bit misleading.

The main site requires authentication:

curl -Iki http://cdo-tst.lenovo.com/
HTTP/1.1 403 Forbidden
Server: nginx/1.14.0
Date: Mon, 18 Nov 2019 00:17:54 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive

You need to exclude the /.well-known/acme-challenge/ requests from such required authentication.
Probably better to just auth on 443 and redirect all http to https]
[other than the challenge requests]

server {
server_name  cdo-tst.lenovo.com;
#charset koi8-r;

#access_log  /var/log/nginx/host.access.log  main;

location /digital_operation {
    proxy_pass      http://10.122.43.29:8080;
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
}

#error_page  404              /404.html;

# redirect server error pages to the static page /50x.html
#
error_page   500 502 503 504  /50x.html;
location = /50x.html {
    root   /usr/share/nginx/html;
}

listen 80;

}
this is what I configured in my nginx default.conf file, any mistake?

There is no consideration for the challenges…
I would add something like:

   location /.well-known/acme-challenge/ {
       root /ACME-challenges/;   #use a new dedicated folder for challenges 
       try_files $uri =404;
   }#location

#mkdir /ACME-challenges/
#chmod 777 /ACME-challenges/

Also, inside the location / section:
return 301 https://$host$request_uri;
[to redirect all http to https]

Which makes me wonder if you should move this location to the https server block:

location /digital_operation {
   ...
}

The com zone has often different SOA numbers, that’s not a problem. Same with the net zone.

The zone of the domain should have a consistent SOA number.

The same thing happened at my production env(https://cdo.lenovo.com), currently everything is going fine, but there is only 6 days left for me to resolve this issue.