Question:
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.
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?
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.
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
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.
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..