Open Bug 1397177 Opened 4 years ago Updated 10 months ago

Problem with the second peer connection in one browser tab (WebRTC)

Categories

(Core :: WebRTC: Networking, defect, P3)

55 Branch
defect

Tracking

()

Tracking Status
firefox55 --- affected
firefox57 --- affected

People

(Reporter: necromantos, Unassigned)

Details

Attachments

(1 file)

Attached file Connection Log.txt
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

I create two separate streams from my webcam with different identifiers. Then I try to connect to both of them and display them within one tab of the browser. 


Actual results:

First stream is displayed correctly, the second stream is not displayed at all.


Expected results:

Both streams should be displayed.
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core
Do you have an example page we can use to reproduce this?
Flags: needinfo?(necromantos)
Whiteboard: [needinfo to reporter 2017-09-07]
http://alpha-mgw-sd.webinar.ru/web/create.html

In first tab execute in console:
1) createPublisher("1")
2) createPublisher("2")

In second tab execute in console:
1) createPlayer("1")
2) createPlayer("2")

Second player will not work.
Thanks. I can reproduce this in both 55 and 57. We'll have to take a closer look to prioritize properly.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(necromantos)
Whiteboard: [needinfo to reporter 2017-09-07]
Rank: 25
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
I have found that Mozilla FireFox can not validate second DTLS Certificate with the same Common Name and different Public Keys. According the code it relies on unique Certificate Subject/Identity per Transport. That's why the same issue occurs with Google Chrome due to its static Common Name "WebRTC". Same issue with OpenWebRTC implementation (also "dtls" plugins from the GStreamer's gst-plugins-pad repo) with its "OpenWebRTC" Certificate. And Firefox works fine with each other in most cases since it generates random Common Names.

Anyway, using static Key Pair temporary solves the issue.
Yes, this is a problem in the NSS cert handling. I'll take a look and see if I can fix it.

Needinfoing WTC in case he has any good ideas.
Flags: needinfo?(wtc)
After looking at this a bit, I'm less sure what I said in c6 is correct. Firefox should be good with two certificates with the same CN as long as they have different issuer/serials. Valisy, are you sure you are generating separate issuer/serials?
Flags: needinfo?(pixelbender)
They have same issuer and serial but different keys:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=SE, CN=OpenWebRTC
        Validity
            Not Before: Oct 17 09:35:39 2017 GMT
            Not After : Oct 17 09:35:39 2018 GMT
        Subject: C=SE, CN=OpenWebRTC
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ...(different)...
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         ...(different)...
Flags: needinfo?(pixelbender)
Thanks. This matches my expectation and I'll see what we can do about making Firefox more robust in this case.
The issuer name + serial number pair uniquely identifies a certificate.
It is wrong for two different certificates to have the same issuer name
and serial number.

For example, see this excerpt from RFC 5280:

4.1.2.2.  Serial Number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).

I am sure this is also specified in X.509.
Flags: needinfo?(wtc)
Thanks, WTC. But reading the same RFC:

4.1.2.2.  Serial Number

   ...

   Note: Non-conforming CAs may issue certificates with serial numbers
   that are negative or zero.  Certificate users SHOULD be prepared to
   gracefully handle such certificates.

In the real world:

Google Chrome's WebRTC self-signed certificates have a negative serial number.
OpenSSL's self-signed certificates have a zero serial number.
Hello, colleagues, is there any new information on this issue? Its decision is very important for us.
Best regards!

After looking at this a bit, I'm less sure what I said in c6 is correct. Firefox should be good with two certificates with the same CN as long as they have different issuer/serials.

In https://mediasoup.org we create random DTLS certificates with random name/subject and random serial number:

However the issue reported above happens as shown here:

A second PeerConnection connecting to a different worker instance of mediasoup (which has a different random DTLS certificate) fails. And the issue does not happen if all worker instances of mediasoup are provided with the same DTLS certificate (instead of letting them create a random one).

Hi,
we are experiencing the same issue. We are using AWS Kinesis Video Streams with a backend based on https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c and GStreamer. Streams from multiple PeerConnections show up fine in Chrome but only one stream shows up in Firefox.
I have also created this issue for the amazon-kinesis-video-streams-webrtc-sdk-c (https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/issues/1050) but they say the problem is not on their side.

Is anyone looking into this?

Hi,
similar problem here. Opening two PeerConnections from one tab results in DTLS handshake error - Bad Certificate. Sending the same cert works well but it's not an option in my case. Any updates about this issue?

You need to log in before you can comment on or make changes to this bug.