Too many requests of a given type :: Error creating new order ::

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.

My domain is:

ryuuzaki.jp

I ran this command:

certbot certificates

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Attempting to parse the version 0.35.1 renewal configuration file found at /etc/letsencrypt/renewal/mail.ryuuzaki.jp.conf with version 0.31.0 of Certbot. This might not work.
Attempting to parse the version 0.35.1 renewal configuration file found at /etc/letsencrypt/renewal/ryuuzaki.jp.conf with version 0.31.0 of Certbot. This might not work.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: mail.ryuuzaki.jp
    Domains: mail.ryuuzaki.jp
    Expiry Date: 2020-06-29 02:02:43+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/mail.ryuuzaki.jp/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/mail.ryuuzaki.jp/privkey.pem
  Certificate Name: ryuuzaki.jp
    Domains: ryuuzaki.jp
    Expiry Date: 2020-06-26 14:05:20+00:00 (VALID: 86 days)
    Certificate Path: /etc/letsencrypt/live/ryuuzaki.jp/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/ryuuzaki.jp/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version):

not sure what does this mean?

The operating system my web server runs on is (include version):

|Distributor ID:|Ubuntu|
|Description:|Ubuntu 18.04.4 LTS|
|Release:|18.04|
|Codename:|bionic|

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

yes, or at least run sudo commands.

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

no, only terminal

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot --version
certbot 0.31.0

certbot-auto --version
zsh: command not found: certbot-auto

I saw other similar topics as old as 2015 where it said to deactivate the ipv6 or something, but I don’t know what parts of those to follow to try to fix this issue.

I am getting an email from Cron Daemon:

Subject: Cron <root@server> /opt/certbot-auto renew --quiet --no-self-upgrade --force-renewal

