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 DnsCacheClear method to Http and Socket. This method clears the Chilkat-wide (in-memory) DNS cache.
  • Fixed a minor issue with writing AES encrypted Zips — the CRC written to the local file header and central directory record within the zip format was the correct CRC, but it is preferred to write a 0. This caused no actual problem, but it now conforms to what is preferred for AES encrypted zip archives.
  • Fixed a problem with the HTTP SyncrhonousRequest method where the request body of the HttpRequest object was being sent when the HttpRequest.HttpVerb equals GET or HEAD. Normally, one would not set the HttpRequest body, but this was discovered when an HttpRequest object instance was re-used after a previous POST request.

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 now included in the list, and will be used if the server chooses.

Also, a minor problem was fixed in Chilkat HTTP. If a server responds with no Content-Length header, then there was a chance that Chilkat would not return the full response. This does not apply to “chunked” responses — only to non-chunked responses that are lacking the Content-Length header — which is a rare occurrence (and it is poor practice for an HTTP response to omit the Content-Length).

Finally, a minor and rarely encountered ASN.1 problem was fixed. (ASN.1 code is internal to Chilkat and has to do with implementations for PKCS, PFX, etc.

(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 been set, and the Chilkat SSL/TLS handshake implementation will send a 0-length client-side certificate, which is the correct response for servers that request a client-side cert but don’t actually require it.

If the certificate object passed to SetSslClientCert is a pre-installed certificate on the Windows operating system, then make sure it was installed from the PFX such that the private key is exportable.  Chilkat’s SSL/TLS handshake code needs access to the client-side private key when a client-side cert is required.


An SSL/TLS connection failed and the LastErrorText contains “SEC_E_INTERNAL_ERROR”, such as in the error text below:

(See cause solution below)

    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.
    Failed to receive on the TCP socket
    connectionClosed: 0
    timedOut: 0
    Error reading data from server in handshake loop
    Setting scRet = SEC_E_INTERNAL_ERROR
    Error performing handshake

Cause #1:
This is caused when the server-side expect an SSL 3.0 initial packet and cannot handle an SSL 2.0 initial packet. Normally, when a client and server connect and begin the SSL/TLS handshake, the SSL 2.0 packet is the first one sent. It allows the client and server to negotiate and agree upon protocols starting from SSL 2.0 and up (SSL 2.0, SSL 3.0, TLS 1.0, etc.) Normally, the most secure protocol is used and SSL 2.0 is never actually used (unless there is some very very old legacy server that only supports SSL 2.0).

In some cases, the server does not expect the 1st packet to be SSL 2.0 formatted. One such case is the following OpenSSL command:

OpenSSL> s_server -accept 443 -Verify 5 -ssl3 -cert c:\certs\server.pem

Solution #1:

Set the SslProtocol property equal to the string “SSL 3.0”. For example:

socket.SslProtocol = "SSL 3.0";

This applies to all components capable of using SSL/TLS connections: FTP2, HTTP, Socket, IMAP, MailMan, etc.

Cause #2
The server requires the client to provide a certificate for authentication, but none was provided.

Solution #2
Load a Chilkat certificate object with the appropriate client-side certificate (there are many ways of doing this..) and then set the clients-side certificate by calling the SetSslClientCert method. This method exists on all Chilkat objects that use SSL/TLS connections (FTP2, HTTP, Socket, IMAP, MailMan, etc.)

Important: It’s entirely possible that your application might need to apply both solutions.

Client-Side SSL/TLS Authentication

This blog post is here to clarify a very common misunderstanding. The various Chilkat components that provide SSL/TLS support also provide an option that allows a client-side digital certificate to be used with the secure connection. A certificate identifies you to the server. In 99% of cases you do not need a client certificate. It is usually not necessary for the server-side of the SSL connection to identify you by means of a digital certificate. For example, when you are purchasing something online at Amazon.com, there are two important things regarding the connection: (1) you know you are really talking to Amazon.com (i.e. the server’s SSL certificate is verifiable) and (2) the connection is secure. Amazon.com does not require you to have a client-side certificate to communicate over SSL. If it did, then anybody wishing to do anything over SSL on the Internet would need to first purchase a digital certificate from a company such as Verisign, Thawte, Comodo, etc., be verified by that certificate authority, and then renew the certificate every year. Sites usually require you to login with a username/password, and this is what verifies your identity. Login/password identification applies to HTTP, FTP, POP3, SMTP, IMAP, etc., all of which have SSL support in Chilkat. It’s the login that provides client-side identification. Therefore, the SSL client certificate is usually never needed. (In fact, the login usually occurs over a secure SSL/TLS connection.)

The one place where a client-side certificate is required is this: When the client-side certificate takes the place of a login/password. This option is sometimes seen w/ high-security FTP servers involving financial transactions.

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 mail.chilkatsoft.com 25

220 mail.chilkatsoft.com ESMTP MailEnable Service, Version: 0-1.85- ready at 05/30/08 08:04:19

or this:

> telnet smtp.gmail.com 465

The response is non-printable binary data...

If however, you telnet to port 465 and get a human-readable response, then the SMTP server is not expecting an implicit SSL/TLS connection. Most likely, it’s expecting the connection to be converted to TLS via the STARTTLS command.

For example:

> telnet smtpx17.msoutlookonline.net 465

220 smtpx17.msoutlookonline.net Microsoft ESMTP MAIL Service ready at Fri, 30 May 2008 05:09:46 -0700

In terms of using Chilkat MailMan, three properties are involved: SmtpPort, SmtpSsl, StartTLS.

If the SMTP server expects an implicit SSL/TLS connection on the port, set SmtpSsl = true, and StartTLS = false.

If the SMTP server expects a non-SSL connection to be converted to a TLS connection, set SmtpSsl = false, but set StartTLS = true.

The SmtpPort, of course, should be set to the correct port value…