Mailing List Message #100600
From: James Roman <>
Subject: Re: TLS problem with huge acceptable client certs
Date: Thu, 02 Sep 2010 13:34:29 -0400
To: Communigate Pro Mailing List <>
On 01/-10/-28163 02:59 PM, Tamas Levente wrote:
we are experiencing a problem that seems to be realted to a fact that CGP (5.3.8 and possibly all before that) only reads in 16k of cert on TLS negotiation. I attached the CGP log and the console openssl connection results, you can see CGP after read in 16k of data decides that the certificate is broken and wants to proceed with cleartext, but the remote side is still pushing the remaining part of the certificate hence the weird reply to our QUIT.
It should be easy to fix it, just read the cert to EOF or certsize , without size limit, or if you are affraid that it might get hacked, choose a little bigger buffer size, 64k-128k must do it. you can test it with address.

This is how it looks like from CLI:
openssl s_client -connect -starttls smtp
depth=0 CN =
verify error:num=18:self signed certificate
verify return:1
depth=0 CN =
verify return:1
Certificate chain
Server certificate
Acceptable client certificate CA names
/C=BR/O=ICP-Brasil/OU=Instituto Nacional de Tecnologia da Informacao - ITI/L=Brasilia/ST=DF/CN=Autoridade Certificadora Raiz Brasileira
/O=Root CA/OU= Cert Signing Authority/
/O=CAcert Inc./OU= Class 3 Root
/C=DE/ST=Hessen/L=Fulda/O=Debconf/CN=Debconf CA/
/C=US/O=AOL Time Warner Inc./OU=America Online Inc./CN=AOL Time Warner Root Certification Authority 1
/C=US/O=AOL Time Warner Inc./OU=America Online Inc./CN=AOL Time Warner Root Certification Authority 2
/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Class 1 CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Public CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Qualified CA Root
/C=NL/O=DigiNotar/CN=DigiNotar Root CA/
/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority
/C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certificate Authority
SSL handshake has read 21021 bytes and written 486 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 038238157B5D6594A668AF9F40769393C542E30D7B62AEB5F0B2B600252C9724
Master-Key: BD5A789FF0D8F81C552EE73DDC480AA4EEA311F707254CD605291167E10F21B6B551D9E6979C40814251767985B0461E
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1282744555
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
250 HELP
I might be wrong but this looks like a misconfiguration on the client, the server or both. (I can't exactly tell whether the CGP log session is between two mail servers or a mail client and your mail server.) I've seen similar behavior from servers when they use self-signed or ActiveDirectory hosted certificates. The problem is that the receiving mail server does not trust the certificate path provided by the sending mail server (or the client does not trust the mail server cert). When this occurs, the entire list of trusted CA certificates is sent. This is not normal behavior, and would be indicative of a TLS failure.

Your options in this case are:
1) Make sure the other server's CA signing certificate (or certificates in a chain) are installed as trusted signing certificates. (It is not enough to trust the mail server's sending certificate (as a peer). If you are using a self-signed certificate, the server certificate must also be trusted as a signing authority.)
2) Don't relay mail using TLS. This IS the example of why you just don't blindly REQUIRE TLS sessions when delivering mail between servers, unless they are part of the same organization (which implies they use the same signing CA, it requires two-way cooperation/configuration.
3) Install a certificate signed by a trusted CA.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster