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.

SSL/TLS Error – SEC_E_INTERNAL_ERROR

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.
    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
    Failed.

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.

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…