On Mon, May 04, 2015 at 08:59:10AM +0300, Birta Levente wrote:
> > Can you reproduce the problem by using "-CAfile $cafile" with
> > s_client(1)? I don't see how adding a trusted CA can break the
> > handshake if the CA is well formed.
> >
> > Please provide more information. Please attach a gzipped copy of
> > the CAfile after making sure putting it back restores the problem.
>
> Seems like the CAcert root certificate is not in the acceptable client
> certificate CA names at the remote server.
No, that's not the reason...
> Like you ask I attached the gzipped CA certificate
But now I finally have the required information. The CAcert root
certificate in question is (of course) self-signed, but with MD5
as its signature algorithm.
You had also (contrary to best practice advice) configured the use
of client certificates, and the SMTP server in question happens to
solicit client certificates (incidentally sends an embarrasingly
long list of acceptable root issuer DNs).
When you also configure the CAcert root as a CAfile, it is
automatically added your client certificate chain. However, the
server in question is allergic to MD5, and aborts the handshake
when it finds any certificates with MD5 in the chain. Even if they
are self-signed roots, and even though it had no reason to refuse
to talk to clients whose certificates fail to verify.
So we have a thicket of failures:
* You've set "smtp_tls_cert_file" non-empty, despite:
http://www.postfix.org/postconf.5.html#smtp_tls_cert_file
Do not configure client certificates unless you must present
client TLS certificates to one or more servers. Client
certificates are not usually needed, and can cause problems
in configurations that work well without them. The recommended
setting is to let the defaults stand...
* The CAcert root CA uses bleeding edge computationally
exorbitant 4096-bit RSA, but then mysteriously gets stingy
and self-signs with MD5, which is deprecated.
* The Microsoft server solicits client certificates on port
25, it should reserve such features for ports 587 and/or 465.
Interoperability is better without and no waste of bits sending
enourmous lists of issuer DNs.
* The Microsoft server uses a TLS library that is a poor fit
for opportunistic TLS. It is way too strict, despite the
fact that client authentication on port 25 is optional.
A client that is not authenticated should be able to
proceed just a client that presents no certificates
at all, or a client that uses cleartext.
Do follow the the documented advice and avoid needless configuration
of client certificates.
Do not use certificates issued by the exotic md5 CAcert root, it
has poor interoperability. They likely have a newer version now
that uses SHA2-256 or (more geek cred?) SHA2-512 instead.
--
Viktor.
P.S. I was able to reproduce the problem with posttls-finger and
my own freshly minted root CA that used MD5. Changing just the
signature algorithm of the root CA to SHA1 resolves the issue.
MD5:
$ posttls-finger -l may -F ca.pem -k ee.pem irs-ro.mail.eo.outlook.com:25
posttls-finger: Connected to irs-ro.mail.eo.outlook.com[213.199.154.87]:25
posttls-finger: < 220 DB3FFO11FD002.mail.protection.outlook.com Microsoft
ESMTP MAIL Service ready at Mon, 4 May 2015 07:16:56 +0000
posttls-finger: > EHLO amnesiac.example
posttls-finger: < 250-DB3FFO11FD002.mail.protection.outlook.com Hello
[192.0.2.1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-DSN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-BINARYMIME
posttls-finger: < 250 CHUNKING
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 SMTP server ready
posttls-finger: SSL_connect error to
irs-ro.mail.eo.outlook.com[213.199.154.87]:25: lost connection
SHA1:
$ posttls-finger -l may -F ca2.pem -k ee2.pem irs-ro.mail.eo.outlook.com:25
posttls-finger: Connected to irs-ro.mail.eo.outlook.com[213.199.154.23]:25
posttls-finger: < 220 AM1FFO11FD013.mail.protection.outlook.com Microsoft
ESMTP MAIL Service ready at Mon, 4 May 2015 07:43:03 +0000
posttls-finger: > EHLO amnesiac.example
posttls-finger: < 250-AM1FFO11FD013.mail.protection.outlook.com Hello
[192.0.2.1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-DSN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-BINARYMIME
posttls-finger: < 250 CHUNKING
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 SMTP server ready
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
subjectAltName: *.mail.eo.outlook.com
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
subjectAltName: *.mail.protection.outlook.com
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
subjectAltName: mail.protection.outlook.com
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
subjectAltName: outlook.com
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
subjectAltName: mail.messaging.microsoft.com
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25 CommonName
mail.protection.outlook.com
posttls-finger: irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
subject_CN=*.mail.eo.outlook.com, issuer_CN=MSIT Machine Auth CA 2,
fingerprint=3D:FA:EC:8A:81:0E:8B:F2:D8:1D:64:6E:D4:E1:1E:0F:FD:F6:FA:55,
pkey_fingerprint=19:00:DD:94:FA:DC:82:BF:CD:79:31:B1:8D:36:C8:99:CD:AA:B4:8F
posttls-finger: Untrusted TLS connection established to
irs-ro.mail.eo.outlook.com[213.199.154.23]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-SHA384 (256/256 bits)
posttls-finger: > EHLO amnesiac.example
posttls-finger: < 250-AM1FFO11FD013.mail.protection.outlook.com Hello
[192.0.2.1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-DSN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-AUTH LOGIN
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-BINARYMIME
posttls-finger: < 250 CHUNKING
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 Service closing transmission channel
