Questions about Renewing before TLS-ALPN-01 Revocations

Is it possible that you're running Caddy as a different user (so ~ would not point to the correct location)?
You could also try looking in ~/.local/share/caddy. At least that's where v2 stores its certificates.


Great! And you're welcome, I'm glad for sponsors who make it possible.

Make sure to upgrade to the latest version so that you don't have to take any action to replace your certificates.

Yeah, that is what we are doing right now. Btw. any special steps for renewal on Caddy 2.2.0 that uses Redis as storage?

Sorted thank you.

All I needed to do was to run certbot --force-renewal


It is possible that you will run into a rate limit for new-orders. I believe this does apply regardless of duplicate certificates. If that happens, please let us know and we can sort out the appropriate rate limit overrides. Unfortunately, most of the Let’s Encrypt staff is in North America and won’t be online for a few hours to fully resolve if that’s the issue.

You can create a maximum of 300 New Orders per account per 3 hours. A new order is created each time you request a certificate from the Boulder CA, meaning that one new order is produced in each certificate request. Exceeding the New Orders limit is reported with the error message too many new orders recently .


A post was merged into an existing topic: Early Renewal Traefix

Thanks! Where is the best way to contact you if we get into that issue?


This thread will be watched staff and community members who can reach us. I can also be DMd


Ah, yes I think you may be right!

cat /etc/systemd/system/caddy.service
# ; User and group the process will run as.
# User=caddy
# Group=caddy

However there isn't a user directory for caddy. :thinking: However, in that same file I also spotted:

; Letsencrypt-issued certificates will be written to this directory.

And there it was! Removing this directory and once against restarting caddy resulted in every certificate being renewed, also confirmed via the SSL Checker! :heart_eyes:


It would be great if there was some kind of API where you can provide the account id + email and the system spits out which certificates, or at least the CN's these are.

We have already checked the first 50 or 60 servers, but this is going to take days to look through everything :unamused:

Edit: Sorry, maybe because of panic I somehow completely missed the TLS-ALPN-01 bit. So, the wildcard cert below doesn't apply, as it was generated by DNS challenge.

Previous post

This is great. However when exactly will Caddy renew the certs? After January 28 at 00.00 UTC?

There is any way to manually force the revalidation? I'm asking because I have a special situation here: Basically I have a server with Caddy that manages an affected wildcard domain cert, then I have to move this cert to another server (intranet, long story!) with Caddy and load it manually with the tls directive.

So I need time to move the cert around once it is revalidated and before the January 28 deadline.



I could be misunderstanding what you're trying to do, but if you're trying to renew asap then I think you want to set the days parameter to a very high value as it means under how many days the certificate you're trying to renew has left before it tries to renew it. So if you set it to 1 it won't renew if the certificate has more than 1 day left.

I use the same renewal script, and I set the days parameter to 100, then manually ran the script (rather than relying on the cron), and it renewed all my certificates. I then removed the parameter again.


I am caught in a Catch-22: I use Let's Encrypt's lego client on Ubuntu, which does not allow me to renew my certificates because they are too new. But lego has no --force-renew or --force option. What is the best way forward to renew the certificates in the two days I have left before they are revoked?

Thanks for reading.

Update: To avoid being caught with my certificates down, I took the brute force approach:

  • install Go 1.16
  • clone the git repository for the lego client
  • edit func needRenewal in cmd/cmd_renew.go to return true before checking the time window
  • build the lego client
  • use the "customised" lego client to renew the certificates

Not for the faint of heart, but it works when you're in a bind.


A post was merged into an existing topic: Early renewal for bncert (bitnami)

Hi, yes of course this worked! Very tired, been up all night trying to sort it.

But now I'm not sure if this is right - doesn't that mean by setting it to 100 days that my certs won't get renewed in 90 and therefore my website will be unsecured for 10 days once my certs pass this 90 day expiry date?

In other words, now it's at 100 days, even though I've set it to 60 days in the script, how do I force the certs to expire in 60 days now, they are gonna stick around for 100 no?

My error message (of course) trying to renew the certs back to 60 days:

The certificate expires in 89 days, the number of days defined to perform the renewal is 60: no renewal.

So I'm thinking I should've thought for a second and just done 61, inside the 90, over the 60 for the current cert... I'm using lego too with apparently no force renew...

Or will they renew in 89 days like the error suggests, because you can't really force a cert to expire in 100, they're locked at 90, hence why you suggested 100 days for those people who have renew 90 in their code?

I'm being rate limited: urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many new orders recently

Who can i contact to have these limits raised while traefik requests new certs?

@Hvid - jillianLet's Encrypt staff


"This thread will be watched staff and community members who can reach us. I can also be DMd"

Dear @jillian , I can't find the way to DM you but I'll definitely need LE staff help to raise my reissue limit.
Please advise, whom to message and with what information, thanks!

It seems new users cannot DM.

Strictly speaking what we call a "renewal" is just a brand new certificate which happens to contain the same set of hostnames :wink:

Could you perhaps clarify which limit you're actually having issues with? Preferably the actual error message provided by the ACME server.