Archived Forum Post

Index of archived forum posts

Question:

chilkat socket certificate verification error

May 02 '13 at 05:12

I try to estabilsh a SSL session with a client certificate and try to validate both sides: the client verifies the servers cert and vice versa. This works well on my DEV machine (signatureVerified: 1). If I run the code on a different machine, the verification of the server cert on the clients side fails (signatureVerified: 0).

Any ideas why this could be? Are there any additional requirements for chilkat Socket that I'm not aware of?

Thanks in advance! T.


Answer

It's difficult to tell what might be wrong without a code snippet and the contents of the LastErrorText property (as they are immediately after the failed call), so if you can supply those,then that might help.

Since the problem is with certificate handling, the Socket might re-use code from the ChilkatCert library. Maybe you could try deploying that library on the failing machine?


Answer

It's difficult to tell what might be wrong without a code snippet and the contents of the LastErrorText property (as they are immediately after the failed call), so if you can supply those,then that might help.

I don't think there's much more to see than I already provided. But you asked for it, here your are:

Win 7:

ChilkatLog:
  SignatureVerified:
    DllDate: Dec 12 2012
    UnlockPrefix: MyNamexSocket
    Username: HOSTNAMEWIN7:MyUser
    Architecture: Little Endian; 32-bit
    Language: .NET 4.0
    VerboseLogging: 1
    Initializing certificate validity info.....
    calling CertCreateCertificateChainEngine...
    CryptoAPI certificate chain engine created.
    CryptoAPI certificate chain built.
    CryptoAPI certificate chain processing completed.
    signatureVerified: 1
  --SignatureVerified
--ChilkatLog

Win XP:

ChilkatLog:
  SignatureVerified:
    DllDate: Dec 12 2012
    UnlockPrefix: MyNamexSocket
    Username: HOSTNAMEXP:MyUser
    Architecture: Little Endian; 32-bit
    Language: .NET 4.0
    VerboseLogging: 1
    Initializing certificate validity info.....
    calling CertCreateCertificateChainEngine...
    signatureVerified: 0
  --SignatureVerified
--ChilkatLog

Both outputs were created with the very same binary. Here's the source:

If Not SSL.SetSslClientCertPem(My.Application.Info.DirectoryPath & "\certificate.crt", "") Then
        MsgBox("error setting cert")
        Return False
     End If

     If Not SSL.Connect("192.168.1.2", 12345, True, 10000) Then
        MsgBox("error connecting to server")
        Return False
     End If

     Receive()

     Dim serverCert As Chilkat.Cert
     serverCert = SSL.GetSslServerCert
     serverCert.VerboseLogging = True

     Dim success = serverCert.SignatureVerified
     Console.WriteLine(serverCert.LastErrorText)

Since the problem is with certificate handling, the Socket might re-use code from the ChilkatCert library. Maybe you could try deploying that library on the failing machine?

I may be wrong, but I understood that chilkatCert is included in chilkatSocket. However, I can successfully create a cert object and read properties like subject and dates and such from my client cert.


Answer

I narrowed down the problem a bit. I can get successful cert verification on more than one Win7x64 and Win7x86 machine. Also I can get successful cert verification on WinXP with VB6 code using the chilkatSocket and chilkatCert Active-X controls. Using the .NET chilkatSocket on XP SP3 x86 still fails. This can be reproduced easily.

This is the VB.NET code which works fine on Win7 and fails on XP:

Class MainWindow 
Private Const ChilkatSocketLicense As String = "MyNamexSocket123456"
Private SSL As New Chilkat.Socket
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click
  Dim cert As Chilkat.Cert
  Dim Success As Boolean
  Success = SSL.UnlockComponent(ChilkatSocketLicense)
  MsgBox("Unlock: " & Success)
  Success = SSL.SetSslClientCertPem(My.Application.Info.DirectoryPath & "\certificate.crt", "")
  MsgBox("SetClientCert: " & Success)
  Success = SSL.Connect("192.168.1.2", 12345, True, 10000)
  MsgBox("Connect: " & Success)
  cert = SSL.GetSslServerCert()
  MsgBox("SignatureVerified: " & cert.SignatureVerified)
End Sub
End Class

This is the VB6 code:

Private Const ChilkatSocketLicense As String = "MyNamexSocket123456"
Private SSL As New ChilkatSocket
Private Sub Form_Load()
  Dim cert As ChilkatCert
  Dim Success As Long
  Success = SSL.UnlockComponent(ChilkatSocketLicense)
  Debug.Print Success
  Success = SSL.SetSslClientCertPem(App.Path & "\certificate.crt", "")
  Debug.Print Success
  Success = SSL.Connect("192.168.1.2", 12345, 1, 10000)
  Debug.Print Success
  Set cert = SSL.GetSslServerCert()
  Debug.Print cert.SignatureVerified
  End
End Sub

This works well on VB6 and I do get cert.SignatureVerified = 1. Just like it should be.

Summary:

I may be wrong but to me this sounds like a bug in the .NET4 assembly of chilkatSocket. I contacted support on Friday but didn't get any response. :-(

Blockquote


Answer

The underlying implementation is identical whether it's the ActiveX, .NET, C++ libs, etc. In other words, the only difference between the ActiveX and .NET is the thin outer layer that passes arguments to, and returns results from the underlying C++ implementation. If there is a bug in .NET and not the ActiveX, then the bug would be in this thin wrapper, and it's probably not the case here.

I can deduce from the LastErrorText's you previously posted that it is the call to the Microsoft Crypto API's CertCreateCertificateChainEngine function that is returning a failed status. (http://msdn.microsoft.com/en-us/library/windows/desktop/aa376032%28v=vs.85%29.aspx) Unfortunately, the Chilkat internals did not call Microsoft's GetLastError function to get more specific information about why it failed. I suspect it has to do with that particular machine, or maybe somehow related to permissions. At this very moment, it's not possible to produce a new build that can get this information. It might be possible in a few days.


Answer

I think I see the problem. If you examine the CERT_CHAIN_ENGINE_CONFIG structure, which is an argument to the Windows Platform SDK's CertCreateCertificateChainEngine function:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa377184%28v=vs.85%29.aspx

You'll find that three new members are added to Windows 7 and Windows Server 2008 R2. Effectively, Microsoft made a change that breaks existing code. I'll make a change to update this ASAP, but it'll take until tomorrow..