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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
