cancel
Showing results for 
Search instead for 
Did you mean: 

SSL handshake failure

Former Member
0 Kudos

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.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

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!

JaySchwendemann
Active Contributor
0 Kudos

Great to hear this has been resolved. Just being curious: Did you end up sending via port 990 (which should not work IMHO) or any other ports?

Cheers

Jens

Former Member
0 Kudos

Yes, I used port 990 for the control connection. For the data connection, a whole range of ports is being used. We're still figuring out what that range is exactly.

Answers (3)

Answers (3)

Former Member
0 Kudos

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

JaySchwendemann
Active Contributor
0 Kudos

Which PI Version are you on? Dual or Single Stack? Not sure if the new errors are related, though 😕

Former Member
0 Kudos

PI 7.11 SP13, dual stack.

- edit -

I tried connecting using IP instead of server name and got the error "Peer certificate rejected by ChainVerifier". I'll investigate this further. Problem with the certificate after all?

Message was edited by: Iddo Rijsdijk

iaki_vila
Active Contributor
0 Kudos

Hi Iddo,

There is some note with this problem but with below versions than yours. Then the problem can be with the certificate. Have you restarted PI ICM after certificate importing?

Regards.

Former Member
0 Kudos

I imported the certificate in the NWA. I'm not using ICM in this scenario. I got the Peer certificate rejected by ChainVerifier due to the fact that the IP address didn't match with the server name in the certificate, which makes sense.

Which note did you find?

JaySchwendemann
Active Contributor
0 Kudos

This is excepted, SSL needs domain names instead of IP

JaySchwendemann
Active Contributor
0 Kudos

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

Former Member
0 Kudos

Certificate authentication is not supported by the FTPS server. Only username/password.

WinSCP:

PI:

JaySchwendemann
Active Contributor
0 Kudos

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

Former Member
0 Kudos

No sorry, port 21 does not work. I have asked the FTPS owner for more information.

former_member184720
Active Contributor
0 Kudos

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.

iaki_vila
Active Contributor
0 Kudos

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.

Former Member
0 Kudos

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?

JaySchwendemann
Active Contributor
0 Kudos

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

Former Member
0 Kudos

Hi Jens,

yes using of XPI inspector confirmed the supposed reason some weeks ago.

Changing host name of Server solved it!

Thanks,

Fabian

iaki_vila
Active Contributor
0 Kudos

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

Former Member
0 Kudos

Hi Iñaki,

Yes, I tried all of that. I got a different error with the active connection though (not allowed).

JaySchwendemann
Active Contributor
0 Kudos

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

Former Member
0 Kudos

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)