Philip Helger

Existing debug log messages should already be emitted. Search e.g. for `Performing certificate revocation check on certificate`

Yes, that looks pretty okay. As a workaround please call `PeppolCertificateChecker.setCacheOCSPResults(false)` to disable OCSP result caching in general

Thanks for digging deep into this issue. So it really seems to be an issue with the outbound proxy on your side.... https://bugs.openjdk.org/browse/JDK-8132011 may be a good hint to see...

I am currently only using OCSP and not CRL. Maybe some inhouse changes???

I can confirm, that the OSCP lookup has some issues when using with Java 17 - it really seems to be quite indeterministic when it works and when it doesn't...

I enabled the system property `-Djava.security.debug=certpath` and in case of error, this is the debug trace I see: ``` certpath: ---checking signature... certpath: signature verified. certpath: BasicChecker.updateState issuer: CN=PEPPOL ACCESS...

Ha, here we have the source of the error: the expected length of `0x7fffffff` is a bit too much:  The actual data read has 2277 bytes. The expected length...

Comparing it to a successful response, the `Content-Length` header is contained and has the value of `2277`:  So it is indeed an error at the OSCP service of DigiCert,...

The reading code in Java 11.0.16 looks like this:  It deals with the "no Content-Length" situation totally different. I think I file a JDK bug

The change was introduced from 17b3 to 17b4: * Version 17b3: https://github.com/openjdk/jdk/blob/jdk-17%2B3/src/java.base/share/classes/sun/security/provider/certpath/OCSP.java#L262-L274 * Version 17b4: https://github.com/openjdk/jdk/blob/jdk-17%2B4/src/java.base/share/classes/sun/security/provider/certpath/OCSP.java#L271-L277