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 P
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 unsucce
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 R
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 certifi
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 wrote:
>
>
>
> On 01/03/17 05:55, Suman Paul wrote:
>> I
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 s
