[ Bcc'd to a contact Microsoft, who should be able to help get the
issue addressed on that end at some point. The problem is a TLS
stack at outlook.com that is poorly suited to opportunistic TLS.
However, it is possible to work around this in Postfix, mostly
by sticking to default settings, plus some care in one's own
certificate chain configuration. ]
On Fri, Jul 24, 2015 at 10:20:49AM +0200, Moritz Schmitt wrote:
> My server serving.schmi.tt is experiencing problems with mails coming in
> from outlook.com. This is what I found in my logs (many times actually):
>
> -----
> Jul 24 09:28:16 serving postfix/smtpd[4577]: initializing the server-side TLS
> engine
> Jul 24 09:28:16 serving postfix/smtpd[4577]: connect from
> mail-am1on0067.outbound.protection.outlook.com[157.56.112.67]
> Jul 24 09:28:16 serving postfix/smtpd[4577]: setting up TLS connection from
> mail-am1on0067.outbound.protection.outlook.com[157.56.112.67]
> Jul 24 09:28:16 serving postfix/smtpd[4577]:
> mail-am1on0067.outbound.protection.outlook.com[157.56.112.67]: TLS cipher
> list "aNULL:-aNULL:ALL:+RC4:@STRENGTH"
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:before/accept
> initialization
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:SSLv3 read client
> hello A
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:SSLv3 write server
> hello A
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:SSLv3 write
> certificate A
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:SSLv3 write key
> exchange A
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:SSLv3 write server
> done A
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:SSLv3 flush data
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept:failed in SSLv3 read
> client certificate A
> Jul 24 09:28:16 serving postfix/smtpd[4577]: SSL_accept error from
> mail-am1on0067.outbound.protection.outlook.com[157.56.112.67]: lost connection
This is closely related to:
http://thread.gmane.org/gmane.mail.postfix.user/250484/focus=250556
your server certificate chain is:
$ (sleep 2; printf "quit\r\n") |
openssl s_client -showcerts -starttls smtp -connect serving.schmi.tt:25
2>&1 |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs -noout
subject=/CN=serving.schmi.tt
issuer=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing
Authority/emailAddress=supp...@cacert.org
subject=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing
Authority/emailAddress=supp...@cacert.org
issuer=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing
Authority/emailAddress=supp...@cacert.org
The root CA in question is using MD5 (this SHOULD be harmless) for
its self-signature, but the outlook.com SMTP servers are allergic
to MD5, even in self-signed root certificates. To avoid the
interoperability problem:
1. Set:
# Don't let OpenSSL augment your server certificate chain
# with "missing" certificates. Instead, place just the required
# certificates in smtpd_tls_cert_file.
#
smtpd_tls_CAfile =
smtpd_tls_CApath =
smtpd_tls_ask_ccert = no
# With the problem solved, a less verbose log level is saner!
smtpd_tls_loglevel = 1
2. The certificate chain file configured via smtpd_tls_cert_file
MUST NOT contain the "CA Cert" root certificate, delete
that certificate from the file it if is present. The
file should have only the content below my signature
(the leaf certificate, and not the issuing root
certificate).
Once that's done, Microsoft will be able to send you email.
--
Viktor.
subject: /CN=serving.schmi.tt
issuer: /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing
Authority/emailAddress=supp...@cacert.org
-----BEGIN CERTIFICATE-----
MIIGDjCCA/agAwIBAgIDEMoeMA0GCSqGSIb3DQEBCwUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y
dEBjYWNlcnQub3JnMB4XDTE1MDYxNTIyNTEyNloXDTE1MTIxMjIyNTEyNlowGzEZ
MBcGA1UEAxMQc2VydmluZy5zY2htaS50dDCCAiIwDQYJKoZIhvcNAQEBBQADggIP
ADCCAgoCggIBANCPqzOryaou6zRD4ZyT5sNLnxG+h/1FH9N9oXpWYu2k3rig17X1
+CWJzOJf15Cc1/xKF6ebzPxHj6Hvfbj7eqWGsyG/uk3V00y8+PSrOXXj7bwoGsji
NZWuZ2fmRpVaZYJdXV8NyQMCBQN7s2R1rZXsEGk7eRvnB7gpq8O+Ds4CwYKqae46
kdjS1MtBVYgTneSyWiUFCU3eedr3A6qROM5DgoYFLE1iy1XSRO6GQiSeDRUWB+Ue
J3U+gLY5y162GPlXB0Fz9XZ/Fdwz0/ffQiXCXLxuscEWVhsNDa9ZUx0SEZM58aOb
7ofaMtUh4VoCBhImBfExl+VPU6VdSYs1ZAaz+OkgzlNjv6Nin2WzSA75+1VSjAX8
iM6fNNi061nnRZqfR1FN0Ke7FEQ9GNpYDTdtjXsTg1Ln26XKvU0H7PH/IMCgm/xZ
rU92ZyHY0kiS0iWzx90fWlUEopJ1X5DvUHQRXqNk1fU6WZq9riacKESXFhvpDe7V
WvD7grPwXF3RE5DysFRCD4q2r3RQju+qusekUADioYBPZdROhZAXwYcGrCmwLtiB
6ASrS7AVOOP20VB+x+OEhSihsi9gNcQ28uGWtuVywfVLnI83A52m/EoJuJ7Gr5fh
u76GMWFkTCkqEk+l3ggJ530lNVvEv1sPTERqPU5ehB5S3lzPbQ8HVKVFAgMBAAGj
gfwwgfkwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCA6gwNAYDVR0lBC0wKwYI
KwYBBQUHAwIGCCsGAQUFBwMBBglghkgBhvhCBAEGCisGAQQBgjcKAwMwMwYIKwYB
BQUHAQEEJzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5jYWNlcnQub3JnLzAx
BgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2VydC5vcmcvcmV2b2tlLmNy
bDA7BgNVHREENDAyghBzZXJ2aW5nLnNjaG1pLnR0oB4GCCsGAQUFBwgFoBIMEHNl
cnZpbmcuc2NobWkudHQwDQYJKoZIhvcNAQELBQADggIBAH4pPAsKGGQqvzx0A4Wq
3g0AgAL/Ee5/sa3lKvsS1c6FRZz6da/W2FVN03hVqF8yaTG2aGCDPyMcIllhCVE7
7JdJ3gwpcHVgykbPD2UPdFbnI3STYxEOzk7d20TR3Fb1mYaHHi8M0E1KcfrOiJVo
J0Brpz+J2Q8vz1Ctcf/jSA4p0jPZyiugihHozEzba7tbFUwd6XwUxNX2t/oRzyke
nNKYAe3TzreNBCqWg80dyyAn56cKRX4YVVg12RjN0Jy0PBB0qLJr7dxcKdZlaFJM
4NWbXevE6+NZCz758M06hICQCAOpZcY9RypNc8Pvm6ZpetgdbLervS1dehLv1U5V
nXZInyjt3Yd5rLOKqL5NbOq9kJNxvdv7KRwrfjjUSXx7UBpbhKrW4c8wRjVEKDXR
2PBZ8rnuF/RakURsty5xdJNW9DR3TWOqa5lz93MFXrwoJYRO7EPsYt85kLbnz4OS
gC37//VXY5HCaIyxhGFWXhVJxFMWxGWAyPE1mssXUQvhap3K2zom45IisISqvny4
sH1qHOd4jPqTG4JXERosvG8GJbFwjoqPwQSkis1epuCJTvUdikN1GoxCD8Q97De9
k6dGy9+CMebRXjEvVoUeKS2N20aOq++ZJnID1iuuSCcjSoflv12Eu6jlAk2OV5d1
J9UmCJxk4ehqFwS84x+/gD+e
-----END CERTIFICATE-----
