Type: unauthorized Detail: Invalid response from

Do you have an IPv6 address?

From my knowledge I don’t. Why you ask?
It’s strange that it’s happening only with this site, not with others in the same server.

None of my sites have an AAAA record configured, but I am not 100% sure if in Arubacloud vps I have an IPv6 or not

Let’s Encrypt recently changed to preferring validations over IPv6 if a site has an AAAA record. Many people’s sites, it turns out, do have AAAA records but are not properly set up to receive incoming web connections via IPv6.

2 Likes

What should I check then? In the domains DNS configurations there re only MX, A and TXT records.

Since there’s no redirect from mysite.pl to myanothersite.pl in your nginx config, I’m guessing that redirect is happening in your PHP code.

Your nginx config looks like it should send a real file if it exists before executing PHP, so the first thing to check is that the file .well-known/acme-challenge/wc7Romm8QfnvUMxqn4YnSm48XNeOHGkyvmGPA_8Yb4Q exists in your web directory for the vhost on the server (/var/www/mysite.pl according your your config snippet). Perhaps you moved things around so certbot is putting this file in the wrong directory, and you just need to update your certbot config with the correct webroot directory.

If that all looks good, try dropping a test.html file or so in the .well-known directory and see if you can browse to it. If you still get redirected to myanothersite.pl when trying to visit that test.html page, you have a problem with your nginx configuration that you might get better help with on Server Fault or a nginx forum.

really strange. I didn;t change anything yet in the server or DNS. Few minutes ago I tried to enter:
http://mysite.pl/.well-known/acme-challenge/wc7Romm8QfnvUMxqn4YnSm48XNeOHGkyvmGPA_8Yb4Q

and got redirected to https://myanothersite.pl/.well-known/acme-challenge/wc7Romm8QfnvUMxqn4YnSm48XNeOHGkyvmGPA_8Yb4Q

Then I tried to enter:
http://mysite.pl/.well-known/acme-challenge/
and got redirected to:
http://myanothersite.pl/.well-known/acme-challenge/

Then tried to enter:
http://mysite.pl/.well-known/
and got forbidden

Then tried to re-enter http://mysite.pl/.well-known/acme-challenge/ and got forbidden too

Then I tried to re-enter http://mysite.pl/.well-known/acme-challenge/wc7Romm8QfnvUMxqn4YnSm48XNeOHGkyvmGPA_8Yb4Q and this time I got the page, there was some text of my site, but no graphics.

