VinstaCP issuance problem - frustration with failed validation rate limit


#1

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

My domain is:

businessofbrands.co.uk

I ran this command:

v-add-letsencrypt-domain rachel businessofbrands.co.uk

It produced this output:

Error: LetsEncrypt challenge request 429

My operating system is (include version):

Ubuntu 16.0.04

My web server is (include version):

nginx 1.11.13

My hosting provider, if applicable, is:

Linode

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):

Yes, VinstaCP

Hi,

This is so frustrating! I’ve verified the folder works for the challenge:

http://businessofbrands.co.uk/.well-known/acme-challenge/foo.html

…yet I kept getting an error (not matching). I have my DNS set to update every 5 minutes, so there is no way (after an hour) it should still be using the old version. I can’t get the site back up again until this is done, as it’s all on SSL!

Why such a low (silly) limit? I’m now going to have to see if I can somehow grab the certificates from my other server (where it used to be hosted), but I’m not even sure that is an option as I can’t seem to log in to it anymore.

So frustrating :sob:


#2

Does it work for a plain text file, and serve it as plain text? No javascript or other wrapping?


#3

Hi,

Do you mean like this?

http://businessofbrands.co.uk/.well-known/acme-challenge/test.txt

It literally is a simple wrapper in nginx:

server {
    listen      80;
    listen      [::]:80;
    server_name businessofbrands.co.uk www.businessofbrands.co.uk;
    error_log  /var/log/apache2/domains/businessofbrands.co.uk.error.log error;

    location '/.well-known/acme-challenge' {
        root /home/rachel/web/businessofbrands.co.uk/public_html;
        allow all;
    }

    location / {
        rewrite ^(.*) https://businessofbrands.co.uk$1 permanent;
    }

}

The same code worked fine on another of my domains(on the same server), so I don’t get why this one is having such a problem (and ironically, this is the one I need to get moved over ASAP… the other one is just a test domain I was trying out before the move)

Is there a place we can find out what IP it’s hitting? I did read that it uses the Google Public DNS servers to work out where a domain is, but then I also read it got cached for 24 hours? (even though my TTL is lower)

Thanks

Andy


#4

Because the rate limits are fine for normal use and for testing one should use the staging environment.

If one uses a control panel, such as VinstaCP, the control panel should “just work”. If not, you should contact the developers of the control panel used.


#5

My understanding is that Let’s Encrypt uses whatever nameservers are specified as authoritative for your domain. As to finding out what IP it’s hitting, if you were using certbot, it would tell you, and also tell you much more specifically what the error was. What logs does your control panel make available?


#6

The control panel isn’t the problem. The DNS caching is :wink: As you can see above, the pages DO load fine - but my guess is that it’s looking at the old (wrong) server


#7

The Let’s Encrypt validation server doesn’t cache anything, including DNS requests. It always asks the authoritive name server directly.

Further, the error “Error: LetsEncrypt challenge request 429” isn’t very helpful. I’m guessing it’s an error from the control panel software, as this isn’t likely to be an error directly from the Let’s Encrypt validation server.

And some other thing: I just clicked on your foo.html and test.txt links above and your site is completely broken. I’m getting ERR_EMPTY_RESPONSE as wel as ERR_CONNECTION_RESET errors in Chrome.

The latter is probably because I have IPv4 and IPv6 dual stack, obviously preferring IPv6… And your site doesn’t work through IPv6.


#8

Hi @steampunkjnkies,

I’ve updated the issue title to more accurately reflect the problem. Please also take a moment to review the community guidelines.

The failed authorization limit is higher in the staging environment specifically to help with the case where you are troubleshooting. I second @Osiris’s recommendation that you switch to the staging environment while you work out the kinks in your process.

Can you share the exact error that you see? Do you have any additional logs?

Right now you’ve shared the 429 error that was caused by too many failed validations but that won’t help identify the problem that caused the failed validations.

I think there might be some wires crossed here. For an HTTP-01 challenge it likely isn’t a DNS problem. [quote=“steampunkjnkies, post:3, topic:31863”]
I did read that it uses the Google Public DNS servers to work out where a domain is, but then I also read it got cached for 24 hours? (even though my TTL is lower)
[/quote]

Can you share where you read this? It’s not true and I’d like to get it fixed if possible. The Let’s Encrypt validation server does not use Google public DNS to work out a domain and does not cache for 24 hours.


#9

Thanks @danb35. Unfortunately it only likes working with their built in system. Unfortunately I don’t get an error, and can’t seem to find any log it would use:

https://vestacp.com/docs/#config-log-location-debian-ubuntu

I just tried it again, and get:

