On Sun, Dec 11, 2016 at 08:13:08PM +0100, Joerg Dorchain wrote: > On Sun, Dec 11, 2016 at 12:57:06PM +0100, Kurt Roeckx wrote: > > > > > > > Most reproduceable way I found by now is the DANE validator at > > > > https://dane.sys4.de/, which leave a log entry e.g.: > > > > Dec 11 11:04:54 Redstar sm-mta[18223]: STARTTLS=server, error: accept > > > > failed=-1, reason=ca md too weak, SSL_error=1, errno=0, retry=-1, > > > > relay=dane.sys4.de [IPv6:2001:1578:400:111:0:0:3:1] > > > > > > > > Other affected parties include e.g. amazon. > > > > With SMTP you really have no security unless you're using DANE. > > 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. > > Note that that check is only in case of a CA certificate. So a > > CA is in use, and they really should use a proper signature > > algorithm in that case. > > 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. 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. > > I think that the CA is on your end. If it's the same as on your > > website, the intermedia "CAcert Class 3 Root" is with MD5, while > > the end certificate is with SHA512. I suggest you replace the CA > > certs with newer ones. > > Sorry to say, I see things differently. It is about mails I > receive, which means my sendmail MTA plays the TLS server role, > and to my understanding, the complaint is about the signature > algorithm of the sending side. 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. > Otherwise I would get no mail at > all anymore, and not only problems from some parties. There might be several reasons why you still do get mails: - It never tried to encrypt the mail in the first place - It failed with encryption and it had no policy to require encryption so it retried without encryption. - It's using an anonymous cipher (ADH, AECDH) which does not involve any authentication and so doesn't use certificates. At least postfix supports that and does that when it's not using DANE. I have no idea if sendmail support that. > 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? > 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? > > CAcert will probably have newer ones. > > As a side note, CAcert is working on a new root cert, but no timeline > yet. > > 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. > > It seems the smtp servers don't want to talk to me, so I couldn't > > check that. So my problem was that you have a very high pre-greet delay, and openssl's s_client doesn't have an option for that end directly sends the EHLO. > I can trigger a check via https://dane.sys4.de/ reliably. In case > it helps, I enclosed to packet capture from a ESMTP > conversation. It shows the other side sending a ClientHello and you just closing the connection before you send the ServerHello. No certificates where send. Kurt
