Inovis (VAN) connectivity?

, ,
1

Is anyone doing EDI with Inovis?

Issue - unable to establish connection from IS 7.1.1/EDI 6.5.2 via FTPSSL.

Inovis has setup our new FTP mailbox & has provided me the connection details. Attempts to get VAN.VANConnectivity:getFromVAN going (as per the documentation) to prove connectivity have failed. I’m stuck at the pub.client.ftp.login service (called from FTPConnection which is called from getFromVAN).

From the trace log, I can see the dialogue starting but pub.client.ftp.login fails with “com.wm.net.ftpCException: [ISC.0064.9016] FTP AUTH command failed with error : Server certificate rejected by ChainVerifier”.

Inovis didn’t provide a certificate at first. They did send one after I asked and it has been saved (in der format, including the intermediate and root CAs) on the IS server. I’ve tried with and without defining a TN Partner (though I’m not sure how to reference a TP for an FTP service…).

SAG support has tried connecting too and says Inovis’s certificate is not valid. Inovis maintains that their certificate is just fine.

From SAG "Even in my setup after I ran the ftp service, I’m getting the same chain verifier error as you see in the error log.
So configured inovis certs to verify if the chain is not proper. Below is the error message from openssl -

As you can see the certificate chain is not proper -

C:\openssl>openssl s_client -connect localhost:9443 -verify 6 -showcerts verify depth is 6 Loading ‘screen’ into random state - done
CONNECTED(00000784)
depth=0 /C=US/ST=Georgia/L=Alpharetta/O=Inovis, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=ftpssl.gateway.inovisworks.net
verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=Georgia/L=Alpharetta/O=Inovis, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=ftpssl.gateway.inovisworks.net
verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=Georgia/L=Alpharetta/O=Inovis, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=ftpssl.gateway.inovisworks.net
verify error:num=21:unable to verify the first certificate verify return:1 3932:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:.\ssl\s3_pkt.c:1031:SSL alert number 20 3932:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:.\ssl\s23_lib.c:226:"

Do I need to setup a trading partner for Invois in TN? If I do and configure the certs like I would for an AS2 partner, how do I feed the TPID to the FTP service? (e.g. ediint has sender & receiver ID inputs for the AS2 id, ftp doesn’t).

Thoughts? Tips? Extended settings suggestions?

2

I believe you need TP (Inovis) in TN in case you are processing any AS2/Http certs etc…But are you using PublicQueues and VAN FTP delivery services Inbound/outbound?

In the getFromVAN service did you set secureFTP to true and configured certs IS level?

HTH,
RMG

3

Thanks RMG, We plan on using queues and the VAN delivery services.

This is our first attempt at FTP and first attempt to communicate with a VAN (we are doing EDI and RosettaNet via AS2 with lots of other partners).

I’ve tried with and without secureFTP, and all 4 settings (none, SSL, TLS, TLS-P) - no impact/resolution of the chain error.

4

They might be looking for secureFTP comm and FTP/S with certs.May be you should troubleshoot both ends checking network layer also while doing connection test.I have seen first time attempts these kind of issues (nuts and bolts) are common to make it finally work.

We have only AS2/Http connection with them at this moment and can’t comment on FTP side.

HTH,
RMG

5

rmg, are you exchanging EDI docs with Inovisworks directly to and from webMethods via AS2?

6

Yes EDI/XML side.

7

interesting! I thought the preferred (aka “only”) method of communicating with a VAN was via the delivered ftp-based services and queues etc.

I’ll research/pursue AS2 with Inovis if I can’t get AS3 going in short order.

Thanks for pointing out a different solution to consider (other than jumping to another VAN)!

8

Yes try Inovis/GXS AS2 they do support both.we have no choice keeping multiple gateways with external world interconnects.

9

Follow-up and “resolution” = must communicate via AS2 with Inovis at this point in time. Inovis does indeed have a cert chain issue that apparently only webM is keen to enforce (not a bad thing). SAG support did come back today and mentioned that at least one other SAG client has hit the wall on the same thing. Support also mentioned the following feature/solution request to “accomodate bad cert chains” if anyone is interested in promoting/voting for…

[URL=“http://softwareag.force.com/ideas/viewIdea.apexp?id=087200000004MDLAA2”][U][SIZE=2][COLOR=#0000ff][SIZE=2][COLOR=#0000ff]http://softwareag.force.com/ideas/viewIdea.apexp?id=087200000004MDLAA2[/u][/color][/size][/COLOR][/SIZE][/URL]

10

Voted…Done!