root@com:~# v-add-letsencrypt-domain rachel businessofbrands.co.uk
Error: Invalid response from http://businessofbrands.co.uk/.well-known/acme-challenge/A11xWfTeE7OwTLP3XQ9uzhqUzBYTedSB95ZwVyZxLeE: \

I’ve renamed the .well-known folder, just in case the server would prefer to create it (and the sub-folder)

However, after doing that change, I now can’t test it again as I get the “too many certificates issues” problem :frowning:

root@com:~# v-add-letsencrypt-domain rachel businessofbrands.co.uk
Error: LetsEncrypt challenge request 429

#10

@cpu Does Boulder perfer IPv6 over IPv4? If so, that might be the reason it’s not working.


#11

It does not, though there is demand for that approach and I believe we’ll switch to v6 preferred with a v4 fallback some point in the future.


#12

@cpu , thanks :slight_smile:

The failed authorization limit is higher in the staging environment specifically to help with the case where you are troubleshooting. I second @Osiris’s recommendation that you switch to the staging environment while you work out the kinks in your process.

Thanks. I’m not so sure how / where I would do that though :confused:

Can you share where you read this? It’s not true and I’d like to get it fixed if possible. The Let’s Encrypt validation server does not use Google public DNS to work out a domain and does not cache for 24 hours.

Sorry, it was yesterday I read it (can’t remember where now, but if I come across it again, I’ll give you a shout :))

It looks like I do have an ipv6 issue though. ipv4 works fine, but not ipv6. Will dig into that (I doubt its the problem, but needs fixing anyway);

root@steamdev2:~# curl -Iv4 http://businessofbrands.co.uk
* Rebuilt URL to: http://businessofbrands.co.uk/
* Hostname was NOT found in DNS cache
*   Trying 178.79.134.35...
* Connected to businessofbrands.co.uk (178.79.134.35) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: businessofbrands.co.uk
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
* Server nginx is not blacklisted
< Server: nginx
Server: nginx
< Date: Tue, 11 Apr 2017 14:24:17 GMT
Date: Tue, 11 Apr 2017 14:24:17 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 178
Content-Length: 178
< Connection: keep-alive
Connection: keep-alive
< Keep-Alive: timeout=60
Keep-Alive: timeout=60
< Location: https://businessofbrands.co.uk/
Location: https://businessofbrands.co.uk/

<
* Connection #0 to host businessofbrands.co.uk left intact
root@steamdev2:~# curl -Iv6 http://businessofbrands.co.uk
* Rebuilt URL to: http://businessofbrands.co.uk/
* Hostname was NOT found in DNS cache
*   Trying 2a01:7e00::f03c:91ff:febc:659...
* Connected to businessofbrands.co.uk (2a01:7e00::f03c:91ff:febc:659) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: businessofbrands.co.uk
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

#13

I still can’t seem to get ipv6 working on port 80 :confused: The weird thing, is that it works fine on 443!

root@com:~# wget http://businessofbrands.co.uk/.well-known/acme-challenge/foo.html
--2017-04-11 15:36:25--  http://businessofbrands.co.uk/.well-known/acme-challenge/foo.html
Resolving businessofbrands.co.uk (businessofbrands.co.uk)... 2a01:7e00::f03c:91ff:febc:659, 178.79.134.35
Connecting to businessofbrands.co.uk (businessofbrands.co.uk)|2a01:7e00::f03c:91ff:febc:659|:80... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

I’m wondering if this could be part of the problem.The stupid thing is that it was working fine yesterday! The only 2 things I installed since it was all working fine, is:

sudo apt-get install build-essential
sudo apt-get install libdbd-mysql-perl

…and I can’t imagine either of those would break stuff :confused:

I need to call it a day - I’ll have to change the DNS back over to the old IP’s, otherwise the site is going to be offline.


#14

Ok, I’m just coming back to this. I have a test page showing up fine:

http://businessofbrands.co.uk/.well-known/acme-challenge/foo.html

However, when trying to set it up I get:

Error: Invalid response from http://businessofbrands.co.uk/.well-known/acme-challenge/N8cnsfKUR6Ydh0xrFZe99Zx1puCRQsNxbve9KFEDctM: \

This is what I have setup for that bit:

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

I’m a bit wary of just keeping on trying, otherwise it will lock me out again :frowning: Any ideas?

Cheers

Andy


#15

Mmm ok, well not ideal - but I got it going with the basic certbot-auto:

certbot-auto certonly -a webroot --webroot-path=/home/user/web/businessofbrands.co.uk/public_html -d www.businessofbrands.co.uk -d cdn.businessofbrands.co.uk -d mail.businessofbrands.co.uk

I guess there must be a bug. Bit annoying, as I was hoping to use the fully integrated method of VestaCP to create and manage the certs, but this will have to do :slight_smile:

Cheers

Andy


#16

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