SAN certificate with dns-cloudflare

Even in this case, you still don't need --force-renew; you could use --expand instead.

The difference in logic between then is that --expand automatically answers "yes" to the question about whether you'd like to replace the old certificate with an expanded one (covering a strictly larger set of names), while --force-renew also answers "yes" to the question about whether you'd like to re-issue the certificate even though there's no apparent reason to do so (when the certificate is not near expiry and no new names have been requested to be added to it).


Why this is a problem to re-issue cert? Even there were no changes in names, but I want to renew it not in 3 month, but in one. Where problem?

You can certainly do that if you prefer. We've seen that, for most people, relying on a manual schedule like that makes it more likely, rather than less likely, that they'll eventually miss a certificate renewal (because they're on vacation, or sick, or dealing with some other urgent matter at that the time that they hoped to deal with the certificate renewal).

And people who habitually use --force-renewal without looking closely at the Certbot output are also likely to hit rate limits in case of certain minor errors.

But it doesn't violate any Let's Encrypt policies or anything to do it that way.

If you merely want the renewal to happen after 30 days without also doing your renewals manually, you can set renew_before_expiry = 60 days instead of the default renew_before_expiry = 30 days in the .conf file in your /etc/letsencrypt/renewal directory. (That time window for renewal attempts is user-configurable.)


What will you do when you get the 51st server?
I'd start doing whatever you would for that now.


51 will not be tomorrow. When I'll get at least 45 - I will think.

In any way, question is - It work 4 month ago, and not working now.

I think we recently saw a very similar issue with Akamai here: LE is not issuing cert for unknown reason, where CAA rechecking and large certificates are involved.

It is a little worrying if both Cloudflare and Akamai users are encountering this problem. If finalization triggers a flood of DNS queries that is is too heavy (for some subjective measure of "too heavy") and we're seeing it across multiple notable providers, something's up.

It might be possible to prevent the CAA rechecking flood by deactivating existing authorizations every time you issue a certificate. The overall process will take longer, but it means the CAA checks will happen one by one for each authorization, not in rapid fire upon finalization. However, there is no way to force Certbot to do this, only with the --dry-run flag which discards the certificate. The other way to do it is to use a fresh ACME account every time.


If everybody was doing that, Let's Encrypts systems would have their load increased a LOT. IMO that's not something you should do.


The other way to do it is to use a fresh ACME account every time.

How can I do it?

If everybody was doing that, Let's Encrypts systems would have their load increased a LOT. IMO that's not something you should do.

Well, ok, I agree, but in current situation, as I can see there is no difference between manual renewing and automatic. I think error wil appear in both.

It's not a long term solution, but certbot unregister before creating/renewing a certificate would do it. But remember:

You can create a maximum of 10 Accounts per IP Address per 3 hours


Yes, you are right. Not a long-term solution.
If I unregister account will current certificates be active or not?

Will wait for answer from CF, but as I think solution is only divide SAN
certificate for two with less number of names. It makes harder to my project,
but it may be only one solution.

Deactivating your ACME account won't affect the status of any certificates. Also if you have any rate limit exemptions from Let's Encrypt, you shouldn't deactivate your account.


Without getting into any design details...
Have you tried using any other [free] CAs?


No. But I think its not the problem of CA.

Then, can we agree "the problem" is in the process [or design]?


What do you mean by design? Which one?
Design of how LE obtain certs? May be.
But imho its common problem of LE and DNS providers.

I'd say the "design" flaw is in:
DNS + firewall/IPS

Something is "blocking" when it should not be.

That may be ["common"].
But LE is simply following the rules [per RFCs].
So... the issue seems to be with the DNS implementation [and likely their allowed access rates].



Well then, "we're preaching to the choir".
The people that need to hear about this are the ones managing the DNS systems that may be causing this problem.


So its time to think about creating alternative platform ))) Why not!?

? ? ?

Have you tried raising an issue/concern with your DSP?