Track acme4j 5.1.0 major upgrade

[lagergren]

Context

Dependabot will ignore org.shredzone.acme4j:acme4j-client for now because the available update is major: 3.5.1 -> 5.1.0. We should track it explicitly instead of letting it disappear behind the major-update ignore.

Upstream differences from 3.5.1 to 5.1.0

4.0.0 breaking/material changes:

• acme4j now requires Java 17 or newer. The upstream parent POM changed maven-compiler-plugin release from 11 to 17.
• Deprecated APIs were removed.
• Dns01Challenge.toRRName() was replaced by instance method Dns01Challenge.getRRName().
• Default network timeout increased from 10 seconds to 30 seconds.
• Session can be shared across threads and now owns a reusable HttpClient.
• Buypass provider support was removed; Actalis provider support was added.
• New/updated ACME extensions include RFC 9773 ARI, ACME profiles updates, and experimental DNS account label support.

5.0.0 breaking/material changes:

• Private key access through Login.getKeyPair() was removed. Login.getPublicKey() remains for the public key.
• Login.getAccountLocation() was removed; use Login.getAccount().getLocation().
• dns-persist-01 challenge support was added.

5.1.0 changes:

• Fixes Google CA link-list traversal.
• Updates ACME profile and dns-persist drafts.

Dependency metadata:

• acme4j-client still has the same direct runtime dependency shape: jose4j, bcprov-jdk18on, bcpkix-jdk18on, and slf4j-api.
• Parent properties changed notably from Bouncy Castle 1.80 -> 1.83 and SLF4J 2.0.16 -> 2.0.17; jose4j stayed at 0.9.6.
• On the current dependency-health branch, our direct Bouncy Castle pin is already 1.84, so Gradle resolves Bouncy Castle to 1.84 even with acme4j present.

Local impact analysis

Repo usage is limited to javatools/src/main/java/org/xvm/runtime/template/_native/crypto/xRTCertificateManager.java.

The current code uses:

• Account, AccountBuilder, Authorization, Order, Session, Status
• Http01Challenge
• AcmeException
• CSRBuilder
• KeyPairUtils
• Certificate.revoke(...)

The current code does not use the upstream breaking APIs:

• no Login.getKeyPair()
• no Login.getAccountLocation()
• no Dns01Challenge.toRRName()
• no Buypass provider URI
• no DNS-01 or DNS-persist challenge path

Verification already performed

Temporary local trial with acme4j = "5.1.0":

• ./gradlew :javatools:compileJava --console=plain passed.
• ./gradlew :javatools:test --console=plain passed.

Local JDK used for that trial was Corretto/OpenJDK 25. This confirms compile and focused unit-test compatibility, but not live CA behavior.

Recommended follow-up

Open a separate upgrade PR for acme4j = "5.1.0" after the dependency-health branch lands or in a follow-up branch. The upgrade looks low-risk for API compatibility, but because it is a major ACME client upgrade it should include:

• the normal javatools compile/test validation,
• dependency insight confirming Bouncy Castle still resolves to 1.84,
• manual or integration validation of the HTTP-01 flow against Lets Encrypt staging if practical.

Risk level: low for source compatibility, moderate for live certificate issuance behavior because ACME/network behavior changed across a major release.