REF-16: Send OCSP requests using POST from the library, and make CRLCheckerTest reliable

[thomasnymand]

Sends OCSP requests using POST from the library itself, and fixes the CRLCheckerTest problems that uncovered the issue.

The problem

The JDK OCSP client uses the RFC 5019 GET form (request base64-encoded into the URL path) for requests of 255 characters or less. The NemLog-in OCSP responders answer HTTP 404 to that form, so every OCSP check fails with UNDETERMINED_REVOCATION_STATUS.

This is not test-only. In a deployment it means:

• with the default configuration, the SP silently degrades to the CRL fallback (one warn per certificate),
• with oiosaml.servlet.revocation.crl.check.enabled=false, all IdP certificates are dropped and login breaks.

Version detail: sun.security.provider.certpath.OCSP in JDK 8 and 11 always POSTs; the GET form and the com.sun.security.ocsp.useget switch exist from JDK 12 onwards (confirmed present in 21/25/26, absent in 11/8). USE_GET is a private static final boolean initialized in the class's static initializer from a system property only (System.getProperty, default true), so Security.setProperty has no effect and setting it after the first OCSP check is too late.

Two further problems in CRLCheckerTest:

• testOcspCheckOnValidCertificate failed (expected: <1> but was: <0>) for the reason above.
• The revoked tests passed for the wrong reason: with OCSP unreachable the result set was empty, which happened to satisfy assertEquals(0, …). The revoked certificate's real status was never exercised.

Changes

Force POST in the library, not in the tests. CRLChecker.configureOcspTransport sets com.sun.security.ocsp.useget=false, called from OIOSAML3Service.init so it runs before the first OCSP check in the JVM. It is gated by a new property oiosaml.servlet.revocation.ocsp.post.enabled (default true), plumbed through Constants → Configuration → DispatcherServlet. A value set explicitly by the deployer (-Dcom.sun.security.ocsp.useget=…) is left alone, and each branch logs what happened. POST support is mandatory for responders per RFC 6960, so forcing it is safe; the only cost is that GET responses are no longer HTTP cacheable for other OCSP users in the same JVM.

Drop the JVM global security properties. doOCSPCheck no longer sets ocsp.enable / ocsp.responderURL. Those published the responder of the certificate currently being checked as a JVM wide default, which leaked into every other PKIX validation in the container and raced with concurrent checks. Replaced with a per validation PKIXRevocationChecker (Java 8 API): setOcspResponder(URI) plus Option.NO_FALLBACK, so CRL fallback stays in checkCertificate where the OIOSAML configuration drives it.

Use a genuinely revoked certificate for TestConstants.REVOKED_CERTIFICATE. Verified against the live test CA: OCSP reports revoked and the serial is present in the issuing CRL. Validity 2026-07-06 .. 2029-07-05 (no near-term expiry).

Tag the revoked tests @Tag("integration") (both OCSP and CRL variants) since they depend on the live test CA revocation infrastructure. No group filtering is configured, so they still run by default; the tag allows excluding them offline via -DexcludedGroups=integration.

Remove the workaround from BaseServiceTest, so CRLCheckerTest now exercises the production path instead of a test-only property.

Verification

mvn -pl oiosaml test: the four CRLCheckerTest cases pass (present, not skipped). Re-running with -DargLine=-Dcom.sun.security.ocsp.useget=true makes testOcspCheckOnValidCertificate fail again, which confirms both that the responder really 404s on GET and that the deployer override is honoured. The only remaining failure is the unrelated OIOBPPUtilTest (JDK 26 JAXB incompatibility), which also fails on master.

Notes

• com.sun.security.ocsp.useget is an OpenJDK/Oracle-internal property, reliable on HotSpot-derived JVMs and JVM-global in scope. It is applied whenever oiosaml.servlet.revocation.ocsp.post.enabled is true, also when OIOSAML's own OCSP checking is disabled, because applying it lazily would risk being too late to take effect.
• Follow-up worth its own issue: build the OCSP request in the library (BouncyCastle is already on the classpath), POST it with our own timeouts, and hand the DER response to PKIXRevocationChecker.setOcspResponses(…) so the JDK still does all signature and validity verification. That would remove the dependency on a JDK-internal property entirely and give us control over OCSP timeouts.
• The revocation tests remain live-network dependent by nature; the integration tag makes that explicit. A fully hermetic (MockServer-based) rewrite remains a possible follow-up.

[mthiim]

Approved