Synology: maximum certificate requests reached

DSM refuses a certificate request with a message about the maximum number of requests or attempts. It is tempting to wait an assumed number of days or repeatedly request different names. In the documented Synology incident, however, a specific Let’s Encrypt rate limit was not established. A translated interface message alone cannot identify the upstream failure. Q1

Separate two different situations

A genuine ACME rate limit and an unsuccessful domain challenge require different actions. For a confirmed limit, use its type and returned guidance; revoking a certificate does not reset those limits. Q2 For an unreachable validation endpoint, the technical failure remains even if you click the button again later.

Collect a useful baseline

1. Preserve the current state. Record the DSM version, requested names, timestamp and complete message. Keep the existing certificate and service assignments. Do not delete a usable certificate in an attempt to reset an assumed counter.
2. Find the underlying response. Inspect the diagnostics or logs available for your DSM version. Look for the certificate authority's actual error and any retry time. If those details are unavailable, explicitly mark the rate-limit explanation as unconfirmed.
3. Identify the domain and challenge path. Distinguish your own domain, third-party DDNS and Synology DDNS. Use the applicable manufacturer instructions to identify the expected validation method. Check its DNS and external reachability; opening DSM successfully from inside the LAN does not verify the whole path.
4. Compare the request with deployment. Check which names the existing certificate covers and which service uses it. DSM provides certificate management and service assignment separately. Q3 A successfully renewed file only helps the affected service when that service actually presents it.
5. Make the next attempt purposeful. For a confirmed limit, respect the returned retry guidance. For a challenge failure, repair the identified path first. Do not change domain lists merely to evade a guessed counter.

Define a successful outcome

Verify three observations: the request is accepted, the resulting names and validity dates are correct, and the affected service presents that certificate. Record each observation with a timestamp. The disappearance of an interface error alone is not sufficient confirmation.

For handoff, prepare the DSM version, domain type, DNS results, sanitised error details and service mapping. Passwords and private keys are not needed in an initial enquiry. If only the general interface message is available, make that remaining uncertainty visible rather than filling it with a guessed waiting period.

Frequently asked questions

Must I always wait several days?

Not on the basis of this message alone. The actual limit response is needed to establish meaningful retry guidance.

Will deleting the old certificate help?

It does not establish the cause and can interrupt working access. Preserve the usable configuration during diagnosis.

Describe your case