0

Two days ago I updated openssl 1.0.1f to 1.0.1g. Everything seemed fine. But after a while an error popped up in the sendmail log:

OpenSSL 1.0.1g fails

Apr 10 10:13:45 mail sendmail[17568]: STARTTLS=client, error: connect failed=-1, reason=tlsv1 alert decode error, SSL_error=1, errno=0, retry=-1

Apr 10 10:13:45 mail sendmail[17568]: STARTTLS=client: 17568:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762:

Apr 10 10:13:45 mail sendmail[17568]: ruleset=tls_server, arg1=SOFTWARE, relay=mail.example.com, reject=403 4.7.0 TLS handshake failed.

The mail has not been delivered.

OpenSSL 1.0.1f works

Then I downgraded to 1.0.1f and the mail has been sent with:

Apr 10 10:17:31 mail sendmail[31809]: STARTTLS=client, relay=mail.example.com., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256

It seems that there is another difference between the two openssl versions than only the heartbleed bugfix.

Version comparison

Then I tried on both OpenSSL versions:

openssl s_client -starttls smtp -connect mail.example.com:25

Output of OpenSSL version 1.0.1g:

CONNECTED(00000003)

140370040759952:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762:


no peer certificate available


No client certificate CA names sent


SSL handshake has read 131 bytes and written 552 bytes


New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE


Output of OpenSSL version 1.0.1f (parts):

CONNECTED(00000003)

depth=0 C = US, ST = California, L = San Bruno, O = "IronPort Systems, Inc.", CN = IronPort Appliance Demo Certificate

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 C = US, ST = California, L = San Bruno, O = "IronPort Systems, Inc.", CN = IronPort Appliance Demo Certificate

verify error:num=21:unable to verify the first certificate

verify return:1


Certificate chain

0 s:/C=US/ST=California/L=San Bruno/O=IronPort Systems, Inc./CN=IronPort Appliance Demo Certificate

i:/C=US/ST=California/L=San Bruno/O=IronPort Systems, Inc./CN=IronPort Appliance Demo Certificate


Server certificate

---snipped---


No client certificate CA names sent


SSL handshake has read 1771 bytes and written 552 bytes


New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol  : TLSv1

Cipher    : DHE-RSA-AES256-SHA

---Snipped---

What now?

I interpret, that the presented certificate from mail.example.com is one not meant for productive usage...

Is there a way how I can handle such certificates with openssl 1.0.1g? mail.example.com is one of several communication-partners which I have problems with.

Thanks Teddy

  • 1
    Exactly how did you upgrade openssl? How was it originally installed? What sort of hardware and OS is this? – Michael Hampton Apr 10 '14 at 15:42
2

Circumstances forced me to compile openssl 1.0.1g from sources and I encountered behavior identical to that reported above. This is under Fedora 18 on a 64-bit Intel. Like the original poster reports, most mail went out OK but one mail destination suffered the same TLS handshake failures.

The openssl change log (brief CL here, detailed CL here) showed only three changes from 1.0.1f to 1.0.1g:

  • a security update
  • another security update
  • Add TLS padding extension workaround for broken servers.

Speculating that third change was responsible for the problem I commented out one line in ssl/tls1.h that appears to control presence of this "TLS padding" modification, like so:

/* #define TLSEXT_TYPE_padding 21 */

Compiled again, put the library .so files in place, restarted sendmail, and out went the queued mail with no problems. I hope I haven't opened up new issues as a result.

1

Yes, there are two solutions:

  • Use SSLv3
  • compile without

    /* #define TLSEXT_TYPE_padding 21 */
    

Reference here.

  • So in order to work around one broken middlebox (F5) they found out that another middlebox was broken (IronPort). Hate those broken middleboxes :( – Steffen Ullrich Apr 16 '14 at 6:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.