In the specification for TLS 1.2, it says the following:

If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a hash/signature
algorithm pair that appears in that extension.

However, when I tried the following command in OpenSSL (As a server) it runs without any issue:

openssl s_server -accept 443 -cert ecdsa-cert.crt -key ecdsa-key.key -debug -msg -state -HTTP -cipher ECDHE-RSA-AES128-SHA

Then, I run another command for client:

openssl s_client -connect -debug -cipher ECDHE-RSA-AES128-SHA

It can't proceeed any further on the server console, it says "no shared cipher". However, when I used wireshark and inspect the ClientHello.signature_algorithms, it did indeed has ECDSA pair in it. So I'm wondering is it me that misinterpret the specification?

3 Answers 3


The ECDHE-RSA-AES128-SHA cipher suite means that the key exchange will use a dynamically generate ECDH key pair, that the server will sign with its own RSA private key. The server's certificate will thus contain a RSA public key, regardless of how that certificate was signed by its CA.

I suppose that the certificate you use contains an EC key pair, thus not compatible with the ECDHE-RSA-AES128-SHA cipher suite. It is kinda dumb from the server to start up at all with the provided options, since, in effect, it supports no cipher suite at all. But software is known to be dumb (at times).

So while the client is perfectly able to understand ECDSA signatures (and states as such in its signature_algorithms extension), the list of supported cipher suites that you configured prevents it from accepting any ServerKeyExchange message which contains anything else than an ECDH public key signed with RSA.

Also, the signature_algorithms extension is only partially related to this. With this extension, the client may announce the signature algorithms that it supports, and this is meant to help the server select an appropriate certificate chain, and algorithms for messages that need to be signed. If the client says "RSA only", then the server should strive to use only RSA signatures, both for what it signs itself (e.g. ServerKeyExchange message) and for the certificate chains is sends (all CA certificates should be RSA based).

That's, in practice, wishful thinking. Most servers have only one certificate, and that's the one they will send, regardless of the signature_algorithms extension. And most clients will adapt: if the client really supports RSA signatures, then it will process the RSA signatures on certificates and on TLS messages. This is the normal behaviour in the absence of the signature_algorithms extension.

The real usage of this extension is not to limit possible signature algorithms -- these are constrained by both the cipher suite and the kind of certificate that the server actually owns -- but to help the server choose hash functions to be used with signature algorithms. When the client says: "I support RSA with SHA-256", it is really telling to the server "if you must use RSA signatures, then you can do it with SHA-256 as support hash function, I know how to handle it".


I'd be curious if the ecdsa.crt that you are using on the server has a key pair that is prepared to handle RSA. As I remember, not only must the client and server agree on the signature and/or hash algorithms, but the server must have a certificate and key pair that is relevant to that algorithm.

My thought is that the name of your certificate references "DSA" an alternate key pair type to "RSA" - so while you've set up the server to allow ECDHE-RSA-AES128-SHA you haven't given it a key pair that it can use for making a ECDHE-RSA-AES128-SHA response.

I'll admit that "no shared cipher" isn't an intuitive leap to this path of thinking, but my experience with OpenSSL is that intuitive error messages aren't likely.


You are using ECC with ecdsa-cert.crt, so you should specify command option -cipher ECDHE-ECDSA-AES128-SHA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.