Sorry, I meant to say when the client sends its certificate, firefox in this case, it has a key of type ECDSA. How does a key of this type work when the cipher selected is of type RSA?
Suman > On Mar 1, 2017, at 1:33 AM, Matt Caswell <m...@openssl.org> wrote: > > > > On 01/03/17 05:55, Suman Paul wrote: >> I have been looking at WebRTC DTLS handshake and don’t understand the >> logic of how it works. >> >> My Firefox client has support for both RSA and ECDSA ciphers while my >> DTLS server only supports DHE-RSA-AES128-SHA and has a RSA key. I see >> that Firefox sends a ECDSA key during client hello. What ends up >> happening is that DHE-RSA-AES128-SHA is selected. I would have >> expected the negotiation to fail due to there being no common >> ciphers. >> >> I also verified this behavior using the OpenSSL s_server and s_client >> utilities. Seems to me that as long as s_server has a cert and key of >> the type of cipher I enforce with ‘-cipher’ option the negotiation >> succeeds irrespective of the type of key the s_client (provided that >> cipher is also supported by the client). > > Your terminology is slightly confusing. No keys are sent in the > ClientHello at all. You should see a list of all the ciphersuites that > the client supports being sent in the ClientHello and then the server > should respond with a ServerHello which picks a ciphersuite from that list. > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > <https://mta.openssl.org/mailman/listinfo/openssl-users>
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
