[gnutls-help] Fwd: TLS1.2 fail, Could not negotiate a supported cipher suite,

[Peter Gervai]

Hello,

Regardless of the numerous advice to recompile exim to use openssl I'm
rather here. :-) I kind of avoided the problem but it's not
prefect.... later on that .

A mailserver running Exim on Debian stable (wheezy) acts unfriendly
towards TLS users, and spews too much "Could not negotiate a supported
cipher suite." errors.

Exim is 4.80-7 (exim4-daemon-heavy) and libgnutls26 is 2.12.20-7. The
problem is that this is the same as many other servers running happily
and without significant problems.

Using annoyingly much
gnutls-cli mail.* -p 25 -s -d 5  --no-ca-verification --priority
NORMAL:-VERS-TLS-ALL:+VERS-TLS1.1
kind of commands, varying the priority it turned out that TLS1.2 will
not work no matter what I try to do, even restricting it to the one
known working RSA_AES-128-CBC_SHA1
(NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2:-CIPHER-ALL:-MAC-ALL:-KX-ALL:+RSA:+AES-128-CBC:+SHA1:-SIGN-ALL:+SIGN-RSA-SHA1:%COMPAT)
or by trying various compatibility or breakage flags.

|<2>| ASSERT: gnutls_constate.c:581
|<4>| REC[0x2453120]: Allocating epoch #1
|<3>| HSK[0x2453120]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x2453120]: CLIENT HELLO was queued [47 bytes]
|<4>| REC[0x2453120]: Preparing Packet Handshake(22) with length: 47
and target length: 47
|<4>| REC[0x2453120]: Sent Packet[1] Handshake(22) in epoch 0 and length: 52
|<2>| ASSERT: gnutls_buffers.c:1018
|<4>| REC[0x2453120]: SSL 3.2 Handshake packet received. Epoch 0, length: 81
|<4>| REC[0x2453120]: Expected Packet Handshake(22)
|<4>| REC[0x2453120]: Received Packet Handshake(22) with length: 81
|<4>| REC[0x2453120]: Decrypted Packet[0] Handshake(22) with length: 81
|<3>| HSK[0x2453120]: SERVER HELLO (2) was received. Length 77[77],
frag offset 0, frag length: 77, sequence: 0
|<3>| HSK[0x2453120]: Server's version: 3.2
|<2>| ASSERT: gnutls_handshake.c:1721
|<2>| ASSERT: gnutls_handshake.c:2225
|<2>| ASSERT: gnutls_handshake.c:1442
|<2>| ASSERT: gnutls_handshake.c:2701
*** Fatal error: A record packet with illegal version was received.
|<4>| REC: Sending Alert[2|70] - Error in protocol version
|<4>| REC[0x2453120]: Preparing Packet Alert(21) with length: 2 and
target length: 2
|<4>| REC[0x2453120]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed

And the other side logs no suitable cipher suite.

Pulling the server back to TLS1.1 makes it kind of work but some
clients are not happy:
"A TLS fatal alert has been received."
which probably means "I want to talk TLS1.2 dammit".

The cert is using an internal CA but it's the same CA issuing the
certs for the other servers working happily. Still, there seem to be
little difference apart from the key/cert, the ca-certificates.conf
(whcih is supposed not to be used anyway since we don't vrify the
certs), or possibly something seemingly unrelated libs around the
server.

[...]  time passes [...]

In my experience one of the best things of asking help is that I have
to gather all the info in one place, and try to make it coherent. In
the process sometimes it just happens that I happen to find the
solution. I guess a web-searchable documentation is still due, so here
you all are, googling this.

The problem is the "same old" problem happens from time to time to
gnutls installs: certs generated by openssl. These certs may work, or
may not work, or somewhere inbetween generating various horrible side
effects, including the one you have observed above. These otherwise
perfectly work with anything which is not gnutls. ;-)

The solution was generating the cert with certtool (which is a pain in
the ass since openssl is smart enough to realise that I want it to ask
for the password but use the rest of the template while certtool is
either full-interactive or non-interactive, never inbetween), and it
works.

The solution was partly helped by
gnutls_serv --debug 5 --port 1234  --x509keyfile server.key
--x509certfile server.crt
but only partially since it's almost impossible to figure out what the
bloody message means:

Could not find an appropriate certificate: Insufficient credentials
for that request.

I guess now (after knowing the solution) that it would like to convey
the message that the certificate does not allow the method I try to
use it for, or that it is missing the required extension (for example
"Key Encipherment"), or that the extension is not understood by
gnutls. If I knew that I would have suspected problems with the
certificate. But the message is so cryptic that not even
google-my-friend was able to figure it out. (Partially helped by
gnutls documentation which says not a word more explaining the
problem.)

But being able to reliably regenerate the problem resulted fast
trials, and among them was a newly generated key/cert pair (not
working), then suspecting old family feuds trying gnutls tools instead
of openssl. And bingo.

Since then it seems to work without any errors whatsoever.

Thanks for watching. ;-)

Peter