Secure FTP Client Connection Error - "Secure connection error, return code -11"
Last Post 15 Apr 2010 05:23 PM by Scott Klement. 9 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
James Sullivan
New Member
New Member
Posts:4

--
13 Apr 2010 04:46 PM
This is probably a simple setup error, might be old hat to those already doing FTP/SSL. I am getting a "-11" return code while trying to test out a secure (FTP/SSL) client connection to a non-iSeries FTP server. Here's the command I use to start the FTP client session: STRTCPFTP RMTSYS(FTP.VENDOR.COM) CCSID(*DFT) PORT(21) SECCNN(*IMPLICIT) And here's what I get back: Connecting to host FTP.VENDOR.COM at address 146.145.191.7 using port 21. Secure connection error, return code -11. The vendor says no certificate exchange is needed, but I wonder. Even though I am just the FTP client - not the server- won't I need to import their certificate into my iSeries DCM? All replies will be appreciated.
Satid Singkorapoom
Senior Member
Senior Member
Posts:2990
Avatar

--
14 Apr 2010 01:48 AM Accepted Answer
What is the message ID? Is it TCP3D2C? If so, I did a search in IBM Support Portal web site with "secure ftp client" and found this IBM Technote which may help: Secure FTP Data Connection Fails to Open with a TCP3D2C.
.... A SECDATA P subcommand had to be issued by the client for the server to reply with the data encrypted.
This one may also be useful: Setting Up Secure FTP Client. If they do not help, please do more search in IBM Support Portal web site.
Marcia Dore
Veteran Member
Veteran Member
Posts:546

--
14 Apr 2010 04:50 PM Accepted Answer
You would still need to send a sign on and password - thinking that is what it is waiting for. Ask the vendor if they have an active supplier who is willing to help you through the setup. With FTP trading partners - the setup is not standard so what works for one partner - may be totally wrong for another.
KRKA01
Basic Member
Basic Member
Posts:255

--
15 Apr 2010 07:01 AM Accepted Answer
implicit SSL normaly use port 990. Are you sure that you should use implicit SSL and not explicit? Take a look at this link for more info: http://help.globalscape.com/help/se...cit_SS.htm // Krister
James Sullivan
New Member
New Member
Posts:4

--
15 Apr 2010 01:30 PM Accepted Answer
FTP with SSL is a new protocol to the vendor to whom I need to upload files (they prefer and push SSH for file transfers). They admitted yesterday that they had setup initially with a self-signed server SSL certificate. That means their self-signed FTP server SSL certificate is not signed by Verisign, or Thawte - root authorities that are already imported into our iSeries DCM, and if it was a Verisign/Thawte certificate, their server would have be recognized. They were supposed to put in a certificate signed by Godaddy. That means importing Godaddy's root authority certificate into our iSeries' DCM, and trying the connection again. So my guess is that code "-11" has something to do with an invalid or not trusted certificate. Still, I have been unable to find the IBM documentation for FTP return codes. Anybody know where that documentation is located?
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16387
Avatar

--
15 Apr 2010 02:50 PM Accepted Answer
-11 means SSL_ERROR_BAD_MESSAGE which means that they received a message that was "badly formatted" -- in other words, it didn't recognize the format of the SSL data it received. Most likely, this does NOT relate to the self-signed certificate. When I've seen 'bad message' types of errors, it was usually because someone accidentally connected to a "regular" port rather than an ssl port. the plain-text data wasn't seen as valid XML data, so it was considered a "bad message." And that fits your scenario perfectly, since it appears you are connecting to port 21 (regular FTP) via SSL. To make that work properly, you either need to use SECCNN(*SSL) (which connects as plain FTP, but tries to negotiate an upgrade to SSL) or you need to connect to port 990 (which is for implicit SSL)
James Sullivan
New Member
New Member
Posts:4

--
15 Apr 2010 02:54 PM Accepted Answer
Scott, thanks for the clarification. Where are these return codes documented?
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16387
Avatar

--
15 Apr 2010 04:02 PM Accepted Answer
When I want to see what -11 means, I look in the include files that IBM provides for programmers who are writing SSL apps. In this case, you'd need to have the "System Openness Includes" licpgm installed, and then you'd look in the QSYSINC library in a file named H, member named QSOSSL you'd find this: (This is just an excerpt, there are many more than I'm including here)

/*********************************************************************/
/* Macros for return code from SSL functions                         */
/*********************************************************************/
                                                                       
#define SSL_ERROR_NO_CIPHERS                    -1                     
#define SSL_ERROR_NO_CERTIFICATE                -2                     
#define SSL_ERROR_BAD_CERTIFICATE               -4                     
#define SSL_ERROR_UNSUPPORTED_CERTIFICATE_TYPE  -6                     
#define SSL_ERROR_IO                            -10                    
#define SSL_ERROR_BAD_MESSAGE                   -11                    
#define SSL_ERROR_BAD_MAC                       -12                    
#define SSL_ERROR_UNSUPPORTED                   -13                    
#define SSL_ERROR_BAD_CERT_SIG                  -14                    
#define SSL_ERROR_BAD_CERT                      -15                    
#define SSL_ERROR_BAD_PEER                      -16                    
Because this is C code, and I'm an RPG programmer, I converted this stuff to RPG *years* ago. If you find RPG code easier to read, you might like to look at my RPG code which is here: http://www.scottklement.com/rpg/cop....rpgle.txt At any rate, that tells you that -11 means SSL_ERROR_BAD_MESSAGE. Now that you know that, you can look at the docs for the SSL APIs. Keep in mind that I've been writing/supporting/teaching SSL applications for nearly a decade. Based on that experience, it was pretty clear from your description that the error was occurring during SSL handshaking. Here's the API that FTP calls for SSL handshaking: http://publib.boulder.ibm.com/infoc...lhands.htm Near the bottom of the page, you'll see a list of all of the errors, and a brief description of each one. If you didn't know the proper API, you could always search the information center for SSL_ERROR_BAD_MESSAGE and see what the possibilities are. The rest of the info/advice I gave you came from my experience supporting this stuff, rather than any documentation.
James Sullivan
New Member
New Member
Posts:4

--
15 Apr 2010 04:55 PM Accepted Answer
Now I am getting a "-23" error, which is "SSL_ERROR_NOT_TRUSTED_ROOT...". The site must have installed their new certificate, issued by Godaddy.com (an authority not yet imported into our DCM; this is starting to make better sense now).
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16387
Avatar

--
15 Apr 2010 05:23 PM Accepted Answer
Yes... that error means that it doesn't trust the CA who signed their certificate. The way you establish that trust is to install GoDaddy's CA certificate into your DCM. Incidentally, you could've used the same method to make it work with a self-signed certificate (install the CA of the self-signed cert into the DCM)
You are not authorized to post a reply.

Acceptable Use Policy