Rate limiting by certbot issues

Help
1

My domain is: americanconsumercouncil.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for americanconsumercouncil.org
An unexpected error occurred:
too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after 2026-05-24 10:52:56 UTC: see Rate Limits - Let's Encrypt
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

i am importing a large wordpress multisite with each subsite being a separate and distinct domain. I am hitting this wall now with only 5 of the subsites properly ssl connected. how can i get the rest of these sites added before tuesday? there's going to be 46 more requests as i add these aliases. i am using virtualmin 8.1 as my control panel on debian 13

2

I see 5 certificates issued in the past week that have only your domain name americanconsumercouncil.org in it.

You say your subsites each have their own domain name but that would not require you to get fresh certs for that registered domain.

Have you setup VirtualMin yourself or do you have a hosting service?

When you say subsites are these actually different registered domains or just subdomains? If the latter perhaps you would be better off using a DNS Challenge and a wild card cert.

3

That error is telling you that you've obtained five identical certificates within the past week--each of them has the exact same set of names on them. Why have you done this? If each subsite needs its own cert, make one for the appropriate name(s) only.

4

they are distinct domains under the main site. so acc is the root, then alaskaconsumercouncil.org is another domain under that same site located in a sub folder. I am the webhost using virtualmin. i have to setup an aias server under the main server account for the domains to get their individual certs as le needs a place tow rite it's challenge file. so when i added the alias the cert gets re-requested to include the new alias domain. so if it's 5 per time..it's going to take..a week to import this site?

5

because this is how virtualmin does it...

6

I don't see any cert issued for that domain name. And, HTTPS requests to alaska fail because of an invalid cert. HTTPS requests to alaska fail because it uses the acc cert instead. The domain name in an HTTPS URL must match a domain name in the certificate your server sends back.

You should probably visit the VirtualMin community or its support for the best ways to handle your situation.

curl -i https://alaskaconsumercouncil.org 

curl: (60) SSL: no alternative certificate subject name matches target hostname 'alaskaconsumercouncil.org'
More details here: https://curl.se/docs/sslcerts.html
7

I don't know virtualmin that well, but I'm pretty sure it isn't that broken by design. Again, the problem is that you've issued five identical certs within the past week, all for americanconsumercouncil.org. A cert for americanconsumercouncil.org and alaskaconsumercouncil.org, if you'd issued one, wouldn't count toward this rate limit.

A practice that has you issue a cert for a.com; then one for a.com and b.com; then one for a.com, b.com, and c.com; etc. would still be a broken practice, and would likely hit the rate limits if you have 50 sites you're running, but that isn't what's going on here. What you've done is issued five certs for the exact same set of domain names, and there's just no legitimate reason to have done that.

That domain is serving a cert issued only for americanconsumercouncil.org.:

╰─ openssl s_client --connect alaskaconsumercouncil.org:443                                                                      ─╯
Connecting to 104.168.120.130
CONNECTED(00000005)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R13
verify return:1
depth=0 CN=americanconsumercouncil.org
verify return:1
---
Certificate chain
 0 s:CN=americanconsumercouncil.org
   i:C=US, O=Let's Encrypt, CN=R13
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 23 13:06:55 2026 GMT; NotAfter: Aug 21 13:06:54 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=R13
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFEjCCA/qgAwIBAgISBWN+Kb95htQ/zv2CVF5k9HPAMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTMwHhcNMjYwNTIzMTMwNjU1WhcNMjYwODIxMTMwNjU0WjAmMSQwIgYDVQQD
ExthbWVyaWNhbmNvbnN1bWVyY291bmNpbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDLrCxHBq5Gu2j3VsL34iWHBGt0YSDD74tLddz3hQSjBrCj
dZgcLfcOg4jEn5SMH9nzUxBUlisdwHBhyMJQD6+JphocmwNX7yJrkdUwk27ieQtS
IKlgM9zmzbpFqa93xjnIQc7j4b+Q1Wv9XRG4ce7EW1zyZUu6K9BS/+JwW7T7VZUE
3y28qtg9x8Z+Vbhwwf0xyqzpPQimxCE6hBhrJAUV/eIOXUh2RbgkABiztiL3Yx3z
rFRt3rbuFm1y4xOvXwMHNrfYUIXJ39NZUzm3aKRYX/ykNeqMh+NGDEvUDqW4wzo2
JjF0TmhBfRhCSp+gmJQT5dkpz/4sEV7HP7cCG9HBAgMBAAGjggIrMIICJzAOBgNV
HQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAd
BgNVHQ4EFgQUSuzNML+TLdUKEMQPT8ykt2d7oxkwHwYDVR0jBBgwFoAU56ufDywz
oFPTXk94yLKEDjvWkjMwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAChhdodHRw
Oi8vcjEzLmkubGVuY3Iub3JnLzAmBgNVHREEHzAdghthbWVyaWNhbmNvbnN1bWVy
Y291bmNpbC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwLgYDVR0fBCcwJTAjoCGg
H4YdaHR0cDovL3IxMy5jLmxlbmNyLm9yZy82NS5jcmwwggEOBgorBgEEAdZ5AgQC
BIH/BIH8APoAdwDXbX0Q0af1d8LH6V/XAL/5gskzWmXh0LMBcxfAyMVpdwAAAZ5V
J7J7AAAEAwBIMEYCIQCJ+YOc4joSRNKvalIN76ORGqMPZIxP/diCwYm5WXq6YQIh
APbm2L4NdBg9sNAGV0NHGWcbtYyZrabcQKMSXWI1aI0SAH8AbP5QGUOoXqkWvFLR
M+TcyR7xQRx9JYQg0XOAnhgY6zoAAAGeVSe1OQAIAAAFAAzvPTcEAwBIMEYCIQC/
79ptEfQ3Nxg3oRyummqpjSPgZKLI2kmi23Nz6aM2ugIhANfBob8JPBNwPiBVTjKT
YkZPPKEeoI1VCZpn25suPpmFMA0GCSqGSIb3DQEBCwUAA4IBAQA66lJpqJCJdN46
13XKr/H9jI5RUiSGYWr4ghYBORDhOCltZ53dAlm5S4n+qZpfq+OtxANOAZEmTXon
Y0XqnX+LXFLeJeLueFmB/3wxhU8la8elC4OwpEWQyc/O5DqeG+iWNwszMHkKg9vD
viDYkaztTTb98eHu3G19Lgl5CynL5y2V6ATMNa+3Cl+q8DXRAUvy+Xd1Coli+9TP
edRWRLuhbFiDrcjVajITuVBp1o5kKqdd46PAOep2Eqnv4RGvMVrByCfHdHPyZugL
nPoxZcNbXHrGGrSzAOyCQ7IeMDqocgaTVO/HkyADQYJkCE1Rm6N6YNCSw8Y06LbN
xcZPH6+8
-----END CERTIFICATE-----
subject=CN=americanconsumercouncil.org
issuer=C=US, O=Let's Encrypt, CN=R13
---

There are no other names on that cert.

8

That would be broken but that isn't what they are doing either. They are repeatedly issuing a cert for a.com and using it for requests to b.com and so on.

9

Right, that's my point. It'd still be a bad practice, and I think it's what OP thinks he's doing, but it's clear that isn't what's happening.

11

this is a problem between virtualmin trying to add the domain to the parent certificate every single time instead of waiting for me to get done adding all of them so it's one request. The limits via LE are pretty tight. This is what it is. I am referring this back to virtualmin...let's see what they have to say.