sendmail, cannot figure out TLS

I've configured TLS (I think) on two Linux hosts using sendmail. I got the certificates from I've verified the TLS using That site gives me a warning:

Cert NOT VALIDATED: self signed certificate in certificate chain  
So email is encrypted but the domain is not verified  

I'm not sure what that is about since I get the certs from CAcert and did not create a self-signed cert. Anyway, I get the following results:

check tls results
When I try sending an email from one of these computers to the other, I get the following in /var/log/maillog on the target computer. Phrases like "verify=NO" and "verify=FAIL" give me the impression that TLS is not working:

Oct  9 00:15:02 server sendmail[32137]: r994F26M032137: from=mfoley, size=1566, class=0, nrcpts=1, msgid=<>, relay=mfoley@localhost
Oct  9 00:15:02 server sm-mta[32139]: STARTTLS=server, relay=localhost [], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Oct  9 00:15:02 server sendmail[32137]: STARTTLS=client, relay=[], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256

Open in new window

I need to figure this out ASAP. Thanks
Who is Participating?
Daniel McAllisterConnect With a Mentor President, IT4SOHO, LLCCommented:
OK, it appears you have a misunderstanding of SSL & the PKI (Public Key Infrastructure) in general. Whole books are written about PKI, but I'll try to be brief & relevant.

A Digital Certificate is something that is used to electronically verify a document (or a connection). In the case of SSL and mail, the certificate is used to verify the identity of the server. However, in email, SSL is also used to encrypt the mail traffic for a modicum of security.

To prove your identity in the PKI, a Certificate comes with attached "signatures" (think of the letters of introduction one would carry up through the 20th Century to prove that you are who you claim to be). Those signatures are the "guarantee" that you are who/where you say you are, and there are a select "set" of these "guarantors" scattered around the Internet. To be "trusted", you have to have one of these guarantors sign your certificate.

When you install your mailserver software, most will automatically create a self-signed certificate (essentially, the only person who promises you are who you say you are is yourself).... and these are necessary for the server to startup at the onset.

However, if you plan to use SSL "for real", you are expected to purchase a "for real" SSL certificate (your registrar probably sells them, and there are plenty of other vendors -- including my own site -- that sell them too). These "for real" certificates are signed by the guarantors I mentioned above, and then replace the self-signed certificate you installed originally.

So - if all you're doing is encrypting mail traffic, using a self-signed certificate is adequate. Most mail servers don't require a trusted (signed) SSL certificate, they just want to encrypt the transaction for basic security when they can.

However, if you need identity proof (like on your IMAP or POP connections), then you'll need a "real" certificate.

I hope this explains things a little... I tried to stay high level enough that I'm sure some other expert will find some nuance I missed or that doesn't quite fit my analogies... but the gist is there... I hope you find it useful.

jmarkfoleyAuthor Commented:
more info: when I run

$ openssl s_client -connect -starttls smtp

I get:
depth=1 /O=Root CA/OU= Cert Signing Authority/
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate chain
 0 s:/
   i:/O=Root CA/OU= Cert Signing Authority/
 1 s:/O=Root CA/OU= Cert Signing Authority/
   i:/O=Root CA/OU= Cert Signing Authority/
issuer=/O=Root CA/OU= Cert Signing Authority/
Acceptable client certificate CA names
/O=Root CA/OU= Cert Signing Authority/
SSL handshake has read 4943 bytes and written 366 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 5472A6D43E6DB670C8F307F6371737A602F2573ABF42CD2EF951495F0EAE9607
    Master-Key: 32F9901D8059BC1B2332EC46F8ED86927C6B5E34EBA711707F372F42B1E7735E1B6304375BCAB27E3C8382F443442704
    Key-Arg   : None
    Start Time: 1381323452
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

Open in new window

I don't understand why I get the error "self signed certificate in certificate chain". I'd like to fix that if possible.
Jan SpringerCommented:
have you specified the correct certificate in your and rebuilt it?
jmarkfoleyAuthor Commented:
Thanks for the info. I do believe I have it working now. I had a few "issues". First, I had forgotten the "common name" I used to create the certificate signing request. The command:

openssl req -in cert.csr -noout -text

gave me that information. That was my main problem as I was trying to specify a different name with to create a renewed certificate. After creating the new key, the following command gives me information about the signing authority, validity period, common name, etc.

openssl x509 -text -in cert.pem

Finally, I kept getting a failure on verification of the client cert which I couldn't figure out. In the end, that was solved by adding the confCLIENT.. lines to my file:


I suppose this means that the server and client have the same cert, but it doesn't seem to give me any problem.

I found lots of good tips at
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.