Hoverfly bundled CA cert expired 2026-04-28

[dimi-cb]

The Hoverfly Go binary bundled inside io.specto:hoverfly-java-junit5:0.20.2 (latest release, May 2025) generates a per-host server cert with notAfter=2026-04-28 13:36:51 UTC. Any test that runs after that date fails with:

javax.net.ssl.SSLHandshakeException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: validity check failed
Caused by: java.security.cert.CertificateExpiredException:
NotAfter: Tue Apr 28 13:36:51 UTC 2026

Affected: every project pinned to hoverfly-java-junit5:0.20.2 (and earlier) running tests after 2026-04-28.

Reproduce:

@ExtendWith(HoverflyExtension.class)
class CertExpiryTest {
    @Test void anyTestThatProxiesHttps(Hoverfly h) { /* fails on handshake */ }
}

Workaround we landed: override the bundled binary at build time with the fresh Hoverfly Go v1.12.6 (released 2026-04-07, certs valid through 2049). A Gradle task downloads the v1.12.6 release and drops it into build/resources/test/binaries/hoverfly__ so the test classpath finds it before the JAR's copy. Hoverfly Java's TempFileManager.copyHoverflyBinary uses Thread.currentThread().getContextClassLoader().getResourceAsStream(...) which respects the override.

Asks:

1. Cut a hoverfly-java-junit5:0.20.3 re-bundling Hoverfly Go ≥ v1.12.6.
2. Consider documenting the binary-override pattern in the README — useful even pre-fix because the 2-year cert validity window means this issue recurs.
3. Long-term: have the bundled binary regenerate the CA on first launch instead of carrying a fixed-validity one (or at least bump validity to e.g. 100 years).

Diagnostic detail:

• Bundled CA in cert.pem: notAfter=Mar 24 21:49:08 2032 GMT (still valid)
• Per-host MITM certs minted by the bundled Hoverfly v1.x binary: notAfter exactly 2026-04-28
• Fresh Hoverfly Go v1.12.6 mints certs with notAfter=Dec 31 00:00:00 2049 GMT (verified locally)

So the issue is in the embedded Go binary's cert generation, not the bundled CA.