Hi,
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 postmaster@hoti.hu
address.
This is how it looks
like from CLI:
openssl s_client -connect
195.70.35.118:25 -starttls smtp
CONNECTED(00000003)
verify error:num=18:self signed
certificate
verify return:1
verify return:1
---
Certificate chain
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIBsTCCARoCCQCFHU4iJ8cX3zANBgkqhkiG9w0BAQUFADAdMRswGQYDVQQDExJt
YWlsLWEubmV0Zm9ydW0uaHUwHhcNMDkwNzAxMjIyMjI0WhcNMTkwNjI5MjIyMjI0
WjAdMRswGQYDVQQDExJtYWlsLWEubmV0Zm9ydW0uaHUwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBALRsu1r3jkKxNkuEiHLRLt6zK5dXkWy+mv1OrZAF8ExiMLTb
rExi70sgRuH149DdiQ/v95V75JGxwWZo+J8uzPWCdoybNWbSSOMgItlMkX+y93EF
gIlXnvYxL14q6O+9AFj7Qte3PJW1v6ZYFqO5FyaJnGW/nHxK59bPyq2IwrPLAgMB
AAEwDQYJKoZIhvcNAQEFBQADgYEAHsqSt+9Qa1jyU5jL7IhOXvlLcumUvyuf5w3O
6o4T976hx1jiaQBM0wjIbI9yig+PB0crHOCkQHTcfOV+rJksQ9lEMOrjq2IWaZ/U
5UDAuUTdhmSmI0VWXv1n7lgjOU0iM0nFSChB4BBvdPA0qvI0Z+5QMcN16sJtMwQ7
Cox1wJI=
-----END 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
/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=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
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
038238157B5D6594A668AF9F40769393C542E30D7B62AEB5F0B2B600252C9724
Session-ID-ctx:
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.