Error with new IBM mainframe cerificate

Question

I am using edtFTPj/PRO to send files to an IBM mainframe. We have a new certificate that was issued by the mainframe and it appears to be a good certificate. The new certificate looks very much like the one we are using successfully in production.

I am getting the following error and I am looking for direction on how to fix it.

com.enterprisedt.cryptix.CryptixException: PKCS#5: Invalid number of padding bytes


My full screen shot is below:

[sv-wm-d@appedxdv1 IntegrationServer]$ java com.egateway.MF.wmPush2MF_new /app/data/sv-wm-d/test/roy "'PG17678.TEST.EDI.INB.DASR.MAP.EDIX.TEST'" SYSA-FTP.SDGE.COM QEDIXFTP A /app/dv/webMethods82/IntegrationServer/QEDIXFTP.CERT4South.pem P
Setting SSL debugging to :all
CLIENT KEY FILENAME /app/dv/webMethods82/IntegrationServer/QEDIXFTP.CERT4South.pem
Creating FTPS (explicit) client
host=SYSA-FTP.SDGE.COM
username=QEDIXFTP
serverCertFilename=/app/dv/webMethods82/IntegrationServer/QEDIXFTP.CERT4South.pem
clientKeyFilename=/app/dv/webMethods82/IntegrationServer/QEDIXFTP.CERT4South.pem
clientKeyPassword=QEDIXFTP
action, code=P
action, append=false
absolutePath=/app/data/sv-wm-d/test/roy
com.enterprisedt.cryptix.CryptixException: PKCS#5: Invalid number of padding bytes
at com.enterprisedt.cryptix.provider.padding.PKCS5.engineUnpad(PKCS5.java:129)
at xjava.security.PaddingScheme.unpad(PaddingScheme.java:325)
at xjava.security.Cipher.a(Cipher.java:1468)
at xjava.security.Cipher.crypt(Cipher.java:1156)
at xjava.security.Cipher.crypt(Cipher.java:1116)
at com.enterprisedt.net.puretls.crypto.a.a(PEMData.java:139)
at com.enterprisedt.net.puretls.crypto.EAYEncryptedPrivateKey.createPrivateKey(EAYEncryptedPrivateKey.java:59)
at com.enterprisedt.net.puretls.SSLContext.loadEAYKeyFile(SSLContext.java:287)
at com.enterprisedt.net.puretls.SSLContext.loadEAYKeyFile(SSLContext.java:239)
at com.enterprisedt.net.ftp.ssl.SSLFTPClient.loadClientCertificate(SSLFTPClient.java:1243)
at com.egateway.MF.wmPush2MF_new.main(wmPush2MF_new.java:116)
com.enterprisedt.cryptix.CryptixException: PKCS#5: Invalid number of padding bytes
at com.enterprisedt.cryptix.provider.padding.PKCS5.engineUnpad(PKCS5.java:129)
at xjava.security.PaddingScheme.unpad(PaddingScheme.java:325)
at xjava.security.Cipher.a(Cipher.java:1468)
at xjava.security.Cipher.crypt(Cipher.java:1156)
at xjava.security.Cipher.crypt(Cipher.java:1116)
at com.enterprisedt.net.puretls.crypto.a.a(PEMData.java:139)
at com.enterprisedt.net.puretls.crypto.EAYEncryptedPrivateKey.createPrivateKey(EAYEncryptedPrivateKey.java:59)
at com.enterprisedt.net.puretls.SSLContext.loadEAYKeyFile(SSLContext.java:287)
at com.enterprisedt.net.puretls.SSLContext.loadEAYKeyFile(SSLContext.java:239)
at com.enterprisedt.net.ftp.ssl.SSLFTPClient.loadClientCertificate(SSLFTPClient.java:1243)
at com.egateway.MF.wmPush2MF_new.main(wmPush2MF_new.java:116)

Answer 1

I'm not sure why you are using the same certificate file for both the client and the server certificate. Could you please explain what you are trying to do?

Answer 2

I am trying to setup a TLS file transfer from our Linux server to an IBM mainframe. We have a working setup between our AIX server and the same IBM mainframe. The mainframe provided a PKCS12 file (Binary format that had a client certificate, a server CA signed certificate and a private key all in one file). We used opensll to convert this PKCS12 format into a PEM format. Please note this is exactly what we did for the working setup we have on AIX. The conversion to PEM worked as expected.

So we are using the same certificate file for both the client and the server certificate in our working setup between AIX and the mainframe. We have been using this setup using edtFTPj/PRO for the past 5 years successfully. I want to use the same approach of using a certificate file for both the client and the server certificate for the new Linux to mainframe setup. The certificate we are tyring to use for Linux to the mainframe is a new certificate and it is not the same certificate we are using for the AIX to mainframe transfers.

