fix(deps): update dependency org.shredzone.acme4j:acme4j-client to v3.4.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.shredzone.acme4j:acme4j-client (source)	3.2.1 -> 3.4.0

---

Release Notes

shred/acme4j (org.shredzone.acme4j:acme4j-client)

v3.4.0

Important Changes

Until now, order finalization (order.execute()) was started immediately after the domain authorization process was completed. This is working fine for most CAs, but might fail for some CAs that take a while for the order to become READY for finalization. For this reason, I recommend to generally wait for the order status to become READY before invoking order.execute(). If you wait for state changes synchronously, you can use the new order.waitUntilReady() method for that. The example has been updated accordingly.

Waiting for status changes was expected to be implemented by you. There was a waitForCompletion() method in the example client that showed how to wait synchronously. With acme4j v3.4.0, there are now new methods waitForCompletion() and waitUntilReady() that do the heavy lifting for you. You can replace your own waiting code with these new methods if you like to. The new methods wait synchronously, blocking the current thread for several seconds or even minutes. If you have implemented an asynchronous wait, you should prefer to use your own code.

For further information, please see the migration guide and the example client.

Changelog

• Added waitForCompletion() and waitUntilReady() methods, which will synchronously wait for a status change. They replace the waitForCompletion() boilerplate method in the example implementation, and will make simple acme4j implementations simpler and less bugprone.
• Deprecate update() and AcmeRetryAfterException. Use fetch() instead.
• Update to draft-ietf-acme-ari-04. No changes to the code are required.

v3.3.1

• Added chapter about errors and Problem objects.
• OrderBuilder.replaces() set autoRenewal to true, which makes no sense in this context. Fixes #​158, thanks to @​rcc13 for reporting.

v3.3.0

• Added support for subdomain validation (RFC 9444)
• AcmeProtocolException was thrown when a rate limit was reached while fetching a nonce. Now either AcmeRetryAfterException or a generic AcmeException is thrown, depending on the error returned by the server.
• Project could not be built with Java 22, fixed (#​157, thanks to @​tugalsan for reporting)
• Integration tests against the latest docker image versions of pebble and challtestsrv

I also decided to discontinue acme4j v2, because the codebase diverged a lot now, and I don't want to spend my limited resources on maintenance. Please migrate your code to acme4j v3. For most clients, it is less work than it might look like.

---

Configuration

📅 Schedule: Branch creation - "after 10pm" in timezone Europe/Prague, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud