I might be wrong here, but I think I recall something about tls-verifies going awry when using anonymous connections. It's not totally uncommon for SMTP-servers to use this, as it is cheaper, in the form of consumed resources, and you more or less just want the encryption. In other words, try something different than google, and see what you get for resultes.
You can try something like this to verify that the certificate you are exposing actually validates as expected
Code:
$ openssl s_client -connect localhost:25 -starttls smtp -CApath /etc/ssl/certs
This should output a bunch of info..
Code:
[...]
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 1195CCEBCFF2538BF873529BD12023ACB021A5EBBAC8AF09EEAB236AB1BBE732
Session-ID-ctx:
Master-Key: 8A547A5E9653806B31EA8982E22184D9E0DFF40EB8A3E6D7AFA1848F9A6D359C0ADF0FD8392C8391DCA3F47D881C474C
Key-Arg : None
Start Time: 1330556960
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 DSN
QUIT
DONE
..but what is interesting here is the bottom part,
Verify return code: 0 (ok)
This tells us that the chain is correctly set up for out externally exposed SMTP-server.