How to figure out rate limit expiration considering renewals?


#1

Hello,

I’m trying to obtain a certificate for the domain h2763395.stratoserver.net. I ran the command

sudo certbot --nginx -d h2763395.stratoserver.net

on my Ubuntu 16.04 LTS server with nginx version 1.10.3 (Ubuntu) which produced the output

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for h2763395.stratoserver.net
Using default address 80 for authentication.
nginx: [warn] conflicting server name “h2763395.stratoserver.net” on 0.0.0.0:80, ignored
Waiting for verification…
Cleaning up challenges
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: stratoserver.net: see https://letsencrypt.org/docs/rate-limits/
Please see the logfiles in /var/log/letsencrypt for more details.

If I’m interpreting this and the rate limits correctly, this means that in the last 7 days 20 new certificates were issued for the domain stratoserver.net and therefore the rate limit reached.

After googling a bit, I found this very convenient tool to see the last certificates issued for a certain domain. So I ran

lectl stratoserver.net

Unfortunately, I can’t post the output here, because each domain name is converted to a link and new users are restricted to 20 links per post. But the upshot is that there is a long list of more than 300 certificates concluding with the information that the rate limit has been reached but would expire on Wednesday 2018-Mar-21 12:41:00 CET.

If I understand this correctly, the statement that I could issue new certificates on Wednesday 2018-Mar-21 12:41:00 CET is because the 20th certificate in the list was issued 7 days (and 61 minutes) before this time.

My problem is the following: Inspecting the output of lectl I noticed that there are many 7 day windows in which more than 20 certificates were issued, e.g. the last 7 days. I thought that this must be due to renewals also appearing in the list but not contributing to the rate limits, am I right about that? Consistently with this, I observed that the expiration time reported by the lectl moves further into the future over time.
If this is the case, how can I know when the rate limit will expire the next time? Is there a better way to do this than to periodically send requests and hope for the best?

Or is there something else I’m doing wrong?

I’m really stuck at this and any help would be very much appreciated!


#2

Renewals are exempt from the rate limit but they still count towards it. There was an attempt to change this some time ago but it ran into issues and was rolled back. I believe it’s still on the long-term agenda, but for now, this is how things are.

You can’t - at least, not reliably. It depends on the frequency and timing of renewals performed by other users of the shared domain, which you have no reliable way to predict (although I suppose you could try to guess by looking at their history). Unfortunately, it may not even be possible to get a new cert if there are too many renewals happening too frequently.

The best way to get around this is to get your own domain (there are a few ways to get a free one) and point it at your server, then get a certificate for that domain instead.

You might also ask the administrators of stratoserver.net if they would be willing to apply for a rate limit exemption or add the domain to the public suffix list. However they might not be willing to do this and even if they are it will be some time before you can take advantage of it.


#3

Hi John,

Thanks a lot for your prompt reply!

Okay, then I guess you’re right and it’s impossible to get a new certificate for this domain directly.

I actually already have a domain which uses HTTP 301 to redirect to my server. Would I be able to encrypt traffic to my server if I got a certificate for this domain?


#4

It might be possible, but it’s not guaranteed.

Using the 301, not really. You could get a certificate for the domain, with which you could encrypt the initial request and the 301 response, but any further traffic after that would go to the stratoserver domain and would be unencrypted.

However, it should work fine if you can point an A record at the server’s IP address, or an AAAA record at its IPv6 address (if it has one), or even a CNAME to the stratoserver domain.


#5

Okay, thanks again for your help!


#6

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