RedTrust KSP with TLS 1.2 Client Certificate

The EVOLIUM REDTRUST CSP is not capable of signing a non-hash. In other words, it’s not possible to do TLS 1.2 with client certificates with the RedTrust KSP. This is a common problem in CSP/KSP implementations.  They assume that everything to be signed is a hash, such as SHA1, SHA256, SHA384, SHA512, and require the hash algorithm to be specified […]

Failed to read beginning of SSL/TLS record – can be caused by External Firewall

If the problem is with Office365, such as with SendEmail to, port 587, then updating to Chilkat v9.5.0.93 or later will solve the problem. For example, if you see the following, then update to v9.5.0.93 or later. … ensureSmtpSession: ensureSmtpConnection: smtpParams: SmtpHost: SmtpPort: 587 SmtpUsername: … SmtpSsl: 0 StartTLS: 1 –smtpParams smtpConnect: smtpHostname: smtpPort: 587 connectionIsReady: SMTP […]

HMRC Ending Support for TLS versions 1.0 and 1.1

Question: We use your system to submit to VAT returns to HMRC using Making Tax Digital. Does this TLS stuff mean anything to you?  The only reference I can see to it in the code is setting a TLS Boolean to true, which doesn’t specify a version? (This is a portion of the notice from HMRC) “Your application should now […]

Ftp2 AuthTls, AuthSsl, and Ssl Properties Clarified

Question: We are about using Chilkat C++ library for an FTPS connection.  I read on online documentation that there is method CkFtp2::put_AuthTls which allows setting TLS connection. Some questions about client behavior according to this method: if we don’t call this method, transmission is in clear text? Is it equivalent to CkFtp2::put_AuthTls(false)? If  we call this method with parameter true […]

TLS Connection Disrupted after Handshake Completes

The following error can be caused by firewall restrictions. I do not know the specifics of the firewall restrictions, but the TLS connection completes successfully in the prior call to Chilkat.Rest.Connect().    In other words, the TLS handshake completes successfully and then the firewall closes (or blocks) the connection.   ChilkatLog: FullRequestFormUrlEncoded: DllDate: Jul 24 2019 ChilkatVersion: UnlockPrefix: Start […]

v9.5.0.38 Micro Update: TrustedRoots Object/Class Added, and other various fixes

This new version includes the following updates/fixes: Added the TrustedRoots class to allow for programss to globally specify a specific set of trusted root CA certificates for PKCS7 certificate signature verification and for SSL/TLS server certificate trust. Added the RequireSslCertVerify property to Http, IMAP, Socket, and MHT. Added the CrcFile and CrcBytes methods to the Crypt2 API. Added a new […]

v9.5.0.34 Micro Update: SSL/TLS Perfect Forward Secrecy, Minor HTTP and ASN.1 Fixes

The internal Chilkat SSL/TLS implementation now supports the TLS_DHE_RSA_WITH_AES_256_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suites. These allow for perfect forward secrecy. Note: This is implemented on the client-side for all protocols using SSL/TLS. The SSL/TLS client provides the server with a list of algorithms it supports, and it is the server that decides which is to be used. These new algorithms are […]

(FTPS) 530 No client certificate presented.

If this FTP server response is seen in the LastErrorText, it means that the SSL/TLS connection requires a client-side certificate with private key.   Prior to connecting, the client-side certificate should be specified by calling the SetSslClientCert, or SetSslClientCertPfx.  Make sure to check the return value of these methods for success/failure.  If the SetSslClientCert* method fails, then no client-side certificate has […]


Problem: An SSL/TLS connection failed and the LastErrorText contains “SEC_E_INTERNAL_ERROR”, such as in the error text below: (See cause solution below) ChilkatLog: Connect: DllDate: Dec 4 2009 UnlockPrefix: **** Username: **** Component: .NET 2.0 objectId: 1 hostname: *.*.*.* port: 443 ssl: 1 maxWaitMs: 20000 windowsAccount: **** ClientCertDN: **** protocol: default An existing connection was forcibly closed by the remote host. […]

Port 465 is Normally the Implicit SSL SMTP Port, but not always…

If you open a DOS prompt and telnet to an SMTP server (typically port 25 for non-SSL, port 465 for SSL), you should get a human-readable printable-text “HELLO” message from the non-SSL port, but binary SSL-handshake protocol gobbly-gook from an implicit SSL port. For example: > telnet 25 220 ESMTP MailEnable Service, Version: 0-1.85- ready at 05/30/08 08:04:19 […]