login about faq

We are evaluating your product to do an FTP/SSL connection as the last tool we used never worked. Your component seems to offer a lot more potential esp with the verbose debugging.

I am loading a client side cert with the command:

Cert cert = cert.LoadByCommonName("OurCertCommentName");

The log says the cert is found but we see the following message:

Found cert in CurrentUser/ROOT createFromMsCert: msCertGetPrivateKey: No key provider info is available. Failed to get key provider info. --msCertGetPrivateKey --createFromMsCert --msFindByCommonName Success. --LoadByCommonName

Is this an error I need to be concerned about or only a warning that I can ignore?

Later the Ftp.Connect() says it succeeds although I see the same message in the FTP connection log.

Then I do an Ftp.PutFile() where I again see the same message in its log and then my "put" times out after 60 seconds with the following (abbreviated) errors:

Found cert in CurrentUser/ROOT createFromMsCert: msCertGetPrivateKey: No key provider info is available. Failed to get key provider info. --msCertGetPrivateKey --createFromMsCert --cacheClientCerts clientHandshake2: Timeout waiting to read socket or accept connection timeoutMs: 60000 Timed out waiting for incoming SSL/TLS messages. timeoutMs: 60000 Expected ServerHello but did not receive it. --clientHandshake2 --clientHandshake Client handshake failed. (1) connectionClosed: 0 --convertToTls --ConvertDataConnToTls ConvertToTls: Elapsed time: 60029 millisec Failed to convert data connection to TLS --convertDataConnToSsl --uploadFromDataSource --uploadFromLocalFile TotalTime: Elapsed time: 60685 millisec Failed.

asked Mar 10 '14 at 15:15

Courtney's gravatar image

Courtney
1111


It means the certificate was never installed with the associated private key. A certificate with private key will typically be installed from a .pfx / .p12 (PKCS12) file. (The .pfx and .p12 extensions are just different names for the exact same file format.) A .cer file contains only the certificate + public key (which is embedded within the X.509 certificate data), but it does not contain the private key.

You'll need to either re-import the certificate from a .pfx/.p12, or you may use the .pfx/.p12 directly from Chilkat without needing to involve the Microsoft registry-based certificate stores at all..

Finally, you only need an SSL/TLS certificate if the FTP server is requiring a client-side certificate for authentication purposes. This is usually only found in high-security applications, such as banking. Typically, FTP over SSL does not require a client-side certificate.

link

answered Mar 11 '14 at 08:56

chilkat's gravatar image

chilkat ♦♦
11.8k316358420

Thank you for your quick response. This is in fact for a high-profile banking institution so they do require a Client Side cert.

I tried two approaches to address the problem but neither have worked.

  1. I tried loading the cert and private key from files within code: I loaded the ".cer" file provided to us from the bank using the ChilKat Ftp2 LoadFromFile() method.

I then loaded our private key file using the PrivateKey LoadEncryptedPemFile() (using our password)

I then applied the private key to the cert using the Cert SetPrivateKey() method

And finally, I applied the cert to the FTP object using the SetSslClientCert() method.

At each step I logged and examined the LastErrorText and each step says it succeeded.

  1. The second approach I tried installing the cert (with private key) into windows: I used OpenSSL to combine our cert file (.cer) with our private key text file into a PFX file and then installed that PFX within Windows.

I used the Cert LoadByCommonName() method to load the cert

I applied the cert to the FTP object using the SetSslClientCert() method.

Again, at each step I logged and examined the LastErrorText and each step says it succeeded.

With either of the two approaches for loading the certificate, we are still seeing the error:

    Found cert in CurrentUser/ROOT
        createFromMsCert:
          msCertGetPrivateKey:
            No key provider info is available.
            Failed to get key provider info.
          --msCertGetPrivateKey
        --createFromMsCert
      --cacheClientCerts

The other key points to note about this scenario:

  1. We are using FTPS Explicit
  2. We are using Passive mode
  3. We do successfully connect to the remote FTP site and we see the SSL
  4. We do see FTP enter passive mode on one of the expected ports
  5. We are able to do a FTP GetTextDirListing which returns the expected data successfully
  6. We fail on a PUT (after it finds the cert) with the following: Found cert in CurrentUser/ROOT createFromMsCert: msCertGetPrivateKey: No key provider info is available. Failed to get key provider info. --msCertGetPrivateKey --createFromMsCert --cacheClientCerts clientHandshake2: Timeout waiting to read socket or accept connection timeoutMs: 60000 Timed out waiting for incoming SSL/TLS messages. timeoutMs: 60000 Expected ServerHello but did not receive it. --clientHandshake2 --clientHandshake Client handshake failed. (1)

Do you have any other suggestions?

If we were to purchase your software do you have any soft of technical support that might be able to help us solve this issue?

Thanks again

Courtney

link

answered Mar 11 '14 at 16:40

Courtney's gravatar image

Courtney
1111

You can ignore this. It turns out we got it working and the timeout was because my remote path for the PUT was incorrect!

(Mar 12 '14 at 13:46) Courtney
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×62
×56
×48
×24
×4

Asked: Mar 10 '14 at 15:15

Seen: 1,657 times

Last updated: Mar 12 '14 at 13:46

powered by OSQA