I run again certbot onlycert and this time I get a different error (see the mysite and myanothersite:

Failed authorization procedure. mysite.pl (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.myanothersite.com/.well-known/acme-challenge/SieNH_Wxxj0Yo5p1m559ZovGZ2Kco8Q2K4Yzp_-_CP0: Timeout

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: mysite.pl
   Type:   connection
   Detail: Fetching
   https://www.myanothersite.com/.well-known/acme-challenge/SieNH_Wxxj0Yo5p1m559ZovGZ2Kco8Q2K4Yzp_-_CP0:
   Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A 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.

Btw. If I try to enter the test file I put there, it always works well:
http://www.mysite.pl/.well-known/acme-challenge/test.txt

Any idea?

One thing to check is the possible difference between http://mysite.pl/ and http://www.mysite.pl/; it sounds like they might be configured differently in this regard.

What kind of configuration? The DNS have the same IP address for www and non-www.
The rest of the configuration is here above, in the nginx vhost I posted.

One more thing I just noticed. I tried to go to https://www.mysite.pl … I get the error that it’s unsecure. And if I accept to proceed, the browser redirects me to https://www.myanothersite.pl

It’s very inconvenient to look into this without knowing what the actual domain names are; do you think you could let us know them?

I think it was shown (maybe inadvertently):

I believe that’s just a particular resource that a commented-out part of the configuration file was designed to refer to, but not hosting for that site as a whole.

Here it is: http://www.obiektywnarozkosz.pl/ (just for your information - there are images 18+ in the site, so please be aware where/when you open it)

Try also /.well-known/some-random-directory/test.txt and /.well-known/acme-challenge/test.txt. If they don’t work it’s probably that try_files line that is causing you grief.

In fact, I’d really suggest commenting out that try_files line anyway, now that I can see your site. It’s meant to point your domain to something like WordPress, but yours upseems to be pointing to a simple PHP page and is just serving a broken copy of your home page instead of a helpful 404 response. (Create your own helpful 404 page later by adding error_page 404 /404.php directly to your server block if you like. Make sure you send a 404 response if you use PHP.)

http://obiektywnarozkosz.pl/ is redirecting to https://www.obiektywnarozkosz.pl/, which is no problem for validation, but both https://obiektywnarozkosz.pl/ and https://www.obiektywnarozkosz.pl/ are serving a certificate for [www.]anahatatantra.com, resulting in a certificate error in your browser. Let’s Encrypt doesn’t care about the certificate being wrong, invalid, expired, etc. for purposes of validation though.

Did you intend to add [www.]obiektywnarozkosz.pl to the existing certificate for [www.]anahatatantra.com or did you intend to create a separate certificate for it?

You can do it either way as long as both are hosted on your server, but the latter requires adding the certificate to the appropriate server block in nginx while the former will Just Work once you get certbot to issue you a certificate (and restart nginx of course).

At any rate, the certificate being wrong right now doesn’t matter, and the redirect is okay and maintains the path component, hence I’m pretty sure a new certificate or an --expand on the other domain’s with work fine once you get rid of that wonky try_files.

Please share the full certbot command you’re running if you still have trouble after removing it.

http://www.obiektywnarozkosz.pl/.well-known/some-random-directory/test.txt gives me the same result as www.obiektywnarozkosz.pl/.well-known/acme-challenge/wc7Romm8QfnvUMxqn4YnSm48XNeOHGkyvmGPA_8Yb4Q

Where some-random-directory does not exist.

===
I commented the try files and restarted nginx.
I run certbot onlycert, inserted the domains: obiektywnarozkosz.pl,www.obiektywnarozkosz.pl as I did to my other sites successfully, selected the webroot and enter.

Now I retried the some random directory link and I get 404 not found. Which is good.

Now I get this error:
Failed authorization procedure. obiektywnarozkosz.pl (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://obiektywnarozkosz.pl/.well-known/acme-challenge/1D-DiVrq2JG5Zhjuoym1gjhhHcLEtzpBs6c5iMs7Pe4:


<!–[if IE 7 ]”

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: obiektywnarozkosz.pl
   Type:   unauthorized
   Detail: Invalid response from
   http://obiektywnarozkosz.pl/.well-known/acme-challenge/1D-DiVrq2JG5Zhjuoym1gjhhHcLEtzpBs6c5iMs7Pe4:
   "
   <!DOCTYPE html>
   <!--[if lt IE 7 ]><html class="ie ie6" lang="en" prefix="og:
   http://ogp.me/ns#"> <![endif]-->
   <!--[if IE 7 ]"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

The nginx vhost is now:

server {
        listen 80;
        server_name obiektywnarozkosz.pl;
#       root /var/www/obiektywnarozkosz.pl;
        rewrite  ^/(.*)$  https://www.obiektywnarozkosz.pl/$1 permanent;
#       return 301 http://www.obiektywnarozkosz.pl;
}

server {
        listen 80;

        access_log /var/log/nginx/access.log main;
        error_log /var/log/nginx/error.log;

        root /var/www/obiektywnarozkosz.pl;
        index index.php;

        server_name www.obiektywnarozkosz.pl;


        if ($request_uri ~ "/index.(php|html?)") {
                rewrite ^ /$1 permanent;
        }

#       location / {
#               try_files $uri $uri/ /index.php;
#       }


        location ~*  \.(jpg|jpeg|png|gif|ico|css|js|woff)$ {
                expires 365d;
        }

        location ~ (\.sql.gz|\.sql) { return 403; }

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
#               fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}

Aha! I’m seeing the redirects to anahatatantra.com you were talking about now. I’m not sure why I’m seeing them so inconsistently, but that site’s 404 page matches what Let’s Encrypt sees.

Look in the server block for obiektywnarozkosz.pl (without the www). That redirect has to be in there somewhere.

If you can’t find it, you could be lazy and specify the webroot as that of anahatatantra.com, since that’s where the redirect lands. (That redirect may still cause trouble for your visitors though.)

That’s really strange, because the full vhost is the one I posted there. So there are no additional redirects. All you see there, is all I have for this site.

When selecting the webroot, I chose the right one.

Add listen 443 ssl; to both of those server blocks. Maybe it is falling through to the other domain because it’s the only one explicitly listening on ssl.

2 Likes

done… nothing :confused:

Failed authorization procedure. obiektwynarozkosz.pl (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for obiektwynarozkosz.pl

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: obiektwynarozkosz.pl
   Type:   connection
   Detail: DNS problem: NXDOMAIN looking up A for obiektwynarozkosz.pl

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A 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 reverted it back to 80

You must add that line, do not remove the existing entry, so that it listens on both port 80 and 443.

Done:

server {
        listen 80;
        listen 443 ssl;
        server_name obiektywnarozkosz.pl;
#       root /var/www/obiektywnarozkosz.pl;
        rewrite  ^/(.*)$  https://www.obiektywnarozkosz.pl/$1 permanent;
#       return 301 http://www.obiektywnarozkosz.pl;
}

server {
        listen 80;
        listen 443 ssl;

        access_log /var/log/nginx/access.log main;
        error_log /var/log/nginx/error.log;

        root /var/www/obiektywnarozkosz.pl;
        index index.php;

        server_name www.obiektywnarozkosz.pl;


        if ($request_uri ~ "/index.(php|html?)") {
                rewrite ^ /$1 permanent;
        }

#       location / {
#               try_files $uri $uri/ /index.php;
#       }


        location ~*  \.(jpg|jpeg|png|gif|ico|css|js|woff)$ {
                expires 365d;
        }

        location ~ (\.sql.gz|\.sql) { return 403; }

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
#               fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}

And got the error:

Failed authorization procedure. www.obiektwynarozkosz.pl (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for www.obiektwynarozkosz.pl

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.obiektwynarozkosz.pl
   Type:   connection
   Detail: DNS problem: NXDOMAIN looking up A for
   www.obiektwynarozkosz.pl

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A 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.