STARTTLS verify=NO but openssl s_client says OK

[Hans Mayer]

dear all

i am running 2 mail gateways with self compiled sendmail Version 8.14.7 on Solaris 11 successfully. sendmail was compiled with ssl-library and STARTTLS and OpenSSL 1.0.0j coming from Oracle.

watching the debug file of syslog i find a lot of entries with STARTTLS=server
most of the entries have a verify=OK
for example all mails from google respectively gmail.com
but some of them have a verify=NO
when i run an openssl command manually I get "Verify return code: 0 (ok)"
any ideas why sendmail cannot verify some of the connections correctly ?


this is essential part of the m4-macro-file for the mailgateway:

define(`confCACERT_PATH', `/etc/openssl/certs')dnl
define(`confCACERT', `/etc/certs/CA/TERENA_SSL_CA.pem')dnl
define(`confSERVER_CERT', `/etc/mail/cert/cert.iiasa.ac.at.pem')dnl
define(`confSERVER_KEY', `/etc/mail/cert/smtp.key')dnl
define(`confCLIENT_CERT', `/etc/mail/cert/cert.iiasa.ac.at.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/cert/smtp.key')dnl

this is for example one syslog entry:

Jul 16 15:50:07 jump2 sendmail[22869]: [ID 702911 mail.info] STARTTLS=server, relay=smtp1.Stanford.EDU [171.67.219.81], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256


this is the openssl result:

openssl s_client -connect smtp1.Stanford.EDU:25 -state -verify 10 -starttls smtp -CApath /etc/openssl/certs -key /etc/mail/cert/smtp.pem -cert /etc/mail/cert/cert.iiasa.ac.at.pem -CAfile /etc/mail/cert/chain-TERENA_SSL_CA.pem
verify depth is 10
CONNECTED(00000007)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = US, O = Internet2, OU = InCommon, CN = InCommon Server CA
verify return:1
depth=0 C = US, postalCode = 94305, ST = CA, L = Stanford, street = 450 Serra Mall, O = Stanford University, OU = IT Services, CN = smtp.stanford.edu
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/C=US/postalCode=94305/ST=CA/L=Stanford/street=450 Serra Mall/O=Stanford University/OU=IT Services/CN=smtp.stanford.edu
i:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA
1 s:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFSjCCBDKgAwIBAgIQJs/XXwAVy8fZjIJxIfMllzANBgkqhkiG9w0BAQUFADBR
MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNv
bW1vbjEbMBkGA1UEAxMSSW5Db21tb24gU2VydmVyIENBMB4XDTEyMDMyMzAwMDAw
MFoXDTE1MDMyMzIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMQ4wDAYDVQQREwU5NDMw
NTELMAkGA1UECBMCQ0ExETAPBgNVBAcTCFN0YW5mb3JkMRcwFQYDVQQJEw40NTAg
U2VycmEgTWFsbDEcMBoGA1UEChMTU3RhbmZvcmQgVW5pdmVyc2l0eTEUMBIGA1UE
CxMLSVQgU2VydmljZXMxGjAYBgNVBAMTEXNtdHAuc3RhbmZvcmQuZWR1MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv2LW5IktEF/840YAG2kDLgc3Q1iy
1WdxXoMmefdAZBNo5/jggDX6gIGY2XhOZAS82ReOwcOLE60LAv/6H0m7OvY+DgmM
rfJIJL2EWM5LzFwu3Z6RVRaxI6tFCCGad4P5wS+sKdDeVPJIEt0zVeTDP+/D7weQ
BSjRTzgIsYgl3+QzQLNNY1r3UQeENBBaMCJqQPf0QLyDG8cWl5ozgBQawDyD/wzd
Cto7MWMhG1R5WLWCgxehoGPSbEF1ahBITiguu+HlOUloDPiekkSVQBpIC+RY7vNE
YNjSpPLDry6UtBJfFDC/09n3rjPK0svt/J1trEEzyT7p5fKA3DbysmNQrQIDAQAB
o4IBxjCCAcIwHwYDVR0jBBgwFoAUSE9a+i9Kml7gUPNre1Wl3vW+NF0wHQYDVR0O
BBYEFFi7KbIV8ojSLVAkg6oktoTJXY2sMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB
Af8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBdBgNVHSAEVjBU
MFIGDCsGAQQBriMBBAMBATBCMEAGCCsGAQUFBwIBFjRodHRwczovL3d3dy5pbmNv
bW1vbi5vcmcvY2VydC9yZXBvc2l0b3J5L2Nwc19zc2wucGRmMD0GA1UdHwQ2MDQw
MqAwoC6GLGh0dHA6Ly9jcmwuaW5jb21tb24ub3JnL0luQ29tbW9uU2VydmVyQ0Eu
Y3JsMG8GCCsGAQUFBwEBBGMwYTA5BggrBgEFBQcwAoYtaHR0cDovL2NlcnQuaW5j
b21tb24ub3JnL0luQ29tbW9uU2VydmVyQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5pbmNvbW1vbi5vcmcwNAYDVR0RBC0wK4IRc210cC5zdGFuZm9yZC5l
ZHWCFnNtdHAtcm9hbS5zdGFuZm9yZC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAERG
cMOvuADoYmN9gABH0TotMaQ6rWC5RYRurMPSQqYvubY5nWJvDndOToTuNNKN1bH2
3ddMLJ4a7EtYBPhf1Da7RW/EawLFJ93sNaszLIdnwLtNBc/8HNebpZOeasOwfwLV
xPrmaD89bNBDWHSU0eMZuQrMWr8EwVelNGuLQ8nWN23y4dRIROAVrLqlEAoYKQSU
Rc6w9a9s6LKPTValQhoGkUfUU852zG88P16GUOrYGRzRHfEzhJjY9BNflqKNaXnG
iGy7pEhnm3cFkfMcSdZDYg01zg4vdXLx0krYxBK73780XQGsgx//NCrl+bKC4iDB
fUVrJ8B7I/vT9xAglRQ=
-----END CERTIFICATE-----
subject=/C=US/postalCode=94305/ST=CA/L=Stanford/street=450 Serra Mall/O=Stanford University/OU=IT Services/CN=smtp.stanford.edu
issuer=/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA
---
No client certificate CA names sent
---
SSL handshake has read 4712 bytes and written 339 bytes
---
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: B58978343F57558D0097218658F95BE355CC1291FA59A31D74EDFA391417C103
Session-ID-ctx:
Master-Key: A56B70D57B460C68EE1540EAD708DD88A100D2D233416AED0C6DF7AF71B4246133DBE4C4A86AD0DE702443A6B1A5B4E1
Key-Arg : None
PSK identity: None
PSK identity hint: None
TLS session ticket:
0000 - 23 38 42 e2 44 86 8a 8b-bb dc 42 bf 89 8a 92 07 #8B.D.....B.....
0010 - 1b a7 de 69 f1 dd e3 f9-6a 04 c9 ba 35 ac b5 90 ...i....j...5...
0020 - 1c 86 eb 69 a1 cc be f2-51 4d 89 b7 45 9e 9d d9 ...i....QM..E...
0030 - 94 82 33 57 4e f6 d7 d1-f7 f2 bc 7d 25 bb 80 48 ..3WN......}%..H
0040 - a2 38 98 f6 b7 3b 81 1d-50 f5 c8 2c fa 23 04 d4 .8...;..P..,.#..
0050 - 7c 31 ab da f3 ed f6 b9-38 5d e3 cf f5 07 c7 39 |1......8].....9
0060 - 98 2a 67 6e 7b ba 04 1b-bd 02 92 21 4e ec ae c5 .*gn{......!N...
0070 - 04 1c 89 c7 e3 4a 08 42-8b 07 26 3a 07 17 83 bf .....J.B..&:....
0080 - 6e 19 97 c9 d1 ae f0 9c-bd fb 07 9d 88 c6 f8 c7 n...............
0090 - 16 b2 f8 53 d9 f5 c2 d4-5a 65 69 cb 73 ff 95 35 ...S....Zei.s..5

Start Time: 1373985726
Timeout : 300 (sec)
Verify return code: 0 (ok)


the file /etc/certs/CA/TERENA_SSL_CA.pem is the same as /etc/mail/cert/chain-TERENA_SSL_CA.pem

i did setup wireshark to decode SSL packets. i can only see those traffic with verify=YES. other i cannot read.
but all of them are delivered successfully.

any help would be nice.


kind regards from vienna
hans

--

[Claus Aßmann]

Hans Mayer wrote:

> but some of them have a verify=NO
> when i run an openssl command manually I get "Verify return code: 0 (ok)"

> Jul 16 15:50:07 jump2 sendmail[22869]: [ID 702911 mail.info] STARTTLS=server, relay=smtp1.Stanford.EDU

^^^^^^^^^^^^^^^

> [171.67.219.81], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256

op.* says:

NO no cert presented.

> openssl s_client -connect smtp1.Stanford.EDU:25 -state -verify 10 -starttls smtp -CApath /etc/openssl/certs -key

^^^^^^^^

Your test is not relevant -- you can't compare a client connection with
a server connection.


Ask the postmaster of Stanford to set up a client cert...

[Hans Mayer]

dear Claus

many thanks for your answer.
it's nice to see that you are still here in this news group over so many years.

> NO no cert presented.

yes, i know. but this means all of them are bad configured, isn't it ?
and these are not only some few. these are several hundreds per day. standford was just one example.
and i know not to mix up server and client. does it make sense to make different configurations for sending and receiving. but this is only hypothetical, it's not my primary question. thanks for committing what i already assumed.

there are also some few entries with
STARTTLS=server, verify=FAIL

so far i have seen almost all these remote server are sending spam over a self signed certificate. some few have an expired certificate.
is there a way to reject such e-mails ?
all my tries with "access.db" ended with the situation, that my mail-gateway tried to ask for a password. a exception of this rejects must be possible too.


schoene gruesse aus wien
hans

--