Attempting to renew cert ([mail.ryuuzaki.jp](http://mail.ryuuzaki.jp/)) from /etc/letsencrypt/renewal/mail.ryuuzaki.jp.conf produced an unexpected error: urn:ietf:params:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new order :: too many certificates already issued for exact set of domains: [mail.ryuuzaki.jp](http://mail.ryuuzaki.jp/): see https://letsencrypt.org/docs/rate-limits/. Skipping.
Attempting to renew cert ([ryuuzaki.jp](http://ryuuzaki.jp/)) from /etc/letsencrypt/renewal/ryuuzaki.jp.conf produced an unexpected error: urn:ietf:params:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new order :: too many certificates already issued for exact set of domains: [ryuuzaki.jp](http://ryuuzaki.jp/): see https://letsencrypt.org/docs/rate-limits/. Skipping.
All renewal attempts failed. The following certs could not be renewed:
 /etc/letsencrypt/live/[mail.ryuuzaki.jp/fullchain.pem](http://mail.ryuuzaki.jp/fullchain.pem) (failure)
 /etc/letsencrypt/live/[ryuuzaki.jp/fullchain.pem](http://ryuuzaki.jp/fullchain.pem) (failure)
2 renew failure(s), 0 parse failure(s)

I can confirm that my server is trying to do 4 requests per day per certificate here.
https://crt.sh/?q=ryuuzaki.jp
But I don’t know, how or if I even did the correct settings.
I am trying to run a website https://ryuuzaki.jp
And the https seems to work fine. (it shows the lock)

And also a mail server mail.ryuuzaki.jp
I can receive and send emails with no problem. But sometimes my iPhone complains about the server certificate, and some other times it doesn’t, my MacBook Pro computer is setup with the same email account and I can send and receive without any complains.

I’m not sure if both mail.ryuuzaki.jp and the normal ryuuzaki.jp should be on the same certificate, or are they ok in different directories, maybe each is asking for more renewals? how can I combine them or safely remove one without breaking my website or email server. I am pretty confused.

I am so sorry to ask the same thing other people has asked about the “too many requests” error, but going trough all of the posts and answers from 5 different posts, it didn’t give me an idea of how to fix this error on my server.

Any help would be so much appreciate it.

Ryuuzaki Julio

Remove the forcing of renewals from cron job.
Your certs are just fine.

2 Likes

Oh wow, so fast answer.
I have only used crontab on Raspberry Pi.
Would you happen to know how can I edit the Cron Job on this Ubuntu server?

sudo crontab -e

is empty TwT

Hi,

Try to check it in /etc/cron.d/certbot or /etc/cron.d/certbot-auto

Thank you

1 Like

Hi Stevenzhu

Thank you so much.
I did found the /etc/cron.d/certbot one and opened it the uncommented parts say:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

It doesn’t seem to have -force-renewal anywhere. Is there somewhere else I could have that command?

Sorry I have no idea…
Maybe @schoen knows where it might be?

Thank you

1 Like

Hi @RyuuzakiJulio,

Could we see some of the logs from /var/log/letsencrypt? They should reveal whether Certbot is being run with --force-renewal or not.

Sometimes this problem can occur if the symbolic links in /etc/letsencrypt/live are corrupted due to manual renaming or editing of the certificate data there. Could you also run this command and show us the output?

sudo ls -lR /etc/letsencrypt/{archive,live,renewal}

1 Like

Runaway cron job… maybe under another user?

1 Like

Absolutely! Here you go, this is what that command spits out:

/etc/letsencrypt/archive:
total 8
drwxr-xr-x 2 root root 4096 Mar 31 12:02 mail.ryuuzaki.jp
drwxr-xr-x 2 root root 4096 Mar 29 00:05 ryuuzaki.jp

/etc/letsencrypt/archive/mail.ryuuzaki.jp:
total 160
-rw-r--r-- 1 root root 1911 Mar 31 12:02 cert10.pem
-rw-r--r-- 1 root root 1911 Mar 22 01:22 cert1.pem
-rw-r--r-- 1 root root 1915 Mar 22 12:04 cert2.pem
-rw-r--r-- 1 root root 1915 Mar 23 00:01 cert3.pem
-rw-r--r-- 1 root root 1911 Mar 23 12:01 cert4.pem
-rw-r--r-- 1 root root 1911 Mar 24 00:07 cert5.pem
-rw-r--r-- 1 root root 1915 Mar 29 12:02 cert6.pem
-rw-r--r-- 1 root root 1911 Mar 30 00:07 cert7.pem
-rw-r--r-- 1 root root 1915 Mar 30 12:06 cert8.pem
-rw-r--r-- 1 root root 1915 Mar 31 00:04 cert9.pem
-rw-r--r-- 1 root root 1647 Mar 31 12:02 chain10.pem
-rw-r--r-- 1 root root 1647 Mar 22 01:22 chain1.pem
-rw-r--r-- 1 root root 1647 Mar 22 12:04 chain2.pem
-rw-r--r-- 1 root root 1647 Mar 23 00:01 chain3.pem
-rw-r--r-- 1 root root 1647 Mar 23 12:01 chain4.pem
-rw-r--r-- 1 root root 1647 Mar 24 00:07 chain5.pem
-rw-r--r-- 1 root root 1647 Mar 29 12:02 chain6.pem
-rw-r--r-- 1 root root 1647 Mar 30 00:07 chain7.pem
-rw-r--r-- 1 root root 1647 Mar 30 12:06 chain8.pem
-rw-r--r-- 1 root root 1647 Mar 31 00:04 chain9.pem
-rw-r--r-- 1 root root 3558 Mar 31 12:02 fullchain10.pem
-rw-r--r-- 1 root root 3558 Mar 22 01:22 fullchain1.pem
-rw-r--r-- 1 root root 3562 Mar 22 12:04 fullchain2.pem
-rw-r--r-- 1 root root 3562 Mar 23 00:01 fullchain3.pem
-rw-r--r-- 1 root root 3558 Mar 23 12:01 fullchain4.pem
-rw-r--r-- 1 root root 3558 Mar 24 00:07 fullchain5.pem
-rw-r--r-- 1 root root 3562 Mar 29 12:02 fullchain6.pem
-rw-r--r-- 1 root root 3558 Mar 30 00:07 fullchain7.pem
-rw-r--r-- 1 root root 3562 Mar 30 12:06 fullchain8.pem
-rw-r--r-- 1 root root 3562 Mar 31 00:04 fullchain9.pem
-rw------- 1 root root 1704 Mar 31 12:02 privkey10.pem
-rw------- 1 root root 1704 Mar 22 01:22 privkey1.pem
-rw------- 1 root root 1708 Mar 22 12:04 privkey2.pem
-rw------- 1 root root 1704 Mar 23 00:01 privkey3.pem
-rw------- 1 root root 1704 Mar 23 12:01 privkey4.pem
-rw------- 1 root root 1704 Mar 24 00:07 privkey5.pem
-rw------- 1 root root 1704 Mar 29 12:02 privkey6.pem
-rw------- 1 root root 1704 Mar 30 00:07 privkey7.pem
-rw------- 1 root root 1704 Mar 30 12:06 privkey8.pem
-rw------- 1 root root 1708 Mar 31 00:04 privkey9.pem

/etc/letsencrypt/archive/ryuuzaki.jp:
total 160
-rw-r--r-- 1 root root 1899 Mar 29 00:05 cert10.pem
-rw-r--r-- 1 root root 1899 Mar 19 17:28 cert1.pem
-rw-r--r-- 1 root root 1903 Mar 20 00:03 cert2.pem
-rw------- 1 root root 1899 Mar 20 12:04 cert3.pem
-rw-r--r-- 1 root root 1903 Mar 21 00:05 cert4.pem
-rw-r--r-- 1 root root 1903 Mar 21 12:04 cert5.pem
-rw-r--r-- 1 root root 1899 Mar 27 00:01 cert6.pem
-rw-r--r-- 1 root root 1899 Mar 27 12:04 cert7.pem
-rw-r--r-- 1 root root 1903 Mar 28 00:04 cert8.pem
-rw-r--r-- 1 root root 1899 Mar 28 12:08 cert9.pem
-rw-r--r-- 1 root root 1647 Mar 29 00:05 chain10.pem
-rw-r--r-- 1 root root 1647 Mar 19 17:28 chain1.pem
-rw-r--r-- 1 root root 1647 Mar 20 00:03 chain2.pem
-rw-r--r-- 1 root root 1647 Mar 20 12:04 chain3.pem
-rw-r--r-- 1 root root 1647 Mar 21 00:05 chain4.pem
-rw-r--r-- 1 root root 1647 Mar 21 12:04 chain5.pem
-rw-r--r-- 1 root root 1647 Mar 27 00:01 chain6.pem
-rw-r--r-- 1 root root 1647 Mar 27 12:04 chain7.pem
-rw-r--r-- 1 root root 1647 Mar 28 00:04 chain8.pem
-rw-r--r-- 1 root root 1647 Mar 28 12:08 chain9.pem
-rw-r--r-- 1 root root 3546 Mar 29 00:05 fullchain10.pem
-rw-r--r-- 1 root root 3546 Mar 19 17:28 fullchain1.pem
-rw-r--r-- 1 root root 3550 Mar 20 00:03 fullchain2.pem
-rw-r--r-- 1 root root 3546 Mar 20 12:04 fullchain3.pem
-rw-r--r-- 1 root root 3550 Mar 21 00:05 fullchain4.pem
-rw-r--r-- 1 root root 3550 Mar 21 12:04 fullchain5.pem
-rw-r--r-- 1 root root 3546 Mar 27 00:01 fullchain6.pem
-rw-r--r-- 1 root root 3546 Mar 27 12:04 fullchain7.pem
-rw-r--r-- 1 root root 3550 Mar 28 00:04 fullchain8.pem
-rw-r--r-- 1 root root 3546 Mar 28 12:08 fullchain9.pem
-rw-r--r-- 1 root root 1704 Mar 29 00:05 privkey10.pem
-rw-r--r-- 1 root root 1704 Mar 19 17:28 privkey1.pem
-rw-r--r-- 1 root root 1704 Mar 20 00:03 privkey2.pem
-rw-r--r-- 1 root root 1704 Mar 20 12:04 privkey3.pem
-rw-r--r-- 1 root root 1704 Mar 21 00:05 privkey4.pem
-rw-r--r-- 1 root root 1704 Mar 21 12:04 privkey5.pem
-rw-r--r-- 1 root root 1704 Mar 27 00:01 privkey6.pem
-rw-r--r-- 1 root root 1704 Mar 27 12:04 privkey7.pem
-rw-r--r-- 1 root root 1704 Mar 28 00:04 privkey8.pem
-rw-r--r-- 1 root root 1708 Mar 28 12:08 privkey9.pem

/etc/letsencrypt/live:
total 12
drwxr-xr-x 2 root root 4096 Mar 31 12:02 mail.ryuuzaki.jp
-rw-r--r-- 1 root root  740 Mar 22 01:22 README
drwxr-xr-x 2 root root 4096 Mar 29 00:05 ryuuzaki.jp

/etc/letsencrypt/live/mail.ryuuzaki.jp:
total 4
lrwxrwxrwx 1 root root  41 Mar 31 12:02 cert.pem -> ../../archive/mail.ryuuzaki.jp/cert10.pem
lrwxrwxrwx 1 root root  42 Mar 31 12:02 chain.pem -> ../../archive/mail.ryuuzaki.jp/chain10.pem
lrwxrwxrwx 1 root root  46 Mar 31 12:02 fullchain.pem -> ../../archive/mail.ryuuzaki.jp/fullchain10.pem
lrwxrwxrwx 1 root root  44 Mar 31 12:02 privkey.pem -> ../../archive/mail.ryuuzaki.jp/privkey10.pem
-rw-r--r-- 1 root root 692 Mar 22 01:22 README

/etc/letsencrypt/live/ryuuzaki.jp:
total 4
lrwxrwxrwx 1 root root  36 Mar 29 00:05 cert.pem -> ../../archive/ryuuzaki.jp/cert10.pem
lrwxrwxrwx 1 root root  37 Mar 29 00:05 chain.pem -> ../../archive/ryuuzaki.jp/chain10.pem
lrwxrwxrwx 1 root root  41 Mar 29 00:05 fullchain.pem -> ../../archive/ryuuzaki.jp/fullchain10.pem
lrwxrwxrwx 1 root root  39 Mar 29 00:05 privkey.pem -> ../../archive/ryuuzaki.jp/privkey10.pem
-rw-r--r-- 1 root root 682 Mar 19 17:28 README

/etc/letsencrypt/renewal:
total 8
-rw-r--r-- 1 root root 524 Mar 31 12:02 mail.ryuuzaki.jp.conf
-rw-r--r-- 1 root root 499 Mar 29 00:05 ryuuzaki.jp.conf

Hahaha runaway cron job. Yes, that’s what it looks like, is so strange.
I am the only person with access to this server. Perhaps something I did created another user and setup that cron job under that user?
But I always log in with the same user name, or do sudo. I have never logged in or changed my login info.

% sudo -i
# crontab -e

or

% sudo crontab -u root -e

(I see you use zsh, I adapted the prompt)

1 Like

Thank you so much for your help.

Yes I use OhMyZsh with "rkj-repos" theme. Is cute.

So the first command

sudo -I
crontab -e

gives me an empty tmp file.

same with

sudo crontab -u root -e
Just a tmp blank text file:
/tmp/crontab.abEGtz/crontab

where else could guy be hidden?

I used a lowercase i, I don’t know what a uppercase I does.

% sudo ls /var/spool/cron/crontabs
% sudo ls -r /etc/cron*

zprezto with modified steeef here, but not on servers :smiley:

sudo ls /var/spool/cron/crontabs
root ryuuzaki

sudo ls -r /etc/cron*

/etc/crontab

/etc/cron.weekly:
update-notifier-common	man-db

/etc/cron.monthly:

/etc/cron.hourly:

/etc/cron.daily:
webalizer		spamassassin	    ntp      logrotate		apt-compat
update-notifier-common	quota		    mlocate  dpkg		apport
ubuntu-advantage-tools	popularity-contest  mdadm    bsdmainutils	apache2
sysstat			passwd		    man-db   apt-show-versions	00logwatch

/etc/cron.d:
sysstat    popularity-contest  mdadm	    certbot  amavisd-new
postwhite  php		       letsencrypt  awstats

zprezto is nice too, but I don’t like the colored “sales tag” effect. And I slap it everywhere, from my MacBook Pro to all the raspberry pis around the house. Also with Tmux.
Don’t want to sound like I know what I’m doing, cuz I really don’t (nano user here)
Does that output means anything to you? and sorry, yes I did -i but it was autocorrected to capital.

you need to grep those files and see if any have a line calling certbot (grep has a recursive option if you need it grep -r pattern /path/to/directory)

I found omyzsh too heavy (it’s not like zprezto isn’t, but my config at least is) – and my config isn’t that colored :wink:

1 Like

OMG I found it thanks to your comment!
It was here:

/etc/cron.d/letsencrypt

The line reads:

0 */12 * * * root /opt/certbot-auto renew --quiet --no-self-upgrade --force-renewal

But I also have another file:
/etc/cron.d/certbot

with this contents:

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
#
# Important Note!  This cronjob will NOT be executed if you are
# running systemd as your init system.  If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob.  For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

What do you think I should remove? Or… how?

keep this, remove the other. (this is installed by the certbot package, I think. Also check systemctl list-timers --all and see if the certbot one is enabled)


wow, it looks so flashy :smiley:

1 Like

but then, this should not work. maybe you have certbot and certbot-auto, but certbot-auto is only in path for root.

1 Like

Right!? But I’m just covering the fact that I lack so much skills by putting so much decorations.

So when you say remove the other. is there a command to take it off? Or just delete the
/etc/cron.d/letsencrypt
file?

systemctl list-timers --all
Doesn’t show the letsencrypt file, but I do still get an email of that command running.

NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
Wed 2020-04-01 18:39:00 JST  14min left    Wed 2020-04-01 18:09:06 JST  15min ago  phpsessionclean.timer        phpsessionclean.service
Wed 2020-04-01 22:24:38 JST  3h 59min left Tue 2020-03-31 22:24:38 JST  20h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Wed 2020-04-01 23:30:57 JST  5h 6min left  Wed 2020-04-01 02:10:49 JST  16h ago    motd-news.timer              motd-news.service
Thu 2020-04-02 02:24:35 JST  7h left       Wed 2020-04-01 12:01:58 JST  6h ago     apt-daily.timer              apt-daily.service
Thu 2020-04-02 06:32:28 JST  12h left      Wed 2020-04-01 06:54:11 JST  11h ago    apt-daily-upgrade.timer      apt-daily-upgrade.service
Thu 2020-04-02 08:08:04 JST  13h left      Wed 2020-04-01 17:28:45 JST  56min ago  certbot.timer                certbot.service
Mon 2020-04-06 00:00:00 JST  4 days left   Mon 2020-03-30 00:00:02 JST  2 days ago fstrim.timer                 fstrim.service
n/a                          n/a           n/a                          n/a        snapd.snap-repair.timer     
n/a                          n/a           n/a                          n/a        ureadahead-stop.timer        ureadahead-stop.service

9 timers listed.

there’s a certbot one, it’s running.

should be fine.

you should check if you have something in /opt

2 Likes