I hope this is the right place for that kind of question.
So actually I am trying to test the TLS implementation of some industrial device. I have to write my own TLS implementation for this, for which I am using the OpenSSL library and I also do testing via console commands, the version is 1.1.1f.
The device I test only supports the cipher suite tls_ecdhe_ecdsa_with_aes128_cbc_sha256 (0xc023).
As a preparation I want to test an OpenSSL client vs. an OpenSSL server and I am using the follwoing commands to set up both (the certificate has been generated before with OpenSSL as well):
openssl.exe s_server -accept 2 -cipher ECDHE-ECDSA-AES128-SHA256 -key cs_key.pem -cert cs_cert.pem -msg -state -debug -tlsextdebug -bugs
and
openssl.exe s_client -connect localhost:2 -tls1_2 -cipher ECDHE-ECDSA-AES128-SHA256 -msg -state -debug -tlsextdebug -bugs
The server aborts the TLS handshake with an alert message and the console output
11096:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl\statem\statem_srvr.c:2284:
shutting down SSL
This also happens when I use my real device as client.
My questions are:
- Why does the server say there was no shared cipher when I explicitely set up the server to support only that one cipher suite? I suppose it is supported by the OpenSSL implementation as otherwise the s_server call would fail.
- How can I make this work?
Addendum:
If I support all the ECDHE-ECDSA ciphers in the client hello by using
openssl.exe s_client -connect localhost:2 -tls1_2 -cipher ECDHE+ECDSA -msg -state -debug -tlsextdebug
the handshake fails in the same way.
Solution:
In the meantime i stumbled over this and found out this issue is a matter of proper key generation. By applying the proposed solution in the linked thread I was able to get my example working.