I have searched on Google for an explanation of the error message "com.enterprisedt.cryptix.CryptixException: PKCS#5: Invalid number of padding bytes" but have not found any useful information. I am asking for vendor support (EDT) to provide a solution or a direction on how to correct the issue I am having.

Please let me know if you require any other information.

Answer 3

The error appears to happen at ftp = new SSLFTPClient();

package com.egateway.MF;


import java.io.File;

import com.enterprisedt.net.ftp.FTPException;
import com.enterprisedt.net.ftp.FTPClientInterface;
import com.enterprisedt.net.ftp.FTPConnectMode;
import com.enterprisedt.net.ftp.FTPTransferType;
import com.enterprisedt.net.ftp.ssl.SSLFTPClient;
import com.enterprisedt.net.ftp.ssl.SSLFTPStandardValidator;
import com.enterprisedt.util.debug.Level;
import com.enterprisedt.util.debug.Logger;
import java.io.*;
import java.util.*;
import java.net.*;
import java.text.*;


public class wmPush2MF_new {

    final static String debug   = "all"; 
   
    public static void main(String[] args) {
        System.out.println("Setting SSL debugging to :" + debug);
        System.setProperty("javax.net.debug", debug);
        String password = "NotUsed";
        Logger log = Logger.getLogger(wmPush2MF_new.class);
        try {
         SSLFTPClient ftp = null;
         // path to files
         String absolutePath = "";
         File sourceDirectory = new File(args[0]); // [0] directory
         
         // filename
         String filename = args[1];
         
         // client key arg 0
         String clientKeyFilename=args[5];         // [7] client cert file
         System.out.println("CLIENT KEY FILENAME " + clientKeyFilename );
         String clientKeyPassword=args[3];         // [3] user id
         String serverCertFilename=args[5];        // [5] server cert file
         String username=args[3];                  // [3] user id
         String host=args[2];                      // [2] remote host name
         System.out.println("Creating FTPS (explicit) client");
         System.out.println("host=" +host);
         System.out.println("username=" +username);
         System.out.println("serverCertFilename=" +serverCertFilename);
         System.out.println("clientKeyFilename=" +clientKeyFilename);
         System.out.println("clientKeyPassword=" +clientKeyPassword);
         
         
         if (!sourceDirectory.exists()) {
            System.out.println("Directory name was not found.");
               System.exit(8);
         }
         
         //action
         boolean append=false;
         long fsize;
         
         if (args[6].toUpperCase().equals("A")) {
            append=true;
         }
         System.out.println("action, code=" +args[6]);    // [6] action
         System.out.println("action, append=" +append);
         
         // check if certs exist
         File serverCertFile = new File(serverCertFilename);
         if (!serverCertFile.exists()) {
            System.out.println("Server Cert File " +serverCertFilename +" specified in the .tab file does not exist.");
            System.exit(10);
         }
         
         File clientKeyFile = new File(clientKeyFilename);
         if (!clientKeyFile.exists()) {
               System.out.println("Client Key File " +clientKeyFilename +" specified in the .tab file does not exist.");
            System.exit(11);
         }
         
         absolutePath = sourceDirectory.getAbsolutePath();
         System.out.println("absolutePath=" + absolutePath);   
                
         //create client        
         ftp = new SSLFTPClient();
            // disable standard SSL closure
            log.info("Setting configuration flags");
            ftp.setConfigFlags(SSLFTPClient.ConfigFlags.DISABLE_SSL_CLOSURE);
            // NOTE: The DISABLE_SSL_CLOSURE flag is included in this example
            // for the sake of compatibility with as wide a range of servers as
            // possible. If possible it should be avoided as it opens the
            // possibility of truncation attacks (i.e. attacks where data is
            // compromised through premature disconnection).
            
            // set remote host
         log.info("Setting remote host");
         ftp.setRemoteHost(host);

         // load root certificates/server certificate
            log.info("Loading server certificate from " + serverCertFilename);
            ftp.getRootCertificateStore().importPEMFile(serverCertFilename);

         // Disable host-name checking (only recommended when testing)
            log.info("Disable host-name checking (only recommended when testing)");
            ftp.setCustomValidator(new SSLFTPStandardValidator(false));
 
   &nb

Answer 4

I would try removing the server certificate from the file that is loaded by loadClientCertificate.

Answer 5

have issues using the FileManager plug in for "Windows" type users.

When I login I'm redirected to my home virtual folder via the standard listing templates, and all my subfolders work correctly, however I'm not redirected automatically to the /FileManager/ plugin.

If I manually try to enter the the the /FileManager/ plugin path I get the following error: