Archived Forum Post

Index of archived forum posts

Question:

SslAllowedCiphers options

May 06 '16 at 17:08

Looking at the documentation for the TCP socket component, I see a list for the available SslAllowedCiphers. It seems that SHA384 is the highest level available. We have a client that wants to use SHA512 for their certificates. What are our options? Is SHA1512 supported?


Answer

Yes, SHA-512 is supported. I'll make sure the documentation is updated.


Answer

It seems to work with v9.5.0.51, but with v9.5.0.56 we are receiving an error. The certificate that he is using is SHA512.

Failed to connect to 10.96.0.46
Reason: 100-Internal schannel error
(ChilkatLog:
Connect_Socket(218ms):
ChilkatVersion: 9.5.0.56
connectInner(202ms):
hostname: 10.96.0.46
port: 12480
tls: 1
maxWaitMs: 5000
socket2Connect(202ms):
connect2(202ms):
hostname: 10.96.0.46
port: 12480
ssl: 1
connectImplicitSsl(202ms):
Clearing TLS client certificates.
connectSocket:
domainOrIpAddress: 10.96.0.46
port: 12480
connectTimeoutMs: 5000
connect_ipv6_or_ipv4:
This is an IPV4 numeric address.
Domain to IP address resolution not needed.
connecting to IPV4 address...
ipAddress: 10.96.0.46
createSocket:
Setting SO_SNDBUF size
sendBufSize: 262144
Setting SO_RCVBUF size
recvBufSize: 4194304
--createSocket
connect:
Waiting for the connect to complete...
myIP: 10.96.0.46
myPort: 58814
socket connect successful.
--connect
--connect_ipv6_or_ipv4
--connectSocket
clientHandshake(202ms):
certChain:
subjectDN: O=Casey's General Store, CN=Internet Order
--certChain
cacheClientCerts:
Cached TLS client certificates.
certChain:
subjectDN: O=Casey's General Store, CN=Internet Order
--certChain
--cacheClientCerts
clientHandshake2(187ms):
readHandshakeMessages:
processHandshakeRecord:
processHandshakeMessage:
processServerHello:
negotiatedTlsVersion: TLS 1.2
negotiatedCipherSuite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
minAcceptableRsaKeySize: 1024
--processServerHello
--processHandshakeMessage
--processHandshakeRecord
--readHandshakeMessages
Sending client-side certificate(s)...
sendClientCertificates(16ms):
buildCertificatesMessage(16ms):
numCerts: 1
--buildCertificatesMessage
--sendClientCertificates
buildClientKeyExchange(16ms):
buildClientKeyExchangeECDHE(16ms):
verifyServerKeyExchange(16ms):
composeVerifyData:
Unsupported server key exchange hash algorithm
--composeVerifyData
--verifyServerKeyExchange
--buildClientKeyExchangeECDHE
--buildClientKeyExchange
Failed to build ClientKeyExchange
sendFatalAlert(46ms):
Turning on TCP_NODELAY.
passiveClose(15ms):
Passive socket closing complete.
--passiveClose
--sendFatalAlert
--clientHandshake2
--clientHandshake
Client handshake failed. (3)
--connectImplicitSsl
ConnectFailReason: 100
--connect2
--socket2Connect
Failed.
--connectInner
Failed.
--Connect_Socket
--ChilkatLog
)


Answer

This problem actually has nothing to do with the TLS cipher suites or the SslAllowedCipher property. (In other words, it's not a missing cipher suite.)

It has to do with a server key exchange option in TLS 1.2. In the older version of Chilkat, TLS 1.2 was not implemented, and this option does not exist in the older versions of the TLS protocol (TLS 1.0, 1.1), and that's why the problem does not occur. You can work around the problem by setting the SslProtocol property to "TLS 1.1" or "TLS 1.0".

I did add support just now for the SHA512 server key exchange hash algorithm. I can provide a new build, but I need to know exactly what to provide (programming language, operating system, .NET version, Visual Studio Version, or whatever might apply)


Answer

This is the reason I recommend Chilkat to others! Great response on the rare occasion there is an issue.

We are currently using the 32 bit version of ChilkatDotNet4.dll with VB.net 2013


Answer

Please try this new build:

32-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet4-9.5.0-win32.zip

64-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet4-9.5.0-x64.zip

I added the support for SHA512, which was simply to add a section of internal code that is identical to the case for SHA384. I haven't tested it yet -- I'll leave it to you since you can do that quickly.