And of course hit the rate limit:
an unexpected error occurred:
too many certificates (5) already issued for this exact set of domains in the last 168h0m0s, retry after 2025-01-17 00:25:13 UTC: see @https://letsencrypt.org /docs/rate-limits/#new-certificates-per-exact-set-of-hostnames
Now i have to use staging=1 for production [cries]
Do you have a specific question? It's not clear from the post. If you need help getting a Let's Encrypt certificate, please fill out the questionnaire below.
Also, please note that Staging certificates are not trusted by any browser or operating system by default, and as such cannot (and should not) be used in live/production systems.
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. crt.sh | 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:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
My domain is: ai.logdms.com
I ran this command: ./init-letsencrypt.sh without staging=1
It produced this output: Requesting a certificate for ai.logdms.com and www.ai.logdms.com
An unexpected error occurred:
too many certificates (5) already issued for this exact set of domains in the last 168h0m0s, retry after 2025-01-17 00:25:13 UTC: see @https://letsencrypt.org /docs/rate-limits/#new-certificates-per-exact-set-of-hostnames
My web server is (include version): nginx:1.23.4-alpine
The operating system my web server runs on is (include version): ubuntu 22.04
My hosting provider, if applicable, is: digital ocean
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 3.1.0
That is not the usual command used for Certbot. Can you explain more about what that does?
Normally Certbot saves the most current and prior 5 certs in the ../archive/.. folder. The ../live/.. cert file names are symlinks to the most recent. So, in a normal Certbot setup you should have one of these prior certs available.
It is just a file I run to create the certs 
echo "### Requesting Let's Encrypt certificate for $domains ..."
#Join $domains to -d args
domain_args=""
for domain in "${domains[@]}"; do
domain_args="$domain_args -d $domain"
done
case "$email" in
"") email_arg="--register-unsafely-without-email" ;;
*) email_arg="--email $email" ;;
esac
if [ $staging != "0" ]; then staging_arg="--staging"; fi
$COMPOSE_CMD -f docker-compose.prod.yml run --name logai-stack --rm --entrypoint "
certbot certonly --webroot -w /var/www/certbot
$staging_arg
$email_arg
$domain_args
--rsa-key-size $rsa_key_size
--agree-tos
--force-renewal" certbot
echo
this is currently in my live folder : cert.pem chain.pem fullchain.pem privkey.pem
and my archive folder: ai.logdms.com ai.logdms.com-0002 ai.logdms.com-0004 ai.logdms.com-0006
ai.logdms.com-0001 ai.logdms.com-0003 ai.logdms.com-0005 ai.logdms.com-0007
i am not sure how to use an already emitted certificate i have in my archive folder
The --force-renewal is likely a large part of your problem. This is rarely needed and even if needed is used just once.
That looks like something else went wrong too. You should not be getting Certbot renewal folders with names of -0001, -0002, ... and so on. That can happen when something significant is changing with your cert (like the list of domain names). But, makes it difficult to use as the location of the current cert keeps changing.
Not sure where they would be in your Docker setup but can you show your equivalent of the "normal" default of:
sudo ls -l /etc/letsencrypt/live
I see! I will remove the force-renewal from the script..
deployment/data/certbot/conf/live for me and it shows:
-rw-r--r-- 1 root root 740 Jan 15 16:50 README
drwxr-xr-x 2 root root 4096 Jan 15 20:05 ai.logdms.com
Okay, so what do the ls -l for these show
deployment/data/certbot/conf/live/ai.logdms.com
deployment/data/certbot/conf/archive
deployment/data/certbot/conf/archive/ai.logdms.com
deployment/data/certbot/conf/live/ai.logdms.com# ls -l
total 4
-rw-r--r-- 1 root root 692 Jan 15 19:23 README
lrwxrwxrwx 1 root root 42 Jan 15 19:23 cert.pem -> ../../archive/ai.logdms.com-0007/cert1.pem
lrwxrwxrwx 1 root root 43 Jan 15 19:23 chain.pem -> ../../archive/ai.logdms.com-0007/chain1.pem
lrwxrwxrwx 1 root root 47 Jan 15 19:23 fullchain.pem -> ../../archive/ai.logdms.com-0007/fullchain1.pem
lrwxrwxrwx 1 root root 45 Jan 15 19:23 privkey.pem -> ../../archive/ai.logdms.com-0007/privkey1.pem
deployment/data/certbot/conf/archive# ls -l
total 32
drwxr-xr-x 2 root root 4096 Jan 15 16:50 ai.logdms.com
drwxr-xr-x 2 root root 4096 Jan 15 16:51 ai.logdms.com-0001
drwxr-xr-x 2 root root 4096 Jan 15 16:52 ai.logdms.com-0002
drwxr-xr-x 2 root root 4096 Jan 15 16:55 ai.logdms.com-0003
drwxr-xr-x 2 root root 4096 Jan 15 18:22 ai.logdms.com-0004
drwxr-xr-x 2 root root 4096 Jan 15 19:08 ai.logdms.com-0005
drwxr-xr-x 2 root root 4096 Jan 15 19:13 ai.logdms.com-0006
drwxr-xr-x 2 root root 4096 Jan 15 19:23 ai.logdms.com-0007
deployment/data/certbot/conf/archive/ai.logdms.com# ls -l
-rw-r--r-- 1 root root 1294 Jan 15 16:50 cert1.pem
-rw-r--r-- 1 root root 1566 Jan 15 16:50 chain1.pem
-rw-r--r-- 1 root root 1805 Jan 15 16:51 fullchain1.pem
-rw------- 1 root root 3272 Jan 15 16:51 privkey1.pem
root@dockeronubuntu2204-s-4vcpu-16gb-amd-fra1-01:/opt/logai/deploy
here you go
I believe from 005 might be dummy ones as it is after the date I switched to staging mode
Right, I switched the symlinks to the original certificate (no number from archive) and will be running the command from the file manually avoiding the certbot ones to create any more certificates, to see if that works.
Usually the list of folders under ./archive/. is the same as for ./live/
You should review how you manipulate what Certbot is doing. In fact, it usually works best to not try to coerce Certbot. A --deploy-hook is useful to make a copy of the latest certs if you need that (but rarely do). And, be sure to keep all these folders in persistent storage.
Just based on the timestamp it looks like the ./live/ai.logdms.com should be the first cert you got which should still be valid.
What directory path is used in the service which references these file names?
It already was. Or do you mean you did that prior to posting the files noted above
ALSO: Perhaps your deploy system could make use of --cert-name option. Usually best to avoid complexity but if you must perhaps this helps.
I am sure this one is still valid as it is now pointing to the correct one in archive:
-rw-r--r-- 1 root root 692 Jan 15 19:23 README
lrwxrwxrwx 1 root root 37 Jan 15 20:45 cert.pem -> ../../archive/ai.logdms.com/cert1.pem
lrwxrwxrwx 1 root root 38 Jan 15 20:45 chain.pem -> ../../archive/ai.logdms.com/chain1.pem
lrwxrwxrwx 1 root root 42 Jan 15 20:45 fullchain.pem -> ../../archive/ai.logdms.com/fullchain1.pem
lrwxrwxrwx 1 root root 40 Jan 15 20:45 privkey.pem -> ../../archive/ai.logdms.com/privkey1.pem
It used to point to archive/ai.logdms.com-007 one. But I think this is not enough to use this certificate instead of the latest 007 one
It should be if your service uses the name in ../live/ai.logdms.com/..
Why do you think it isn't working?
An HTTPS request to your domain using port 443 gets a self-signed cert. Is this what you expect to be using the Let's Encrypt cert? If so, your web service is not configured properly. The form you were shown in post #2 is helpful info
thank you for your help, for sure it is something on my side. Thank you for the insightufl info I will try to follow it and perhaps a resolution will arise.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.