Problem with OCSP certificate revocation check in Java 17u4 and later #124
Comments
|
@Florianisme this is indeed weird. Can you please turn on debug logging and post what happens before? |
|
I'm running with Debug enabled all the time in our test instance. I have attached a log from the complete SMP lokup. I sadly can't see anything wrong with the initial validation. I looks like it could be an issue witht the revocation cache, did anything significantly change since the last 1.4.x release? |
|
I see, I need to improve debug logging when it comes to certificate checking. Anyhow, this seems to be the debug log of the second request that fails - most likely because the cached result is returned. Can you please provide a similar debug log for the first transmission request? Thanks |
|
Existing debug log messages should already be emitted. Search e.g. for |
|
Will add a log, which contains the initial fail I does print that in the successful log AP_certificate_ok.txt. I actually had to switch to Java 17 because Spring 3.0 requires it. I'm also running behind a proxy if that is of any interest. |
|
Yes, that looks pretty okay. As a workaround please call |
|
That does seem to work for now. Though I could not reproduce the strange behavior I described initally before I made the change. |
|
I have enabled the java.security.debug=certpath and javax.net.debug=all properties and this is what I found in the log: So I'm guessing nothing you can do :) Sorry to have bothered you! |
|
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 what is necessary to enable a Proxy in OCSP - it seems like this can only be achieved via the global system properties. |
|
I am doing that already, though I might have to dig even deeper now. I don't get why it was working perfectly fine before.. |
|
I am currently only using OCSP and not CRL. Maybe some inhouse changes??? |
|
I'm guessing it's related to our network. Some OCSP requests succeed so my implementaion can't be that wrong.. :) |
|
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 work. |
|
That's interesting. I was fully blaming our infrastructure for the intermittent issues. I dug through the Java implementation of the OCSP check but could not find a reason why it would fail. The thing I noticed was that when it fails, it fails quickly (like tens of milliseconds quickly). |
|
I enabled the system property A similar positive case looks like this: on my local machine (Java 17.0.4.101-hotspot Win64) I can boil the error down to this exception: So eventually we do need to take into consideration, that the OSCP Service at |
|
Ha, here we have the source of the error: the expected length of The expected length is the "content length" which is missing and therefore set to
Indeed, no
|
|
Comparing it to a successful response, the
So it is indeed an error at the OSCP service of DigiCert, that they are not consistently returning the |
|
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:
|
|
The commit that changed it was openjdk/jdk@f5ee356 as a result for https://bugs.openjdk.org/browse/JDK-8179503 |
|
I filed a bug in the Java bug database. Internal ID 9075275 - under review. |
|
Wow, nice investigation! |
|
(I created the Stack traces from within the debugger with "evaluate expression") |
|
The server behaves correctly IMHO, as there is either a Content-Length or a Transfer-Encoding header (presumeably "chunked"), so I guess we have to wait for a JDK update here. Thanks for the analysis, followed with interest :) |
|
The bug has been accepted and you can follow under https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8308255 |
phax
changed the title
|
PR for the fix is already opened openjdk/jdk17u-dev#1361 |
|
The fix is supposed to be in Java 17.0.8 which is scheduled to be released 2023-07-18 according to https://www.java.com/releases/ |
|
Do you know when the Docker images will be updated? I did not find a schedule for any of the more popular JRE images |
|
No idea - sorry. I think that is vendor dependent but will happen asap (I hope ;-) ) |
|
So the Adoptium update 17.0.8 is out. I am closing this issue now. |
|
To me it looks like the issue is still persistent (in a way) in 17.0.8 - need to investigate |
|
I'm still waiting for release of the Semeru Images so I could not proceed with my tests yet. How did you find out it's still an issue? |
|
I've update the Java version on peppol.helger.com and still getting the same errors. |
|
Any updates on this or way around it? |
|
Not really, unfortunately, It seems like the Digicert OCSP responder as used by Peppol has some availabiltity problems (that we however cannot prove properly) - see also #155 Regarding the problem, that the certificate callback is not invoked when |
|
I spent some time debugging the issue, but I don't get any closer. To me it seems like the issue is somehow system specific. On Linux this happens quite often, on my Windows dev machine this is really hard to reproduce. Both run Java 17.0.8 Windows: The resulting Java exception on Linux looks like this: The respective method in |
|
I really digged deep into this issue, with So I don't think this is a general problem, but a problem of my specific setup :( |
|
I've built a minimal example project using your Revocation checker to try to reproduce the issue but I can't get it to fail locally at all.. I'm basically running the OCSP check in a loop it it always succeeds. I'm trying on Windows and on Linux with Java 17.0.8 (the patched version) and 17.0.6 (unpatched). |
|
This was the only reason it gave me when I was able to reproduce it: Note that for my tests it was using the top branch in in OCSP:getOcspBytes of this if statement where it neither set's a connection timeout nor a read timeout: |
|
Great thank you. Yes, the upper branch just seems to be right, as the request is only 80-90 bytes or so. Thanks. |
|
Update: I have opened a bug ticket, looks like this was also introduced in openjdk/jdk@f5ee356#diff-905a61d1dae19533a61cb5dd302071479775870df89d3a18e6db2537b007c803 |
|
Has been accepted https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8315979 |
|
Good catch. I never thought that the introduction of GET may also be cause of the problems. Seems like they also do trial and error in a way ;-) So going back to 17.0.3 could resolve the error. Direct link to the bug tracker: https://bugs.openjdk.org/browse/JDK-8315979 |
|
Issue has been closed as a duplicate... |
|
Are you able to update to Java 21 with your applications and give it another try? Apparently the discrepancy in timeout handling has been fixed there |
|
No, unfortunately not. I am more in favour of reverting to 17.0.3 for now. Or even Java 11 :D - let see if Java 17 gets some change in the next release 17.0.9 ... |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
The initial PR openjdk/jdk17u-dev#1361 was never merged. |
Hi Philip, I'm currently encountering an issue while testing with the new 2.1.0 release. I'm using Spring Boot 3.
When I start the Access Point and send a message to customer A, the transmission is successful.
While the application is still running, I send a message to customer B. The transmission fails with the following error:
com.helger.phase4.peppol.Phase4PeppolException: The configured receiver AP certificate is not valid (at 2023-05-05T09:28:22.546313412+02:00) and cannot be used for sending. Aborting. Reason: certificate is revoked at com.helger.phase4.peppol.Phase4PeppolSender._checkReceiverAPCert(Phase4PeppolSender.java:280 undefined) ~[phase4-peppol-client-2.1.0.jar!/:2.1.0] at com.helger.phase4.peppol.Phase4PeppolSender$AbstractPeppolUserMessageBuilder.finishFields(Phase4PeppolSender.java:652 undefined) ~[phase4-peppol-client-2.1.0.jar!/:2.1.0] at com.helger.phase4.peppol.Phase4PeppolSender$Builder.finishFields(Phase4PeppolSender.java:1061 undefined) ~[phase4-peppol-client-2.1.0.jar!/:2.1.0] at com.helger.phase4.sender.AbstractAS4MessageBuilder.sendMessage(AbstractAS4MessageBuilder.java:605 undefined) ~[phase4-lib-2.1.0.jar!/:2.1.0]If however I restart the application and send a message to customer B first, it succeeds. When I try to send a message to customer A then, it fails with the same exception.
The transmission keeps failing until I restart the application.
Let me know if you need additional logs. I skimmed through the code of phase4 and peppol-commons but did not find any obvious error yet.
The text was updated successfully, but these errors were encountered: