New Cert issue error (in Plesk)

Help
1

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. https://crt.sh/?q=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: quizsystems.co.uk

I ran this command: I autorenewed in Plesk (this is one of four domains I did on the same box - the other three worked fine as they all have many times before), but when I got a new _acme-challenge string (which I duly cut/paste to the correct field on the DNS server (it's a different box with a different ISP) for quizsystems.co.uk, when I then clicked (in Plesk )to do the update locally, for the first time ever it failed. So now I have a 'new' _acme-challenge key on the DNS server (which like e.g. jwp.co.uk, runs out Jan 26) 'locally' on the VPS (and on the domain itself) everything is still showing as expiring early November. :frowning:

I can't find the old acme string (in case it needs to match the old 'active' cert) and I'm seemingly out of retries to re-issue a new cert (I tried two/three times and it failed repeatedly) - it's now saying I need to wait. I don't know if all this is an issue or not. The new acme string is...

hKdeCPDe5okpedktRUNKEgwLvC8EKJMC7NNv2EMUbmg

It produced this output: It didn't change anything (the cert still runs out 2nd Nov).

My web server is (include version): Plesk Obsidian v18.0.72_build1800250915.05

The operating system my web server runs on is (include version): Ubuntu 20.04.6 LTS

My hosting provider, if applicable, is: Ionos

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): it's part of Plesk

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

2

How long did you wait after pasting the new TXT value and continuing at Plesk? Because Let's Encrypt validates from many points around the world and your DNS servers must synchronize to ensure each LE center sees the updated TXT value.

Maybe your servers are just taking longer than usual to perform this sync?

Related to that ... do the domain names that work use this same DNS system? (lcn.com it looks like)

No worries. You do not need the TXT value for anything after it is used to get a certificate.

What is the exact error message? Because a few failed attempts would not trigger a Let's Encrypt rate limit. Perhaps that Plesk setup has a limit but you'd have to ask your provider about that. An LE rate limit is easy to identify from the error message and includes a date/time after which you can try again.

5 Likes
3

Hi Mike, thanks so much for the reply and the info. Really appreciated.

In all the years I've been doing this somewhat convoluted solution to certs (!), it's never failed like this, but as you say, if there were to be a delay in the acme txt on the remote DNS server (which is with lcn.com) being updated, that would certainly do it. What was weird here though, was the other three domains on the same server, that I did at the same time had no issue, yet this one, failed every time I tried (until I was told about exceeding the limit).

This is what I got in that regard...

Invalid response from https://acme-v02.api.letsencrypt.org/acme/new-order
Details:
Type: urn:ietf:params:acme:error:rateLimited
Status: 429
Detail: too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after 2025-10-09 03:22:01 UTC: see Rate Limits - Let's Encrypt

What's very reassuring about your comment, is that the acme string is only checked during the cert update process, which I have to say was my main concern here (given I no longer have the one that equates to the current cert, only the failed new one).

I guess I'll wait till I can do it again and see what occurs. It certainly made me think I should always do this process well in advance of when the cert expires!

I'll report back later in the week.

4

That is a Let's Encrypt rate limit and is just what it says. You were issued 5 certificates on Oct7 and now must wait until Oct9 at 3:22 UTC to try again. You can see the details at the link in the error message but you will be allowed one more each 34 hours until the excess washes out beyond a week.

What this means is that Plesk did not properly apply any of those to your system.

That is definitely something for your Plesk support to work out. Below is your cert history from the public logs. I guess the good news is that you don't have any trouble getting the certs :slight_smile:

Screenshot 2025-10-08 095246
Screenshot 2025-10-08 0952461504×608 260 KB

5 Likes
5

Yes, manual interaction to get a wildcard cert is not the easiest way. Setting up automation is the most common and the recommended way. I don't know how to do that with Plesk.

In general, automating the DNS Challenge required for a wildcard cert requires your DNS provider to have an API to allow adding/deleting the TXT record. And, for your ACME Client (Plesk) to support that DNS provider.

If you can use just explicit domain names in your cert (so not a wildcard) you could probably use an HTTP Challenge that relies on a webserver (your nginx) to reply to the challenge. These are usually easier to automate.

5 Likes
6

So... this has now self resolved! I did nothing, so presumably, once the timeout had expired, the certificate was renewed with the new acme details that then resided on the DNS server. Interestingly the date used for that has then 'slipped' by the amount of the delay, so that the domain in questions cert now runs out on the 7th, where as the other three end on the 5th.

1 Like
7

Sort of. Let's Encrypt will cache a successful challenge (per account/name) for up to 30 days (depending on the cert profile chosen).

You got 5 certs on Oct7 for quiz so no new challenge was needed when you requested and were issued another cert Oct9

Your nginx is now using the Oct9 cert so, as you say, all is well. And, that is why its expiration is 2 days later than your other 3. Because Plesk properly applied the Oct7 certs for them but not for quiz.

2 Likes
8

'You' in that sentence is doing some heavy lifting :winking_face_with_tongue: I've not even been back to either server since I had the issues that brought me here. I'm guessing that some automation within Plesk must have re-applied for the cert and given that the acme text on the DNS server had already been changed on the 7th, it went through when the request (post the lock-out) happened.

Interesting though. I'd have thought that the unique acme text was raised on the day of the request, but clearly here it wasn't (becuase the only way that happens is if I masnually cut/paste it from one server to the other.

9

Sure. Meant to be something on your end rather than on Let's Encrypt side :slight_smile:

We don't have to guess. Plesk re-requested a cert because one was actually issued on Oct9. Let's Encrypt cannot issue a cert without a request from an ACME Client (Plesk in your case).

As I described, the reason that could succeed without new DNS TXT record is because of the cache of the successful result from the Oct7 certs. Note the first cert issued on Oct7 is the only one that needed a fresh DNS TXT record value. Perhaps Plesk asked for one anyway after that first one since it didn't handle those certs as it expected. But, from an LE perspective the last 4 certs on Oct7 and the cert on Oct9 had a validly cached challenge and so no new value was needed. And, LE would not have looked for one since it was in its own authorization cache. See the Authorization Reuse period (link here). You (Plesk) are likely using the Classic profile.

It seems Plesk, for some reason, did not handle the 5 Oct7 certs properly. So, once the 34H lockout expired it was able to get another one. It was probably on some auto-retry and its requests prior to the 34H lockout were rejected by LE

Plesk requested the 2nd through 5th certs on Oct7 about 2 minutes after each other. After the 5th cert was issued LE blocked requests due to rate limits. Hopefully Plesk didn't continue (and fail) making requests every 2 minutes for the next 34 hours :slight_smile:

2 Likes
10

Ah OK, so because the auto re-request clearly done by Plesk (once the lockout had expired) was still well within the Authorization Reuse period, the cached acme string was acceptable and the cert was duly updated.

That 'oddity' remains the mystery of all this (of course), but it's all good now and I personally feel that even if it goes pear shaped on another occasion, at least I'm way better informed (and will be signifcantly less worried) than I was this time around.

Many thanks for the advice and info! MUCH appreciated :grinning_face:

2 Likes
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.