Chilkat does not use OpenSSL and is not affected by the Heartbleed bug.
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.