Error with renew: Invalid response

Help
1

I ran this command:--force-renew

It produced this output:

user@ubuntu:/var/www$ sudo certbot certonly --force-renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Nginx Web Server plugin (nginx)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator nginx, Installer None
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel): sub.mydomain.com
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for sub.mydomain.com
Using default addresses 80 and [::]:80 ipv6only=on for authentication.
nginx: [warn] conflicting server name "test.mydomain.com" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "test.mydomain.com" on [::]:80, ignored
Waiting for verification...
Cleaning up challenges
nginx: [warn] conflicting server name "test.mydomain.com" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "test.mydomain.com" on [::]:80, ignored
Failed authorization procedure. sub.mydomain.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: 23.23.23.23: Invalid response from http://sub.mydomain.com/.well-known/acme-challenge/llkJr6CxTZFfJsOQa6fTg63JcBwIA3H-VrSBhhRt3hQ: 400

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

   Domain: sub.mydomain.com
   Type:   unauthorized
   Detail: 23.23.23.23: Invalid response from
   http://sub.mydomain.com/.well-known/acme-challenge/llkJr6CxTZFfJsOQa6fTg63JcBwIA3H-VrSBhhRt3hQ:
   400

   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.

I have root access on ubuntu with nginx
I am using: certbot 0.31.0

Problem maybe on line that: conflicting server name "test.mydomain.com" on 0.0.0.0:80, ignored it should be sub.mydomain.com but it is showing test.mydomain.com

2

That will not work-around problems but can easily cause you to become Rate Limited.

You should fix your nginx config. Use nginx -t to confirm correct syntax.

That is a very old version. You need to replace that with a newer version that supports post-as-get. Use the snap version if you can. See

3 Likes
3

I updated my certbot. but curl -Ii4 sub.mydomain.com then HTTP/1.1 400 Bad Request
I assume that problem with sites-available default config:

server {
    server_name sub.mydomain.com;
    listen 80;
    listen [::]:80;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    client_max_body_size 2048M;
    error_log   /var/log/nginx/error443.log warn;
    access_log  /var/log/nginx/access443.log;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";
    charset utf-8;
    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass http://192.168.1.100:5000;
      proxy_ssl_session_reuse off;
      proxy_set_header Host $http_host;
      proxy_cache_bypass $http_upgrade;
      proxy_redirect off;
    }
    #listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/sub.mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/sub.mydomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
 }

Is there anything issue with incorrect line?

4

The 400 is probably coming from your proxy_pass server.

I also recommend splitting port 80 server block from port 443. They can be combined but can be very tricky. Usually the port 80 server block would process the http challenge and redirect all other requests to https. Something like:

server {
    server_name example.com www.example.com;
    listen 80;
    listen [::]:80;

    location ~ /.well-known/acme-challenge/ {
      root /var/example/folder;
      ##access_log  /var/log/nginx/challenges.log;  # optional
    } 
    location / {
       return 301 https://$host$request_uri;
    }
}

If you do that make sure to remove the two listen's for port 80 from your port 443 server block

2 Likes
5

@allsolution You have not described your proxy server but maybe it does not support a HEAD request? You could try just : curl -i sub.mydomain.com to use a GET request.

3 Likes
6 
HTTP/1.1 400 Bad Request
Server: nginx/1.14.0 (Ubuntu)
Date: Tue, 13 Sep 2022 02:53:30 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 280
Connection: close

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>
root@bbb:/etc/nginx/sites-available#
7
2 Likes
8

Yes I edited the default by

server {
    server_name sub.mydomain.com;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    client_max_body_size 2048M;
    error_log   /var/log/nginx/error443.log warn;
    access_log  /var/log/nginx/access443.log;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    charset utf-8;

    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass http://192.168.1.100:5000;
      proxy_ssl_session_reuse off;
      proxy_set_header Host $http_host;
      proxy_cache_bypass $http_upgrade;
      proxy_redirect off;
    }
    #listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/sub.mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/sub.mydomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}


server {
    if ($host = sub.mydomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
     return 404;
}
9

When I try certbot -d sub.mydomain.com it shows error again.
What should I check?
Please help me guys

root@ubuntu:/etc/nginx/sites-available# certbot -d sub.mydomain.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for sub.mydomain.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: sub.mydomain.com
  Type:   unauthorized
  Detail: 88.88.88.88: Invalid response from http://sub.mydomain.com/.well-known/acme-challenge/qLVXIIlEV2HltMYM_2MtfFZ-fSjU8ZaUYR8ELS2vt0g: 400

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
10

I still think your proxy_pass server is most likely the one causing the 400. But, your nginx config still looks wrong too. If you want help with that we need to see the output of this

sudo nginx -T

Please place 3 backticks before and after the output like this (as it will be long):
```
output of: nginx -T
```

Or, redirect output to a .txt file and upload that if that is easier

sudo nginx -T >upload.txt
2 Likes
11

This part needs a listen statement:

3 Likes
13

Where can I put listen sir?

14

Try:

server {
    listen 80;
    listen [::]:80;
    if ($host = sub.mydomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
     return 404;
}
2 Likes
15

Also need a server_name value in that server block like:

server_name sub.mydomain.com;

(your now subdomain name)

3 Likes
17

Have you restarted nginx after you made those changes?

Because I don't get the response from http://now.(domain) that I should for that config. Instead, I get an error saying HTTPS is required.

The other reason why that might happen is if you have port forwarding or NAT that is not directing port 80 and port 443 correctly.

3 Likes
18

Thank you sir, Yes I have a static ip and using NAT to communicate domain to server.
How can I determine is that NAT thing problem?

2 Likes
19

Check your NAT to ensure incoming http (port 80) requests go to port 80 for your nginx machine. And, incoming https (port 443) goes to port 443. If you can take a screen snapshot and upload it maybe we will see something you do not.

Because your now subdomain has its own server block that should only respond one of two ways:

  1. Redirect to HTTPS://now.(domain)
  2. Return 404

But, a test curl request instead gets an http 400 with an error saying "The plain HTTP request was sent to HTTPS port"

curl -i now.(domain)

HTTP/1.1 400 Bad Request
Server: nginx/1.14.0 (Ubuntu)
Date: Thu, 15 Sep 2022 01:48:22 GMT

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
(rest of text omitted)

Also, if I use HTTPS but force port 80 I get a successful HTTPS connection just with an expired cert. That should not happen if your ports are handled properly.

curl -i https://now.(domain):80
curl: (60) SSL certificate problem: certificate has expired
2 Likes
20

Thank you. I removed NAT, simply set my static internet ip to ubuntu ip config then done

1 Like
21

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