403 Forbidden error on renewal

[JonoEDIT]

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

My domain is: domain.domain.domain.co.uk

I ran this command:$sudo certbot renew --dry-run

It produced this output: 403 Forbidden

My web server is (include version): Nginx - 1.6.2

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

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

I looked like it was pointing to the wrong webroot folder when we inspected the letsencrypt log file so we modified the .conf file in /etc/letsencrypt/renewal and changed the webroot_path and webroot_map value but this doesn’t seem to have helped.

Any suggestions, much appreciated.

[ahaw021]

hi @JonoEDIT

Any reasons why you are not using the nginx authenticator and installer?

Certbot --nginx

The reason why i say that is that it will update your certificate bindings etc.

What I would recommend is that you use the nginx plugin to obtain a new certificate and once that is successful then remove the old certificate you obtained using the webroot method

Andrei

[JonoEDIT]

Hi Andrei,

Thanks for your reply.

Just following instructions here - https://certbot.eff.org/#debianjessie-other

I think I listed Nginx - 1.6.2 as the web server but I think it actually using the ‘webroot’ plugin as suggested on the above link.

Regards

[JonoEDIT]

Here’s the screenshot of the error message that we get when we issue the dry run command

[jared.m]

Your server is refusing to serve files from the .well-known/acme-challenge directory. Try putting a test.txt file there and see if you can load that in your browser. I’m suspecting you will also see the 403. You need to figure out why your web server is refusing to serve from that directory. Posting your nginx configs will help the community assist you with this if you’re having trouble.

[JonoEDIT]

Hi,
We have tried putting a test.txt file the following locations and cannot access it in the browser;

/var/www/html/.well-known
/var/www/custom/.well-known
/var/www/.well-known

We also tried creating the acme-challenge folder as a sub folder to the .well-known and dropping the test.txt file in there but still couldn’t access it in the browser. We are not sure which is the live webroot folder.

All this was done on a server where the dry-run command is successful.

nginx config coming up next.

Thanks

[JonoEDIT]

I can’t upload a .txt file as a new user apparently - how shall I share this nginx conf file with you? If I paste in the contents, the formatting is changed.

[JonoEDIT]

I don’t suppose anyone else has any ideas?

[schoen]

example.txt (91 Bytes)

You can upload text files as forum attachments using the upload button when composing a post. It’s the icon that looks kind of like this ↥.

[jared.m]

New users can’t do this until they reach trust level 1 - it’s a part of the Discourse software. Good news though - it’s easy to reach trust level 1. See https://meta.discourse.org/t/what-do-user-trust-levels-do/4924/3

Basic (1)

If a user sticks around long enough to read a bit, Discourse now trusts them as a basic user.

They can get to trust level 1 by…

entering at least 5 topics
reading at least 30 posts
spend a total of 10 minutes reading posts
Admins can change these thresholds in…

basic_requires_topic_entered
basic_requires_read_posts
basic_requires_time_spent_mins
Users at trust level 1 can…

use all core Discourse functions
Upload images and attachments if enabled
Edit wiki posts
Flag posts
have all new user restrictions removed

[JonoEDIT]

Just to update anyone that may read this. I was able to fix the problem but our situation is quite unique so I would be surprised if our fix helps anyone else, but you never know.
We use the server for our phone system which requires an active SSL certificate to work, the phone system installs nginx and uses a custom config file that was stored in a location I wasn’t aware of. When I eventually found this config file I was able to serve myself files from the server however I still couldn’t get Certbot to run. Adding “allow all;” to the location I was serving in the config file allowed it to work.