TLS "certificate and the given key do not match"

[Steve Madsen]

I've had TLS running just fine with a self-signed certificate for the last ten years. Last night it finally expired, and I thought I'd pay for a $9 Comodo PositiveSSL certificate from Namecheap. After installing it, I can't connect and authenticate in order to send email. The error is:

2013-07-08 08:48:30 TLS error on connection from xxx.yyy.com ([192.168.1.12]) [xxx.xxx.xxx.xxx] (cert/key setup: cert=/etc/ssl/2013.smtp.moonglade.com.crt+ca key=/etc/ssl/2013.smtp.moonglade.com.key): The certificate and the given key do not match.

As near as I can tell, they do match. Running these commands produces the same hash:

$ openssl x509 -noout -modulus -in 2013.smtp.moonglade.com.crt | openssl md5
$ openssl rsa -noout -modulus -in 2013.smtp.moonglade.com.key | openssl md5

Note that there are intermediate certificates in the crt+ca file, ordered as my cert -> intermediate cert -> CA cert.

Additional data points: I purchased two other certificates at the same time to replace other uses of the expired self-signed cert, and those are working fine in Dovecot and Apache. I swapped one of those in to Exim and received the same error. A PositiveSSL wildcard certificate on a different server and domain, but the same version of Exim, works fine.

This is Exim 4.72-6+squeeze3 (Debian 6). I haven't had an opportunity to upgrade to Wheezy yet. Is this a known problem fixed in 4.80?
--
Steve Madsen <***@moonglade.com>

[Graeme Fowler]

Post by Steve Madsen
2013-07-08 08:48:30 TLS error on connection from xxx.yyy.com ([192.168.1.12]) [xxx.xxx.xxx.xxx] (cert/key setup: cert=/etc/ssl/2013.smtp.moonglade.com.crt+ca key=/etc/ssl/2013.smtp.moonglade.com.key): The certificate and the given key do not match.

That comes from the GnuTLS handling code; I would surmise that the permissions on either the certificate or key are too strict and prevent Exim from reading it/them.

Graeme

[Steve Madsen]

Post by Graeme Fowler
That comes from the GnuTLS handling code; I would surmise that the permissions on either the certificate or key are too strict and prevent Exim from reading it/them.

I don't think that's the case here. The permissions were wrong at one time and the error was different. For both the self-signed (working) and issued (not working) certificate/key files, the key is 440 root:Debian-exim, the certificate 644 root:root.
--
Steve Madsen <***@moonglade.com>

[Steve Madsen]

Post by Graeme Fowler
That comes from the GnuTLS handling code; I would surmise that the permissions on either the certificate or key are too strict and prevent Exim from reading it/them.

For anyone that runs across this thread in the future, I have solved the problem and is it ever maddening.

GNU TLS was choking on the contents of the certificate file because pasting them from an email added an extra space at the end of each line. I removed the spaces and Exim is happily using the certificate and key.

Graeme, thanks for the push towards GNU TLS. There was just enough chatter about how GNU TLS is more strict than OpenSSL for me to ultimately discover the root cause.
--
Steve Madsen <***@moonglade.com>

[David Woodhouse]

Post by Steve Madsen
For anyone that runs across this thread in the future, I have solved
the problem and is it ever maddening.
GNU TLS was choking on the contents of the certificate file because
pasting them from an email added an extra space at the end of each
line. I removed the spaces and Exim is happily using the certificate
and key.
Graeme, thanks for the push towards GNU TLS. There was just enough
chatter about how GNU TLS is more strict than OpenSSL for me to
ultimately discover the root cause.

Have you reported this as a bug upstream to GnuTLS? If OpenSSL accepts
these certs then it would seem sensible for GnuTLS to do so.

If *not*, then you end up with GnuTLS being suboptimal as a replacement
for OpenSSL for projects like Exim, because it doesn't let us remain
backward-compatible with existing setups.

Although you could also work out where the extra space came from, and
ensure you file a bug for that too. Cutting and pasting from email
shouldn't corrupt the contents.

[Nikos Mavrogiannopoulos]

Post by David Woodhouse

Post by Steve Madsen
Graeme, thanks for the push towards GNU TLS. There was just enough
chatter about how GNU TLS is more strict than OpenSSL for me to
ultimately discover the root cause.

Have you reported this as a bug upstream to GnuTLS? If OpenSSL accepts
these certs then it would seem sensible for GnuTLS to do so.
If *not*, then you end up with GnuTLS being suboptimal as a replacement
for OpenSSL for projects like Exim, because it doesn't let us remain
backward-compatible with existing setups.

Hello,
I think that issue should be applicable to the 2.12.x series of
gnutls, not the 3.x which has quite several compatibility
improvements.

regards,
Nikos