Hello and good day, I’m trying to activate notifications for newly created DOIs on our platform, I’m following this guide documentation/content-registration/verify-your-registration/notification-callback-service/ in the crossref page,
but I’m having an issue trying to test the endpoint, I’m following the steps until the “2. Test your endpoint” step.
I send the test request and it goes ok but the notification never arrives and when I query the notifications I get this this error
unable to complete notification: callback-notification
with this exception
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
If you want more information I’ll be happy to post what I have.
Could you let me know if you are still having this issue. I am not aware of any issues currently but I would be happy to investigate further for you if you have more information you can send me. What is your username you are using to create the endpoint against?
Thank you for your help, I’m still having the issue, the username is morr, I created one endpoint in the test environment (this one test.crossref.org/notification-callback/exec/createNotificationCallback), and that went alright, but when I test that endpoint (using this test.crossref.org/notification-callback/exec/createNotificationCallback), it doesn’t work. When I query the notification callback attempts (using this test.crossref.org/notification-callback/exec/findNotificationCallbackAttempts) I see the error I described in the first post.
So in the example you say you created an endpoint in the system using test.crossref.org/notification-callback/exec/createNotificationCallback. Is that one you used?
To create an endpoint point using cURL you would need to use "https://0-test-crossref-org.library.alliant.edu/notification-callback/exec/setNotifyEndpoint\
Then you test that using "https://test.crossref.org/notification-callback/exec/createNotificationCallback
Hello Paul
Thanks you for your response, I posted the wrong link in my previous answer but I used the endpoint you mentioned and created the endpoint without issues, it’s when I test the endpoint using createNotificationCallback that doesn’t work, and after querying the notifications I see the error I mention in my first post
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Also I wanna add that the endpoint was created successfully because when I query the notifications, the response mentions it, so it seems to be an issue sending the notification to our server
@pdavis sorry to be so annoying but I’m stuck here, our endpoint works and the notification error doesn’t say much (and it doesn’t seem to be an error in our endpoint), just want to know what can I do to get the notification callback service working.
Sorry for the delay I was checking in with a developer as I wasn’t sure on this one. He said that he thinks this is possibly something on your end as there are not any other similar problems being reported here.
He asked me to ask if you are using TLS 1.2? TLS versions 1.0 and 1.1 are no longer supported and as the issue is negotiating a secure connection this could be why.
So our developer is going to check that our library is updated to negotiate with 1.3, do you know if you are requiring a minimum of 1.3 which could cause the handshake error? If so could you try allowing 1.2 to see if that helps?
Hello Paul, thank you for your answer, our site works with TLS from 1.1 to 1.3, you can see out SSL results here https:// www.ssllabs. com/ssltest/analyze.html?d=next.morressier. com&latest, also according to the site it seems to work with most java versions except with version 6, please let me know if you need more information.
Hello Paul, would you have any more information about this issue? I’ve tried to see logged information on our side but I don’t have much information to continue, if you could provide a little bit of info from your side I could try to find why is this happening.
I feel fairly comfortable that I have come to a conclusion on the issue you have noticed. I’ll share some steps I took, recommend a solution, and walk you through how to test on your end.
I then proceeded to connect to the internal system that sends notifications. From there I ran curl -o /dev/null -s -w "%{http_code}\n" https://next.morressier.com. The result was 200, and this lead me to believe the issue was not at a system level, but with the software used to send the webhook request.
Based on researching javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure I decided the next step was to inspect the ciphers we had available, and the ciphers available on your end.
There is no matching cipher between us. This is causing the handshake failure.
If you’re comfortable with java, and have JDK 8 on a machine, you can test this out by grabbing the pure java example client listed here Enabling SSL debugging in a standalone Java program - Red Hat Customer Portal. You can compile it on the cli by typing javac JavaHttpClient.java. To run it simply call java -Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack JavaHttpsClient https://next.morressier.com:443 1. You can see it output a list of ciphers your end supports and that the jdk 1.8 supports.
I highly recommend checking out https://ssl-config.mozilla.org/. It’s a great source for getting example configurations for TLS settings that are widely supported.
If there’s anything else we can help with, let us know!
@jschuweiler First of all thank you so much for your answer, so I checked the page you mentioned for the cipher suites supported by your side and it seems we do have ciphers in common, if you are using the SunJSSE provider and Java 1.8 we should have ciphers in common, as for our side we are using Google’s load balancing, here you can find the SSL configuration for Google’s load balancer https:/ /cloud .google.com/load-balancing/docs/ssl-policies-concepts#defining_an_ssl_policy, in particular I noticed this one TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 which appears in the JDK 8 column of the link you shared and in all of the google load balancer’s profiles.
I also tried to test from my side with the example you showed me (thanks again for that), so I installed openJDK 8, this is my current installed version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07)
OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)
and I ran the example, at first it didn’t work with this error Exception in thread "main" java.io.IOException: Server returned HTTP response code: 403 for URL: https://next.morressier.com:443 , because the page blocked the request because it didn’t have a User agent, so after adding a basic user agent the request worked fine, in both cases the handshake was successful (I was gonna add an image or a file of this test but I can’t upload images or files, here’s an external link if you want to see the result https:/ /imgur.com/a/hs6qjJ9)
So if it’s a cipher problem could you be using a different suite than SunJSSE? another thing that I think could be the problem is that I checked again the SSL server test and the only version of java that we seem to fail with handshake error is version 1.6, could that be the issue?
If I run openssl s_client -tls1_2 -connect next.morressier.com:443 off of my personal OSX machine, and the server that notifies webhooks I see the following:
CONNECTED(00000003)
140581578844064:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1644424595
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
If I run it from my personal ubuntu 20 desktop I do get back a matching cipher. I’ll do some more poking, but it sure seems like cipher negotiation is not going well. Let me see what else I can find to back this up.
The narrow band of intersecting certificates led us to a note about java versions. We’ve slightly bumped the version of java. Can you give notifications a try now?
Hello, thanks again for your help, sadly still doesn’t work, I took a look at the OSX issue and found that it doesn’t work in because the OSX openssl version by default doesn’t send the server name information, if you run openssl s_client -tls1_2 -connect next.morressier.com:443 -servername next.morressier.com it will work, so could it be possible that the java client doens’t support SNI?