On Sun, Dec 11, 2016 at 08:54:08PM +0100, Kurt Roeckx wrote: > > > The defaults openssl sets now might not make sense for smtp in > > > general, but they should actually be good. > > > > While I agree to e.g. md5 being not appropriate anymore, I would > > still like to be able to receive mails from those sites despite > > of using weak security. > > You can add @SECLEVEL=0 in the ciphers string. I did not know this feature yet, thanks! Useful as an easy testcase. (Note to self: Re-reading man pages once in a while helps) > > > > Agreed. Unfortunately the other end of the connection is beyong > > my control. > > You indicated that this was when receiving. That means either > you're sending your certificates, or you've set up client > authentication and both sides send certificates. I would say my sendmail sends a certificate in server mode, as it has one given in the config. > > But the only case I could find when that error message is > generated is when you try to send your own certificates to the > other party. Which is somewhat counterintuitive to me, but my experiments confirm that so far. > The error message is about the signature algorithm that the CA > uses. It's only the server that is sending the certificates in > normal cases. Indeed. My confusion mainly comes from that sendmail chokes on its own certificate check (from libssl) during the TLS handshake when receiving mails. > > > My sendmail works to send mail to all parties (except a few friends > > running sendmail from debian testing as well), there the MTA plays the > > client role and presents a certificate. > > So you've set up client authentication with them? No, no special arragement with them. > > > With sendmail specifially, STARTTLS even (used to) works without > > any certificates (and hence no trust) at all, just for transport > > encryption. > > So sendmail does support anonymous ciphers? Yes. Actually, it does so by default. Only when you configure certificates, it starts using them. > > > > > I will try getting another certificate, though. > > They have confusing names. It's called "root", but it's really an > intermediate that is the problem. The selfsignature on the root > certificate doesn't matter. CACert has has "Class3 root" as intermediate, and a "CA root" as a root certificate. In this case, it is the md5-signature on the "Class3" intermediate certificate that triggers the effect. Now for my actions and progress: I installed new certificates without md5-signature along the chain. At least, the test at https://dane.sys4.de now succeeds again. I will watch my logs for one more day to see if the "ca md too weak" message appears again. If not, I would consider it as solved. Even in that case, IMHO it would be an idea to mark this bug as "won't fix", or even to leave a line in the NEWS.debian, just in case this version ever hits stable, as a hint for other CACert users (or someone with md5-signatures) out there. Bye, Joerg
Attachment:
signature.asc
Description: PGP signature