Bug#847743: sendmail: STARTTLS server fails with "ca md too weak"
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
Reply to: