Too many certificates already issued for g9telecom.pt

Help
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.

I was trying to produce a new certificate for domain ilc.dev.g9telecom.pt. I tested on the last Friday, yesterday and today, with the same results.

I ran this command, as root in a bash shell: certbot-auto --redirect --uir --apache -d skeleton.dev.g9telecom.pt

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for skeleton.dev.g9telecom.pt
Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
There were too many requests of a given type :: Error finalizing order :: too many certificates already issued for: g9telecom.pt: see https://letsencrypt.org/docs/rate-limits/
Please see the logfiles in /var/log/letsencrypt for more details.

When checking on crt.sh, at https://crt.sh/?q=%.g9telecom.pt I confirmed that only 1 certificate was issued in the past 7 days, and it was a renovation, and so I’m not even close to the 20 certificates per week limit.

I was able to issue the certificate with the staging server.

This is a virtual machine, it was cloned and I’ve tried on Friday to issue a certificate for another hostname in the same domain, which failed. Could this be related to use the exact same account in another host? Don’t think so, but after issuing dozens of certificates in the past years, this is the first time that I’ve got this error without a reason.

I’m running a Apache/2.4.6 on a CentOS Linux release 7.4.1708 (Core).

2

Hi,

From my view, you aren’t close to any of the certificate rate limits too… You have 5 certificates issued to this domain in the past 7 days, but not with the same hostname etc…

@schoen @cpu can you please take a look at this issue?

Thank you

3

Hi @bigs21

actual, crt.sh is a little bit slow. Checking

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

there are a lot of certificates starting from 2018-07-19 or later.

1 Like
4

They’re all renewals, except for one, as crt.sh indicates (it wasn’t slow a few minutes ago). It might be the case, as they total above 20 certificates.

5

Five certificates in total shouldn’t prevent po from requesting another certificate… (The rate limit corresponding to this should be 20 certificates in total each week)

6

The total number of issued certificates on the domain is above 100. New certificates in the 7 days is 1, but with renewals it’s above 20 (25 or so).
I guess that’s the issue, but now I want to confirm.

7

Okay… That’s the issue then… (However, I don’t see that much certificate when checking through Google CT logs)

Although the renewal doesn’t count as duplicate certificates, it will still count toward the total certificates per week & get rate limited.

A suggestion is, request new certificate first, then renew the existing certificate (you should still able to renew even you get rate limited)

Thank you

8

I counted 25 total certificates issued/renewed since 19/07/2018 (last 7 days), 21 of them issued/renewed on the July 19th. That's the problem, in that case.

Currently, we have certificates spread across several servers, and they're renewed daily on their server by a nightly crontab.
I was renewing certificates 45 days before they expire, which I changed yesterday to 30. That will help to have many less renewals every week (1/3 less).

I don't know when I need to issue new certificates, and that is rare nowadays, and so, how do you sugest to issue before renewing? When does the 20 weekly issued certificates reset occurs?

9

It's a rolling window. As soon as you have less than 20 certificates within the last 168 hours, you can issue another one.

Restrict your renewal scheduled task to a certain day in the week, which will give you a predictable time window in which you can issue new certificates before renewals eat up your 20+/20.

1 Like
10

Well, from my perspective, your second sentence, does not work well with the first one.
Let's see: I schedule a task to renew on saturdays at 2 am, I renew 20 certificates in a given saturday, and so in the next week I can't issue 1 new certificate, although I could in the previous week. And if in the next week I renew 20 more, that's 2 weeks where I can't renew certificates.

Unless we apply for a higher limit, this seems unsolvable for some cases, no?

11

If you are renewing 20 certificates every week, yes, I imagine you are right. Though, in that case, you can set renewals to be bi-weekly, which should be possible given that renewals begin at 30 days from expiration. The rope does seem to run out eventually though.

12

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