Turning on AS2

[senikk]

When turning on AS2 we got this error when sending:

Sending failed Unexpected error during execution of http POST to https://ap.unimicro.no/oxalis/as2: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The same code runned nicely with START.

Oxalis 3.0.0

[senikk]

Tried upgrading to Oxalis 3.0.1, still same issue

[senikk]

Found #168, looking into the information there

[senikk]

InstallCert fixed it :)

[senikk]

In our log we now got:
"Sending failed Unexpected error during execution of http POST to https://ap.unit4.com/oxalis/as2: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors"

Is it something wrong with our installation, Oxalis 3.0.1 or Unit4 installation of Oxalis? Adding with InstallCert for every accesspoint failing seems not like a good solution.

[senikk]

Checking our logs further everyone failing is to https://ap.unit4.com/oxalis/as2 no one else.

[teedjay]

That was a bit strange, UNIT4 has about 80% inbound AS2 right now - and is based of a standard GlobalSign / G2 which should be included in Java default truststore.

I see you have a very old Java VM, could you run the keytool kommand and verify that is contain recent the ROOT CA at least, like this :

keytool -list -keystore </path/to/java/lib/security/cacerts> | grep '3E:45:52:15:09:51:92:E1:B7:5D:37:9F:B1:87:29:8A'

[senikk]

I got a hit for that grep in cacerts but it didn't work until I added ap.unit4.com:443 using InstallCert to the jssecacerts file.

[teedjay]

If you have "jssecacerts" present that one will be used instead of cacerts.

[teedjay]

If you want to use your own "jssecacerts" instead of cacerts I think you'll have to add every CA you want to trust yourself. The "cacerts" that comes shipped with recent Java Runtimes should be enough to run Oxalis.

[senikk]

Telenor have the same problem sending to our accesspoint. Since they also have a lower version of Java than SendRegning/Unit4 hopefully a newer version will fix it.

[pavelsbubens]

We have the same problem with one production server - START protocol works fine, but AS2 fails with "unable to find valid certification path to requested target" exception.
Did check oxalis code and found that SoapDispatcher for START protocol is "patched" for this problem (using eu.peppol.outbound.ssl.AccessPointX509TrustManager).
But As2MessageSender does not.
Is there any reason why START protocol was patched, but AS2 was not patched ?

[aaron-kumar]

installing a cert in "jssecacerts" is not a solution for production system. This is only workaround for development system where we install self-sign certificate.

SSL certificates should be trusted automatically.

@teedjay Are you working on same?

[teedjay]

The reason for AS2 "not beeing patched" is for it to verify some of the PEPPOL AS2 Transport Infrastructure requirements regarding SSL usage, such as :

• "The DestAP MUST implement HTTPS with certificate chains to certificate authorities which would be considered to be trusted by the PEPPOL community."
• "The DestAP URL SHOULD use the default port 443. This assures firewall rules are often setup in advance."
• "The certificate MUST correctly identify the DestAP URL e.g. no self-signed certificates."
• The DestAP URL SHOULD use the default port 443. This assures firewall rules are often setup in advance.
• etc

@aaron-kumar I'm not currently working on something related to this, and it seems like @senikk is about to solve this by adding intermediate certificates so that his server will present the full certificate chain.

[pavelsbubens]

You are right, it could be resolved by adding intermediate certificates to a response from server. We will check this as well.
I think it would be good idea to mention this in readme file for oxalis. So all users of it are informed.

[pavelsbubens]

Yes, everything is working once intermediate certificate is added. Thanks!

[senikk]

Working nicely on our server aswell. The other accesspoint having problem sending to us doesn't have the problem anymore :)

[teedjay]

That is great news! I'll add the solution to the readme as @pavelsbubens suggested.

[teedjay]

The solution has been added to troubleshooting section.

[simakas]

hi, can anyone explain what is the fix? problems occurred after upgrade to 3.0.2..

[teedjay]

The fix is to add any missing intermediate certificate(s) to the certificate chain on the server side. That way the server can present a complete certificate chain to the client. The correct intermediate certificates can be downloaded from the SSL certificate issuers website.

[simakas]

sorry, but the explanation is very blurry. is there some new setup step or requirement? is it for app server keystore or oxalis keystore? app servers keystore always contains intermed..

[pavelsbubens]

You can use ssllabs to verify certificate chain
https://www.ssllabs.com/ssltest/analyze.html

Check Certification Paths sections -> all intermediate certificate(s) should have status Sent by server.

[simakas]

Ports other than 443 not supported....

On Tue, Nov 18, 2014 at 10:29 AM, Pavels Bubens notifications@github.com
wrote:

You can use ssllabs to verify certificate chain
https://www.ssllabs.com/ssltest/analyze.html

Check Certification Paths sections -> all intermediate certificate(s)
should have status Sent by server.

