on 03-25-2015 4:26 PM
I'm trying to establish a connection via FTPS using password authentication. Setting up the communication using WinSCP from the server works fine, so firewalls aren't an issue.
The logging shows that the connection enters an error during the SSL handshake, but I can't figure out what's the error exactly. I hope your can help. The logging is this:
ssl_debug(7931): Starting handshake (iSaSiLk 4.403)...
ssl_debug(7931): Sending v3 client_hello message to xxxx.xxx.xxx:port, requesting version 3.1...
ssl_debug(7931): Received v3 server_hello handshake message.
ssl_debug(7931): Server selected SSL version 3.1.
ssl_debug(7931): Server created new session 00:00:00:00:00:00:00:00...
ssl_debug(7931): CipherSuite selected by server: SSL_RSA_WITH_3DES_EDE_CBC_SHA
ssl_debug(7931): CompressionMethod selected by server: NULL
ssl_debug(7931): TLS extensions sent by the server: renegotiation_info (65281)
ssl_debug(7931): Server supports secure renegotiation.
ssl_debug(7931): Received certificate handshake message with server certificate.
ssl_debug(7931): Server sent a 2048 bit RSA certificate, chain has 4 elements.
ssl_debug(7931): ChainVerifier: Found a trusted certificate, returning true
ssl_debug(7931): Received certificate_request handshake message.
ssl_debug(7931): Accepted certificate types: RSA
ssl_debug(7931): Accepted certificate authorities:
ssl_debug(7931): (empty list)
ssl_debug(7931): Received server_hello_done handshake message.
ssl_debug(7931): No client certificate available, sending empty certificate message...
ssl_debug(7931): Sending client_key_exchange handshake...
ssl_debug(7931): Sending change_cipher_spec message...
ssl_debug(7931): Sending finished message...
ssl_debug(7931): Received change_cipher_spec message.
ssl_debug(7931): Received finished message.
ssl_debug(7931): Session added to session cache.
ssl_debug(7931): Handshake completed, statistics:
ssl_debug(7931): Read 4902 bytes in 6 records, wrote 463 bytes in 4 records.
It has been solved. Turned out that the firewall guy didn't actually test from the server but his own PC. The ports weren't opened on the firewall.
Thanks Jens and Iñaki for your help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The certificate seems to be OK. XPI trace shows the following information, besides the error I already posted:
Catching java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key <servername>
Catching com.sap.aii.af.service.administration.api.i18n.LocalizationNotPossibleException: Could not locate resource bundle entry <servername> for resource bundle 'com.sap.aii.adapter.file.i18n.rb_FileAdapter_ChannelMonitor' and locale en_US
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah, sorry, saw this post too late, as you already stated, rejecting the certificate when using IP is expected.
What seems wierd is that your SSL Debugging states an empty accepted CA list
ssl_debug(7931): Accepted certificate authorities:
ssl_debug(7931): (empty list)
Also I'm not completely sure why your client (read "your PI system") may send a empty client certificate.
ssl_debug(7931): No client certificate available, sending empty certificate message...
could be that the FTPS server is requesting client certificate but PI does not provide one (since you configured to use username / password). May depend on the server if authentication stack is allowing username / password as an fallback to client certificate. Maybe you could clarify with the FTPS server provider
Many thanks and kind regards
Jens
I had a similar situation once. 990 was suggested by the FTPS provider. However, 990 is implicit port. 21 is explicit port, see here http://service.sap.com/sap/support/notes/1554886 (already mentioned note)
--> Please try switching to port 21 (you may want to double check with your provider and your and the providers FW team if port is accessible)
HTH
Cheers
Jens
It can't be 990 as it's always implicit.. Port is something that setup by admin.. So they should open it before you can use.
Implicit FTPS was expected to listen on the IANA Well Known Port 990/TCP for the FTPS control channel, and to 989/TCP for the FTPS data channel. This allowed administrators to retain legacy-compatible services on the original 21/TCP FTP control channel.
FTPS - Wikipedia, the free encyclopedia.
It can be anything else.. something like 221 or 9999 etc.
While they setup FTP, they get to choose "allow explicit/implicit connections". As already mentioned by Jens, it should be explicit.
HI Iddo,
I found these notes:
1577913 - PI SOAP receiver channel cannot connect over HTTPS (Not applicable to your system) and you are using FTP.
However you can try with the parameter strictHostnameChecking:
1992392 - Peer certificate rejected by ChainVerifier error due to name mismatch in FTPS Adapter
Regards.
Hello Jens,
I have same issue on a PI 7.4 AEX PL 8
iaik.security.ssl.SSLCertificateException: Peer certificate rejected by ChainVerifier
Problem with verifying the certificate chain while connection to a FTPS Server (on IIS Windows Server 2008)
I suppose the problem is as described in your mentioned oss note: 1992392 - Peer certificate rejected by ChainVerifier error due to name mismatch in FTPS Adapter
Certificate is issued (CN) to: ftpstest.domain.net
But the hostname is only "ftpstest"
While checking the Certificate in WinSCP I am getting this notification:
Do you think the certificate has to be issued without domain name?
Far being an expert in this area but yeah, I think domain name ought to be obligatory in this situation in order to establish chain of trust.
However, you mentioned: "certificate is issued to ftptest.domain.net" so this should already be ok. The server presenting the certificate however must be DNS resolvable via ftptest.domain.net also, so you might look into that and change the server name accordingly.
Apart from that I would encourage you to use XPI Inspector to track this sort of issues down. Invaluable helper tool, that is.
Cheers
Jens
Hi Iddo,
Have you test with winscp in the same subnet that PI?, that could be a firewall problem.
Have you tried to change the connection type from 'active' to 'passive' (or vice versa) ?
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Iddo,
I don't actually see an error in your logging excerpt. Is that your problem?
Anyways, please mind that PI doesn't support implicit FTPS, something I stumbled over in the past. See here for details https://service.sap.com/sap/support/notes/1554886
Also important seems to be to order of your certificate chain http://scn.sap.com/docs/DOC-26940 and the command order as your FTPS provider gave you.
See also here for general reference http://scn.sap.com/people/rajasekhar.reddy14/blog/2010/04/13/how-to-configure-ftps-in-file-adapter
You might consider deep diving into tracing with XPI Inspector which might speed up trouble shooting time considerably.
Cheers
Jens
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks. I'll look into this certificate chain. The FTPS uses explicit encryption, hence it should be technically possible to connect to the server.
The error after the logging I posted earlier is this:
Catching java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:368)
at java.net.Socket.connect(Socket.java:531)
at java.net.Socket.connect(Socket.java:477)
at java.net.Socket.<init>(Socket.java:374)
at java.net.Socket.<init>(Socket.java:187)
at iaik.security.ssl.SSLSocket.<init>(Unknown Source)
at com.sap.aii.security.lib.net.ssl.impl.IAIKSSLSocketFactoryImpl$SSLDebugSocketImpl.<init>(IAIKSSLSocketFactoryImpl.java:266)
at com.sap.aii.security.lib.net.ssl.impl.IAIKSSLSocketFactoryImpl.createSocket(IAIKSSLSocketFactoryImpl.java:144)
at com.sap.aii.adapter.file.ftp.FTPCtrl.createDataSocketPASV(FTPCtrl.java:437)
at com.sap.aii.adapter.file.ftp.FTPCtrl.createDataSocket(FTPCtrl.java:290)
at com.sap.aii.adapter.file.ftp.FTPCl.dir(FTPCl.java:1125)
at com.sap.aii.adapter.file.ftp.FTPCl.listFiles(FTPCl.java:1230)
at com.sap.aii.adapter.file.File2XI.getFtpList(File2XI.java:850)
at com.sap.aii.adapter.file.File2XI.invoke(File2XI.java:637)
at com.sap.aii.af.lib.scheduler.JobBroker$Worker.run(JobBroker.java:534)
at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
at java.security.AccessController.doPrivileged(Native Method)
at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:182)
at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:280)
User | Count |
---|---|
80 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.