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
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
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
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
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,
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
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