Rate limit on renewall

Help
1

Hello,

We got a rate limited advise by trying to renew one domain many times accidentally. Could you tell me if I have to wait 7 days to make the renew correctly?. I have some error at this time and for that the renew was executed many times.

Thank you very much.

Regards

2

Hi @ariellumile

there are different rate limits. If you hit the duplicate certificate limit, you have already a certificate, so you don't need a new. If you hit the

Failed Validation limit of 5 failures per account, per hostname, per hour

you have to wait one hour.

So: What's your domain name? To check if you have already a certificate via CT logs. Which command did you used?

Perhaps only your installation doesn't work. Then a new certificate doesn't help.

3

Hi @JuergenAuer,

The domain already has a valid certificate but it expire in 7 days , so i will need renew it.

The domain is serargentino.com and the command used was:

./certbot —nginx renew —cert-name serargentino.com

Thank you.

Regards!

El El lun, 3 sep. 2018 a las 11:49, Juergen Auer letsencrypt@discoursemail.com escribió:

4

Your command didn't work. There

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:true;domain:serargentino.com&lu=cert_search

is no new certificate. So you hit only the 5 failures per account/hostname/hour - limit.

Is this a problem that you answer per mail?

./certbot —nginx renew —cert-name ...

You have to use -- two hypen, not one —.

If this doesn't work: Is there a logfile? /var/log/letsencrypt/letsencrypt.log?

5

Sorry for the mistake about “-”. I really use “–” .

I executed the command ./certbot —nginx renew —cert-name ... and the rate limit notification dissapeared but now I have a new issue:

Waiting for verification...

Cleaning up challenges

Attempting to renew cert (serargentino.com) from /etc/letsencrypt/renewal/serargentino.com.conf produced an unexpected error: Failed authorization procedure. serargentino.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 27b799d5e96b1e10f751888307d71bcb.8ec38f52a4740fe396318014bef81774.acme.invalid from 159.89.243.227:443. Received 2 certificate(s), first certificate had names "serargentino.com, www.serargentino.com", www.serargentino.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 39aef781a41e99fcdd74a08727652d12.b6f7bce35a4613c9109a08f6df133d36.acme.invalid from 159.89.243.227:443. Received 2 certificate(s), first certificate had names "serargentino.com, www.serargentino.com". Skipping.

All renewal attempts failed. The following certs could not be renewed:

/etc/letsencrypt/live/serargentino.com/fullchain.pem (failure)

Please let me know if I have to open a new issue for this new issue.

Thank you very much.

Regards
Ariel

6

You’re using the old tls-sni challenge. If you have a recent enough version of certbot, switching to the http challenge is often easier than getting the tls-sni challenge working. Try this:

./certbot renew --nginx --preferred-challenges http --cert-name serargentino.com

(The --nginx is not needed with renew unless you’re trying to switch to it from a different plugin, but I left it in just in case that’s actually what you’re doing).

Incidentally, I notice you’re using a HTTP 307 response code to redirect to HTTPS, instead of the usual (and recommended) 301. I don’t think that will make a difference to your ability to issue a certificate, at least in this case, but it might be something to look at nonetheless.

7

Hi @jmorahan, thank you for your answer.

I executed the line below:

./certbot renew --nginx --preferred-challenges http --cert-name serargentino.com

and I got this results:

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

   Domain: serargentino.com
   Type:   unauthorized
   Detail: Invalid response from
   http://serargentino.com/.well-known/acme-challenge/Wig-_9myUtwt1UdvoKXseF-ZG7V6CIXHVtnkAQvQX30:
   "<html>
   <head>
   <title>No se encontr&oacute; la p&aacute;gina - Ser
   Argentino</title>
   <link rel="stylesheet" href="https://maxcdn."

...

The redirect to HTTPS is a configuration in a load balancer cloud services. There is not a configuration file that I can modify.

Regards

8

Hmm.

It might be helpful if you could share your nginx configuration for that domain.

9

Hi @jmorahan,

Maybe this information help you to help me :slightly_smiling_face:

The SSL certificate is configurated in the load balancer services in Digital Ocean but it was created in a nginx webserver. At the begining the webserver was public but then it was behind of the load balancer services.

Could the error be caused by this type of infraestructure?. Are there any way to recreate the SSL certificate in another server and then configure it in the load balancer service?

Thank you very much!

Regards!

10

That would certainly explain why the tls-sni challenge didn't work, at least.

Do you have more than one server behind the load balancer? If so, you might need to configure it to send requests for /.well-known/acme-challenge/* paths to a particular backend server, so that certbot can run on that server and be able to answer the challenges. If you can't get the load balancer to do that, you could configure nginx on the other servers to proxy those requests to the server where certbot is running. Or if you have a shared mount for your web root, you could try the --webroot plugin instead of --nginx.

If you just have the one backend server, the problem might be due to some quirk of your nginx configuration that's somehow incompatible with certbot's configuration parser, in which case it would still be useful to see your nginx configuration.

Another possibility might be to allow the load balancer to obtain and install certificates by itself, which it appears Digital Ocean's load balancers are able to do. This would save you the trouble of having to manually install the new cert to the load balancer after each renewal (or writing a script to do so). However you would have to move your DNS to Digital Ocean as well in order to take advantage of this. Also that wouldn't (by itself) secure the connection between the load balancer and the droplet(s).

11

Hi @jmorahan,

Yes, I have a cache server ahead. So, could I configure that to proxy those request that you say?. Reading about load balance features, the services don't allow rules with URIs. You can only use port redirection. I will ask to digital ocean support about this features.

Yes, I know this feature but I don't have the DNS in DO, so I will need migrate it. The problem is that I have this site in production. However is an option.

Thank you very much!

12

So you have a load balancer, and behind that a cache server (or more than one?) and behind that two or more nginx web servers? In that case yes you could configure your cache server to ensure that all requests for /.well-known/acme-challenge/* paths go to a specific nginx web server.

If you have some other configuration, it would help if you could describe it in detail...

13

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