I don't have answers to most of your questions, but I may have some things that might help in some way:
There's an unofficial system run by someone else on this forum that tracks when Let's Encrypt deploys updated code, https://germancoding.com/boulder-version-history/, which says that there was a release around 2026-10-08 19:52 UTC (though I think it checks only once an hour or so, so don't put a ton of stock in the exact time). So there might have been something that changed on Let's Encrypt side at that time.
I find it highly unlikely that it's a problem with your specific account, but more likely something done by your ACME client that doesn't quite match some standard that the Let's Encrypt server is expecting (though it may be hard to know to which one is doing something "wrong").
Can you give more information on the ACME client being used? Is it something built into whatever that "LoadMaster" is?
If you need an urgent workaround while working through the interoperability issue with Let's Encrypt's servers, you might want to try some other CA. There are several that are also free and support the same ACME protocol, so it should mainly just involve pointing your client to one of those instead of (or in addition to) Let's Encrypt. See https://acmeclients.com/certificate-authorities/ from the creator of Certify the Web and/or https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/ from Posh-ACME. I would say that most real-production systems should be getting certificates from multiple CAs in order to be more resilient to problems with a single one. (See what Wikimedia does where they run different certificates in different data centers to make sure they all work, and then can switch all the data centers to the other certificate quickly if needed.)
No, yours is the first report. If this were a problem at the Let's Encrypt server we likely would have seen many more reports before this. It is not impossible for it to be an LE Server change just not as likely. It is definitely not something that is affecting a large number of people. LE issues over 8 million certs / day and a broad problem on their side is readily apparent to LE's own monitoring systems.
No because this is an unusual error. And I agree with Peter that this is more likely something in your ACME Client (your LoadMaster). There are a few reports in this forum that are much older and these were all related to an ACME Client or other faulty setup on the client side. If that's your situation redoing the ACME account or reconfiguring certs may not help.
Have you submitted a support ticket to LoadMaster? If nothing else they may have debug tools specific for that system.
Once this is resolved you should review your renewal timeline. The recommendation is to renew with 1/3 of a cert's life remaining. That would leave you with several weeks of time to sort it out based on default lifetime of certs today.
If you are using shortlived profile certs (about 6day durations) you should have a backup CA available in case of problems that cannot be corrected in short order.
Yes, the ACME client is built into Progress KEMP LoadMaster (firmware 7.2.63.3).
The timing is particularly interesting: all requests started failing on October 9, shortly after the Let's Encrypt deployment you mentioned on October 8.
We also noticed that our stored ACME account key file changed in September, but we haven't confirmed whether the actual cryptographic key changed.
Could the recent Boulder deployment have introduced stricter JWS validation that affects KEMP's ACME implementation?
We are also contacting KEMP Support to investigate this possibility.
It's not impossible, though I didn't see it in recent commits and issues in their repo in a quick check. But I might not have been looking for the right thing. Could be something else, though.
That's probably your best bet. The error message is indicating that the client is sending something wrong. And it seems like other clients are continuing to work.
Definitely, although a key or account URL change must have happened on either side.
You can, in theory perform a POST-as-GET HTTP request to the account URL ( https://acme-v02.api.letsencrypt.org/acme/acct/<your account-id>) to retrieve its status. However, that does require sending a signed JWS payload to the ACME server, so if you're struggling with the signature this will likely fail with the same error.
The error message comes as a result of a specific "verify" function in Boulder. This verify comes from the go-jose package which is a very popular package. It is highly unlikely this is the root cause of the problem.
Especially since you note a recent change to the account key file on your system. Are you sure your failures only started Oct9? You mention some certs are nearly expired but that would only be happening if you have been failing for nearly 30 days already (in a typical ACME Client setup). Or, of course, if you renew much later than is recommended
This seems like a potential culprit if the key actually changed without an associated key rollover from the client. A JWS verification error is what you can get if you're trying to sign ACME requests with the wrong key.
ACME clients don't generally rotate their own account key without an explicit request from users. But it would be a question for Progress Kemp to track down why the file changed.