—
Reply to this email directly or view it on GitHub
#173 (comment).

simakas@gmail.com
simonas@awsys.no
+370 699 66435

[teedjay]

You should use well known port 443 for your AS2 endpoint (se snippets from the PEPPOL AS2 Transport Infrastructure requirements regarding SSL about 11 comments back).

The certificate chain issue is not directly related to any Oxalis configuration files at all and you should not do anything to your Oxalis keystores or Java keystores.

Often HTTPS is not even handled by the application server running Oxalis at all but terminated at a load balancer or reverse-proxy layer in front (by software such as nginx, apache, haproxy). So which format the SSL certificate + intermediates needs to be in and how they are installed are very much dependant on your setup.

If you have just the SSL certificate as a ".crt" file you might have to download the intermediate as a ".crt" as well and concatinate them together. If you got the SSL certificate as a ".pem" from the issuer, it might allready have the intermediate inside it.

If you tell a little more about your server set-up, we might be able to give you some more precise details.

[pavelsbubens]

Did you get any result scanning with 443? It is possible that the same certificate is used for other ports as well.

[simakas]

than you both for replies. infrastructure is very simple:

• apache on port 80/443 - our services on http and https
• tomcat on port 8443 - AP services
  both apache and tomcat both got their own separate certificates, it was all ok for ages. so I must implement a proxy/balancer and run tomcat only on 443? register another domain name..? sounds awkward..

@pavelsbubens - 443 scans ok, its apache. just ssllabs dont support other port scans. sslshopper.com says all intermediates are in places.

[teedjay]

You do not need another domain name or any proxy/balancer. And you do not need to install any SSL certificates on Tomcat at all, unless your Tomcat is available directly on the Internet at port 8443.

Since you already have Apache running SSL/TLS at port 443 you could let Apache handle all the HTTPS and use "ProxyPass" feature in Apache to pass all the "oxalis" traffic to Tomcat. Like this setup : http://pwu-developer.blogspot.no/2011/04/securing-tomcat-with-apache-web-server.html

Installing the SSL cert and the chain certificates (intermediates) on Tomcat is actually a little tricky, but if you really need to there are some troubleshooting in the Tomcat docs :
https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Importing_the_Certificate

[simakas]

hmz. are there any new changes in 3.0.0+ that limits usage of other ports? so I at least downgrade until I find the way out. can someone tell the cause of the problem?
tomcat is directly available on port 8443, has its own certificate, was working just fine.. ..intermediate was never an issue, intermed incorporation is actually missing in your link, its imported in following order: root, intermed, tomcat..
there is a little problem with apache since its oracle custom apache and its fully dedicated for a single task. port 443 is also already handled and I cant take it away. will probably use a subdomain then?

[teedjay]

What problem did you actually have? This issue #173 is about sending AS2 to AccessPoints that does not have correctly configured SSL certificates. You cannot downgrade away from that issue, the AS2 require the receiving AccessPoint to have a correctly configured SSL certificates.

If you managed to run the analyzer on you Tomcat port 8443 without any warnings or errors you should be fine. If you post you accesspoint URL here I could try to send you a test message to verify?

[simakas]

i get the PKIX error, same one as in issues header. my AP is atworklogin.com:8443 (https://atworklogin.com:8443/oxalis/), you can also test send invoice to org 989272047.
SSLpoke and sslchecks - all looking good. sender reported an error:

[ 2014-11-17 15:44:11,399 ] 136908  86876K DEBUG [JAVA]  , 0.0021707 secs]
[ 2014-11-17 15:44:11,524 ] 40836  86920K ERROR [VM] Job failed. Message='java.lang.IllegalStateException: Unexpected error during execution of http POST to https://atworklogin.com:8443/oxalis/as2: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target'
[ 2014-11-17 15:44:11,524 ] 40836  86920K ERROR [VM] java.lang.IllegalStateException: Unexpected error during execution of http POST to https://atworklogin.com:8443/oxalis/as2: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[teedjay]

Your issue is actually a bit different than the one described in this issue. You use GoDaddy with SHA256 which have a known issue with Java. The problem and the fix can be found in issue #168 .

Basically you need to rekey your cert with SHA1, it is free and can be done at GoDaddy site.

[simakas]

can you check again now? changed from SHA2 to SHA1..

[teedjay]

Now it seems to be ok (sendt at 12:49)
Message sent to https://atworklogin.com:8443/oxalis/as2 using AS2 was assigned transmissionId : b521ab9e-6038-4719-b197-93bdde212919

[simakas]

great, thanks. what certs are used by others to be on the safe side?

[teedjay]

I'm not quite sure, but there haven't been any issues lately (except that GoDaddy issue) - so what's running on accesspoints today seems to be pretty safe choices. ELMA has a page listing accesspoint url's, which can be opened in a browser to look at the SSL cert : https://smp.difi.no/endpoint