Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Received fatal alert: handshake_failure #197

Closed
senikk opened this issue Nov 20, 2014 · 12 comments
Closed

Received fatal alert: handshake_failure #197

senikk opened this issue Nov 20, 2014 · 12 comments
Milestone

Comments

@senikk
Copy link

senikk commented Nov 20, 2014

12:07:24.468 [http-bio-443-exec-7] INFO no.unimicro.ap.UniOutbox - Starting document sending
12:07:24.468 [http-bio-443-exec-7] DEBUG no.unimicro.ap.UniOutbox - sender: 9908:931054600
12:07:24.470 [http-bio-443-exec-7] DEBUG no.unimicro.ap.UniOutbox - receiver: 9908:938708606
12:07:24.470 [http-bio-443-exec-7] DEBUG no.unimicro.ap.UniOutbox - channel: Uni V3
12:07:24.470 [http-bio-443-exec-7] DEBUG no.unimicro.ap.UniOutbox - SENDER DOKUMENT til aksesspunkt
12:07:24.545 [http-bio-443-exec-7] DEBUG eu.peppol.smp.SmpLookupManagerImpl - SML hostname: sml.peppolcentral.org
12:07:24.567 [http-bio-443-exec-7] DEBUG e.p.document.PlainUBLHeaderParser - Creating DocumentParser for type : Invoice
12:07:24.568 [http-bio-443-exec-7] DEBUG oxalis-com - Constructed SMP url: http://B-4dfdfc495f0ab5837b8f2e262bea1dbc.iso6523-actorid-upis.sml.peppolcentral.org/iso6523-actorid-upis%3A%3A9908%3A938708606/services/busdox-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AInvoice-2%3A%3AInvoice%23%23urn%3Awww.cenbii.eu%3Atransaction%3Abiitrns010%3Aver2.0%3Aextended%3Aurn%3Awww.peppol.eu%3Abis%3Apeppol4a%3Aver2.0%3Aextended%3Aurn%3Awww.difi.no%3Aehf%3Afaktura%3Aver2.0%3A%3A2.1
12:07:24.813 [http-bio-443-exec-7] DEBUG eu.peppol.smp.SmpLookupManagerImpl - SML hostname: sml.peppolcentral.org
12:07:24.816 [http-bio-443-exec-7] DEBUG e.p.o.transmission.As2MessageSender - Outbound MIC is : E+rlKHp+2wxbKMhO6pJDumGdqE8=, sha1
12:07:24.849 [http-bio-443-exec-7] DEBUG e.p.a.As2DispositionNotificationOptions - Inspecting signed-receipt-protocol=required,pkcs7-signature; signed-receipt-micalg=required,sha1
12:07:24.850 [http-bio-443-exec-7] DEBUG e.p.o.transmission.As2MessageSender - Sending AS2 from 9908:931054600 to 9908:938708606 at https://peppol.logiq.no:8443/oxalis/as2 type urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biitrns010:ver2.0:extended:urn:www.peppol.eu:bis:peppol4a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0::2.1
12:07:25.043 [http-bio-443-exec-7] INFO no.unimicro.ap.UniOutbox - Sending failed Unexpected error during execution of http POST to https://peppol.logiq.no:8443/oxalis/as2: Received fatal alert: handshake_failure

Have anyone seen this before and what is causing it?

@teedjay
Copy link
Contributor

teedjay commented Nov 20, 2014

Others have reported the same issue, started a few days back. Probably some config change on Logic's side - perhaps some SSLv3 related (Poodle patching)?

@christian-andersson
Copy link

I have also started seeing this.. do we know if anyone has contacted logiq ?

@teedjay
Copy link
Contributor

teedjay commented Nov 20, 2014

Logic has been contacted.

@teedjay
Copy link
Contributor

teedjay commented Nov 20, 2014

Logic will reverse their POODLE patch right away until Oxalis 3.1.0 has been released and access points have upgraded.

So those having trouble should be able to deliver to Logic again from around 14:00 today.

@teedjay teedjay closed this as completed Nov 20, 2014
@senikk
Copy link
Author

senikk commented Nov 26, 2014

Having problems with another accesspoint with just the same handshake_failure message, this time peppol.xledger.net

@teedjay
Copy link
Contributor

teedjay commented Nov 26, 2014

Seems like the same issue ...

If you use Oxalis 3.0.2 today you could build the 3.1.0-SNAPSHOT version from sources and replace your outbound Oxalis installation. The latest snapshot code contains a TLS fix for outbound, we are running that version ourselves in production.

But beware - the snapshot release are being worked on, so you should use this commit :
https://github.com/difi/oxalis/tree/43629048f0b64ae97667bba889af74c445ea02b7

@senikk
Copy link
Author

senikk commented Nov 28, 2014

Suggestion from xledger to upgrade to Java 1.7, could that also be a reason?

@gunnarvo
Copy link

gunnarvo commented Dec 1, 2014

Yes, last week Xledger upgraded to Oxalis 3.0.2/Java 1.7.0_71, but with the effect of not being reachable from a couple of other access points.
Thanks to Evry - they upgraded their outbound Oxalis to 3.1.0-SNAPSHOT, and after that had no problem sending to us.

For everyone experiencing this handshake problem you should indeed consider upgrading to Oxalis 3.1.0-SNAPSHOT!

@teedjay
Copy link
Contributor

teedjay commented Dec 1, 2014

@gunnarvo The Java 1.7.0_71 contains some poodle patching from Oracle. Does this mean you host your SSL certificate in Tomcat?

@teedjay teedjay reopened this Dec 1, 2014
@gunnarvo
Copy link

gunnarvo commented Dec 2, 2014

Yes.

@teedjay teedjay added this to the Oxalis 3.1 milestone Dec 2, 2014
@teedjay
Copy link
Contributor

teedjay commented Dec 2, 2014

Oracle Java 1.7.0_71+ removes SSLv3 from HTTPS so the effect of running SSL certificates on the Java app-server is the same as explicit "Poodle Patching" of nginx, apache, ha-proxy by removing SSLv3.

This issue has been fixed in Oxalis 3.1.0 which will be released later today.

@teedjay teedjay closed this as completed Dec 2, 2014
@teedjay
Copy link
Contributor

teedjay commented Dec 11, 2014

Since we still get a few questions about this - here is a quick summary :

1 - Earlier Oxalis versions might not be able to deliver messages to access points that have removed SSLv3 support (aka "Poodle Patched"). The new Oxalis 3.1.0 client fixes this - and those that see "handshake_failure" when sending MUST upgrade.

2 - The SSLv3 issue has nothing directly to do with the Oxalis server (receiving PEPPOL messages). But when you block SSLv3 on the server side some old Oxalis clients might be unable to connect using HTTPS and cannot deliver messages to you (ref point 1).

We therefore advice everyone to upgrade to Oxalis 3.1.0 as soon as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants