Problem with ssl renew


#1

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: agrozona.bg

I ran this command:

letsencrypt-auto --config /etc/letsencrypt/cli.ini -d agrozona.bg --force-renew --no-redirect

and

certbot certonly --cert-name agrozona.bg

It produced this output:

Failed authorization procedure. agrozona.bg (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://agrozona.bg/.well-known/acme-challenge/G9A7v98UqcRpIU2NvW4zSxIhDZFVY-O2wjQ2zOeq5ik: “\r\n403 Forbidden\r\n<body bgcolor=“white”>\r\n

403 Forbidden

\r\n

and hit the limit after several attempts

An unexpected error occurred:
There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

My web server is (include version): nginx

The operating system my web server runs on is (include version): Ubuntu 16.04.5 LTS

My hosting provider, if applicable, is: I am admin and developer fot the site

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


#2

Hi @john_gahan

if you use http-01 - validation, Certbot creates a file under /.well-known/acme-challenge. But your domain (check via https://check-your-website.server-daten.de/?q=agrozona.bg ) answers with a http status 403 - Forbidden:


Domainname Http-Status redirect Sec. G
http://agrozona.bg/
94.156.223.14 301 https://agrozona.bg/ 0.090 A
http://www.agrozona.bg/
94.156.223.14 301 https://agrozona.bg/ 0.200 E
https://www.agrozona.bg/
94.156.223.14 301 https://agrozona.bg/ 1.610 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
https://agrozona.bg/
94.156.223.14 200 1.807 N
Certificate error: RemoteCertificateChainErrors
http://agrozona.bg/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
94.156.223.14 403 0.086 M
Forbidden
http://www.agrozona.bg/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
94.156.223.14 403 0.090 M
Forbidden

Your root / works. But fetching the not existing file

http://www.agrozona.bg/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de

your server doesn’t answer with a 404, instead with a 403.

So Letsencrypt can’t get this file.

Check your directory permissions of /.well-known/acme-challenge.

Or you have a global bot/spam detection which is wrong.


#3

how is generated this path - via webserver config ?
can I search for it manually to see is is created and where ?


#4

You have a

Server: nginx

So check your webserver configuration. There should be something like

location / {
root /data/www;
}

Then /data/www is your root, so /data/www/.well-known/acme-challenge is the directory.

Create there a file (file name 1234) and try to load it with your browser:

http://www.agrozona.bg/.well-known/acme-challenge/1234

#5

just hit the limit gain

An unexpected error occurred:
There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

I do not see path /.well-known/acme-challenge in my system

shall I created it myself

or certbot will create it ?

Regards


#6

I setup path manually and can see this link now

http://www.agrozona.bg/.well-known/acme-challenge/1234.html


#7

Yep, now it’s better:

Domainname Http-Status redirect Sec. G
http://agrozona.bg/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
94.156.223.14 404 0.094 A
Not Found
http://www.agrozona.bg/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
94.156.223.14 404 0.086 A
Not Found

Both are sending a 404 (not found), not a 403.

So wait one hour, then the “failed limit” is gone.


#8

Can you reset the limit please and not wait an hour ?

Regards


#9

Hello again

just tried now again and got error again

Failed authorization procedure. www.agrozona.bg (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.agrozona.bg/.well-known/acme-challenge/97ljCP7XAjNuzDMW9QxF4ozgKuzWwpH_I5WY_neFjbM: “\r\n404 Not Found\r\n<body bgcolor=“white”>\r\n

404 Not Found

\r\n

this link is still working

http://www.agrozona.bg/.well-known/acme-challenge/1234.html

I do not understand you is this file is supposed to be written by certbot tot the webroot folder 97ljCP7XAjNuzDMW9QxF4ozgKuzWwpH_I5WY_neFjbM

there is not such file on the system after running

letsencrypt-auto --config /etc/letsencrypt/cli.ini -d agrozona.bg -d www.agrozona.bg --force-renew --no-redirect

Regards


#10

Hello,

I solved my problem with this link - https://stackoverflow.com/questions/38382739/certbot-not-creating-acme-challenge-folder

Your support was not useful

Your system has problem with large nginx conf files

Hope it will be solved in next months

Regards


#11

Hi @john_gahan,

It is not possible to reset the rate limits. I recommend you use our staging environment while you are debugging your setup to avoid hitting these rate limits.

I’m glad to hear you solved your problem. :+1:

I don’t think this is a fair comment and would ask you to revisit our community guidelines. @JuergenAuer is a volunteer and was engaging earnestly to try and help you with your problems.


#12

The thread that you linked to does mention that the user’s configuration file was long, but apperas to concludes that the problem with the nginx configuration was that it was lacking

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

rather than simply that it was long.

In order to use certbot --webroot, your existing web server has to be capable of serving the static challenge files from the specified webroot location. If its configuration prevents that, its configuration has to be changed in order to use --webroot.


#13

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