Bag Nginx config

Help
1

Hello,

My nginx config looks like that:

server {
  listen [::]:80;
  listen 80;
  server_name mywebsite.fr www.mywebsite.fr;

  root /var/web/mywebsite/www/public;

  # .well-known/acme-challenge/fiXDtOKkx1O61RqiOXledXA8AlcH2CDLiVQdA4ofO_M:
  location ~ /.well-known {
    allow all;
  }

  return 300 https://www.mywebsite.fr$request_uri;
}

server {
  listen 443 ssl;
  server_name mywebsite.fr;

  ssl_certificate /etc/letsencrypt/live/mywebsite.fr/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mywebsite.fr/privkey.pem;
  ssl_dhparam /etc/nginx/ssl/dhparam4.pem;
  ...

I use the “return 300” to go from http to https. But if I do not comment this line, the letsencrypt command does not work :frowning: I can deal with it for the first time, but I get the same problem with the renew…

So I guest I do not use the good config… Where am I wrong ?

2

Hi @thierryler

300 is "Multiple Choice", that's wrong.

Use 301 or 302.

3

That’s rigth. I just replaced 300 by 302. Thx.

But what about the line to be commented ?

4

If your HTTPS configuration is correct, there should not be a problem. Unfortunately, you’re just saying “the … command does not work” without actually telling us the error et cetera. Please give us the full output of the command you used.

5

Hello,

There is the output when it failed.

/opt/letsencrypt/letsencrypt-auto renew --no-bootstrap
Creating virtual environment...
Installing Python packages...
Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mywebsite.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mywebsite.fr
Using the webroot path /var/web/mywebsite/www/public for all unmatched domains.
Waiting for verification...
Challenge failed for domain mywebsite.fr
http-01 challenge for mywebsite.fr
Cleaning up challenges
Attempting to renew cert (mywebsite.fr) from /etc/letsencrypt/renewal/mywebsite.fr.conf produced an unexpected error: Some challenges have failed.. Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/www.mywebsite.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.mywebsite.fr
Using the webroot path /var/web/mywebsite/www/public for all unmatched domains.
Waiting for verification...
# Hide nginx version information.
Challenge failed for domain www.mywebsite.fr
http-01 challenge for www.mywebsite.fr
Cleaning up challenges
Attempting to renew cert (www.mywebsite.fr) from /etc/letsencrypt/renewal/www.mywebsite.fr.conf produced an unexpected error: Some challenges have failed.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/mywebsite.fr/fullchain.pem (failure)
  /etc/letsencrypt/live/www.mywebsite.fr/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/mywebsite.fr/fullchain.pem (failure)
  /etc/letsencrypt/live/www.mywebsite.fr/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 renew failure(s), 0 parse failure(s)

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

   Domain: mywebsite.fr
   Type:   unauthorized
   Detail: Invalid response from
   https://www.mywebsite.fr/.well-known/acme-challenge/9tbrer_riCYs3W3VvmdOZ5IVjOQPIWmkHaFeWCdKGMk
   [217.182.168.69]: "<html>\r\n<head><title>403
   Forbidden</title></head>\r\n<body
   bgcolor=\"white\">\r\n<center><h1>403
   Forbidden</h1></center>\r\n<hr><center>"

   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.
 - The following errors were reported by the server:

   Domain: www.mywebsite.fr
   Type:   unauthorized
   Detail: Invalid response from
   https://www.mywebsite.fr/.well-known/acme-challenge/q86cFQI27iy4nBCVtx7_a9-KCylIe0kU7O8w8qfWv1Y
   [217.182.168.69]: "<html>\r\n<head><title>403
   Forbidden</title></head>\r\n<body
   bgcolor=\"white\">\r\n<center><h1>403
   Forbidden</h1></center>\r\n<hr><center>"

   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.
6

Please post your real domain. Obscuring it is super detrimental to the process of helping you. You can always edit it out later.

I think you need should wrap this in location block:

location / {
    return 301 https://www.mywebsite.fr$request_uri;
}

Because putting it in the server scope directly prevents that other location block from applying. Hypothetically (I can't test it because of obscured domain) if you then had an nginx location block in your HTTPS server that blocked access to "dotfiles", that could explain your current symptoms.

1 Like
7

I don’t think the HTTP to HTTPS redirect should be outside the HTTP server scope.

The error presented is pretty clear: there is an forbidden error on the HTTPS site of @thierryler server. (Let’s Encrypt has followed the redirect perfectly…)

In the above configuration, the “allow all” for the .well-known directory is only in the HTTP server configuration.

@thierryler should add

  location ~ /.well-known {
    allow all;
  }

to the HTTPS server configuration too.

8

You can try www.sgp4.fr

I renewed yersterday.

Is there a way to force the renew again ?

Here is my config

server {
  listen [::]:80;
  listen 80;
  server_name sgp4.fr www.sgp4.fr;

  root /var/web/sgp4/www/public;

  location ~ /.well-known {
    allow all;
  }

  # 301 or 302 ?
  return 302 https://www.sgp4.fr$request_uri;
}


server {
  listen 443 ssl;
  server_name sgp4.fr;

  ssl_certificate /etc/letsencrypt/live/sgp4.fr/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/sgp4.fr/privkey.pem;
  ssl_dhparam /etc/nginx/ssl/dhparam4.pem;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ...

  return 301 https://www.sgp4.fr$request_uri;
}

server {
  server_name www.sgp4.fr;

  listen [::]:443 ipv6only=on ssl http2;
  listen 443 default_server ssl http2;
  ...
9

Yes, that can be a way to go as well. The reason I did not suggest it is that OP did not post the full virtual host, and the ordering of regex-based locations with nginx can be very subtle. Potentially, that location could get overriden by a dotfile location.

So I felt the safer way was to avoid the redirect entirely and complete the challenge on port 80.

It definitely should be, if you want to have any other location blocks inside the server scope.

10

Thanks for sharing your domain.

You definitely have a rule that is blocking dotfiles:

$ curl -X GET -I https://www.sgp4.fr/.dotfile
HTTP/2 403

$ curl -X GET -I https://www.sgp4.fr/dotfile
HTTP/2 404

If you have a rule that is similar to this:

location ~ /\. {
    deny all;
}

Try adding the rule posted by @Osiris, but you need to insert it above the generic dotfile blocking rule, or it won't work. So like this:

location ~ /\.well-known { 
    allow all;
}
# and here's your existing rule that blocks
location ~ /\. {
    deny all;
}
11

Hello,

I added

  location ~ /.well-known {
    allow all;
  }

into the HTTPS block and it works now (tried on an other server)

  location ~ /.well-known {
    allow all;
  }

  location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
  }

How can I force the renew on my server ? It says that it is skipped:

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/sgp4.fr/fullchain.pem expires on 2019-10-11 (skipped)
  /etc/letsencrypt/live/www.sgp4.fr/fullchain.pem expires on 2019-10-11 (skipped)

Tkx

12

Do you really need to force renewal? Your existing certificate is okay.

If you just need to test whether renewal will work the next time, you can do a dry run:

certbot renew --dry-run
13

Hello,

I did:

/opt/letsencrypt/letsencrypt-auto renew --no-bootstrap --no-self-upgrade --dry-run

And it worked.

Thx so much…

By the way, what’s the deal between “letsencrypt-auto” and “certbot” ? When I installed, I did:

git clone https://github.com/certbot/certbot /opt/letsencrypt --depth=1
/opt/letsencrypt/letsencrypt-auto certonly --rsa-key-size 4096 --webroot --webroot-path /var/web/sgp4/www/public/ -d sgp4.fr
/opt/letsencrypt/letsencrypt-auto certonly --rsa-key-size 4096 --webroot --webroot-path /var/web/sgp4/www/public/ -d www.sgp4.fr

I guest “cerbot” replaces “letsencrypt-auto”. Is there a problem if I continue to use “letsencrypt-auto”?

Th.

14

The names differ based on how you installed Certbot.

certbot-auto and letsencrypt-auto refer to a “portable” version of Certbot that uses virtualenv and avoids installing itself into your package manager. More info here: https://certbot.eff.org/docs/install.html#certbot-auto

certbot usually refers to a version of Certbot that is installed from a package repository.

Which one should you use? You should follow the instructions from https://certbot.eff.org for your operating system and webserver.

Installing from git is usually not recommended. But I don’t think anything will go wrong with your server if you keep using letsencrypt-auto.

2 Likes
15

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