On 04/05/2015 10:45, Viktor Dukhovni wrote:
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.
Thank you !
--
Levi
