Rate-limiting due to authz errors?

I’ve been trying to get a certificate issue. After 5 attempts, it appears I’ve been “locked out”?

Error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently.

The problem is, I need to get this cert issued, and this is now blocking my progress.

How long is this rate limit?

To be honest, getting letsencrypt to work involves several attempts. Rate-limit locking customers from being able to get needed resources due to so few attempts to make the system work is troublesome.

1 Like

I understand your problem as i ran into it myself but this was caused by yourself or myself in my case. There is a staging service for testing which you can use for testing things out which is called with the additional param --test-cert. The staging service has higher rate limit and is there for exactly that reason.

Use staging until you have your setup working and then request one from production - should by fine be now.

Rate limits docu

[quote]
We recently (April 2017) introduced a Failed Validation limit of 5 failures per account, per hostname, per hour. This limit will be higher on staging so you can use staging to debug connectivity problems.[/quote]

1 Like

While I understand the point of this limit, the lockout really needs to be exponential based; one week is a ridiculous amount of time for the first limit hit. Especially because the error mentions nothing of trying --test-cert to work out the kinks. :rolling_eyes:

Turns out the reason I hit this rate is because my site was using https already (without any cert; daily leap of faith). After digging it turns out LE just checks http. Maybe a feature request? :thinking:

Now I need to wait a full week (and therefore roll back all my settings) to make my site secure?! Total lamesauce. :sob:

3 Likes

There are a few different rate limits in place: The one being discussed in this thread is the failed validation limit, which only lasts for an hour.

2 Likes

exactly, running into the same problem…

This limit lasts for an hour. After an hour, you should be able to try again.

You can test against the test server with --staging.

1 Like

I agree with these sentiments. I locked my account out because LE is only hitting the http address, and kept failing to find the .well-known directory. You should at least get a notification on attempt 3 of the hour that you’re going to get locked out and should use --staging to troubleshoot.

is this correct? sudo certbot --staging certonly? It is asking me the following:

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/___.com.conf)

What would you like to do?
-------------------------------------------------------------------------------
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)

This gives me impression I am not in testing environment?

Thanks for the tip on the --staging flag. I’ll have to wait. Two of my domains were easy enough to set up, but I have one that is tied to a wordpress multi-site, and having only heard of “certbot” registrations yesterday afternoon, I googled up some instructions and followed them. And of course, they did not have any mention about the staging flag or what to do about setting up wild-card subdomains since wordpress multi-site sets up subdomains automatically as long as you have them set up in your dns.

So, I made attempts and got shut out. I’m hoping and praying it will only be for an hour. But rather than blocking a person out for a period of time–especially a person new to the program, why not let the certbot command itself figure out if there is an error client side without bothering the main server so that the beginner can make requests, get good, user friendly feedback, learn how to use the system properly, and then when and only when good requests are made, the certbot program can send things through to whatever is done at a central server?

We are always working on this, and I'm hoping to improve it a lot over the next month or so in this regard, but Certbot wouldn't submit a challenge for verification if it didn't believe that the challenge had been set up properly. Certbot has always taken some action that was reasonably calculated to pass the challenge. When challenges fail because of firewalls or web server misconfigurations, it's also difficult for Certbot to know whether or not the user has detected and remedied the problem, particularly because it's hard for Certbot to know what the user's site looks like to the outside world. For example, if a firewall has blocked validation of a TLS-SNI-01 challenge, maybe the user is now re-running Certbot because the problem has been identified and the firewall has been disabled.

if you didn't get a certificate at all, it should just be for an hour starting with your first unsuccessful attempt (the failed challenges rate limit).

Thanks, so much. Actually, I got certificates for nodivorces.com, danieljdick.com, and godsblogs.com, but when I tried to use the subdomains of godsblogs.com with the same cert, it, nginx kept sending me back to the main domain. That is, when I tried to browse to https://dota.godsblogs.com, it sent me to http://godsblogs.com for example. I tried hardwiring the redirection for the subdomains, and it throw up a big red “insecure” error on dota.godsblogs.com for example. So, I tried creating a wildcard certificate and it failed. But then I tried to create them individually adding them to the previous file that was there and somehow I ended up with an error and got locked out.

I think I’ll look at the staging switch before trying again as I do not want to be locked out. But there’s no hurry. I just set things so that only three main domains were secured and the rest were not.

Thanks again for your advice.

Were you using the Nginx autoconfiguration mode of Certbot? I’m curious to know if that might have contributed to the “redirect to main domain” problem you had.

I kind of cooked up a klugey little bash script - not much, but it made it easier for me to set up certs for my wordpress multi-site installation running with nginx and the nginx-helper plugin.

Definitely not fancy or for general use, but it made my job easier nevertheless. I ran it with the --dry-run switch turned on and just printed out the command until it looked right, and then executed it with the dry-run turned on first until it had no errors before giving it a real run.

It fishes out all your domains from the output of the nginx-helper, adds in the additional domains and takes out the excluded domains all set at the top. Be sure to set your wordpress root directory, too.

#!/bin/bash
#
# addcerts - add certificates to a certificate file
# author: Daniel J. Dick
#
# Note: This is for wordpress multi-site installations.
#   with the plugin, nginx-helper running on Linux.
#   I'm using Debian 8, but Ubuntu 14 or 16 should probably work.
#
#   I tend to like to build up commands and directories gradually to
#   allow me or anyone to comment out anything not desired.
#
# 1) Follow instructions in the comments below to adjust vars and comment out parts
# 2) Adjust the configuration for nginx to use the ssl cert files
# 3) Restart nginx
# 4) You may need to clear browser caches
#
CERTNAME='example.com'
excluded_domains="blah1.org blah2.org"
additional_domains="yesiree1.com yesiree2.com"

WP_DIR=/home/wordpress/wordpress

# These four should not need adjusting
WP_CONTENT=${WP_DIR}/wp-content
WP_UPLOADS=${WP_CONTENT}/uploads
WP_NGINX_HELPER=${WP_UPLOADS}/nginx-helper
WP_NGINX_MAP=${WP_NGINX_HELPER}/map.conf

##### Building the basic certbot command #####
# Comment out the parts you do not want
#
# Start the commmand out with a certbot certonly - needed!
CERTBOT="certbot certonly"

# Comment this out to do a real run
#    Warning: repeat failures can get you blocked so try with this left in first!
#    then comment it out when you find there are no longer any errors.
CERTBOT="$CERTBOT --dry-run"

# Keep the -n as this is by nature non-interactive - a script
CERTBOT="$CERTBOT -n"

# This tells the cert where your wordpress directory is
CERTBOT="$CERTBOT --webroot --webroot-path=${WP_DIR}"

# Adjust your certificate name above
CERTBOT="$CERTBOT --cert-name ${CERTNAME}"



#### This searches the nginx helper map for all domains or subdomains
all_domains=`cat ${WP_NGINX_MAP} | awk '{print $1}'`


#Note which domains already have certificates - just for comparison
cert_domains=`certbot certificates | grep Domain`

for i in $cert_domains;do
        if [[ $i != "Domains:" ]]
        then echo Already Present: $i;
        fi
done

# Add all domains that are not excluded above
for i in $all_domains $additional_domains; do
        if echo $excluded_domains | grep -q "$i";then
        continue
        fi
        CERTBOT="${CERTBOT} -d $i"
done


echo This command will be issued:
echo $CERTBOT


# Comment this out if you just want to see the command and not execute it.
# `$CERTBOT`

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