The last bit of information makes my life a little hard. In DTLS-SRTP usage, the DTLS server must present it's server fingerprint in SDP before the client support ciphersuites are known, how can a DTLS server support clients that may support only RSA or ECDSA?
Suman > On Mar 1, 2017, at 4:01 PM, Matt Caswell <m...@openssl.org> wrote: > > > > On 01/03/17 23:52, Suman Paul wrote: >> What I have seen in my trials with s_server and s_client is that if run >> s_server with an ECDSA cert/key and I specify one RSA and one ECDSA >> cipher with the -cipher option, then s_client can only connect to it >> using the ECDSA cipher. I have been unsuccessful in connecting to this >> server using a RSA cipher. RSA cipher fail shows up at the s_server as >> >> 140480482967256:error:1408A0C1:SSL routines:ssl3_get_client_hello:no >> shared cipher:s3_srvr.c:1417: >> >> Your thoughts on this? > > Yes, this is expected. The ciphersuite selection is limited by the > available server certificate(s). That is different to the client > certificate which is independent of the ciphersuite. > > Matt > > >> >> Suman >> >>> On Mar 1, 2017, at 1:51 AM, Matt Caswell <m...@openssl.org >>> <mailto:m...@openssl.org> >>> <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote: >>> >>> >>> >>> On 01/03/17 09:39, Suman Paul wrote: >>>> 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? >>> >>> Ah, right - you are using client auth. The choice of client certificate >>> has nothing to do with the underlying ciphersuite - it is chosen >>> independently. When client auth is in use you should see the server >>> sending a CertificateRequest message to the client. That >>> CertificateRequest contains within it the list of acceptable certificate >>> types. >>> >>> Matt >>> >>>> >>>> Suman >>>>> On Mar 1, 2017, at 1:33 AM, Matt Caswell <m...@openssl.org >>>>> <mailto:m...@openssl.org> >>>>> <mailto:m...@openssl.org <mailto:m...@openssl.org>> >>>>> <mailto: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 >>>> >>>> >>>> >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> > -- > 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