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




WebRTC: Networking
4 months ago
2 months ago


(Reporter: Anatoly, Unassigned)


55 Branch

Firefox Tracking Flags

(firefox55 affected, firefox57 affected)



(1 attachment)



4 months ago
Created attachment 8904908 [details]
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.


4 months ago
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]

Comment 2

4 months ago

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.
Has STR: --- → yes
status-firefox55: --- → affected
status-firefox57: --- → affected
Ever confirmed: true
Flags: needinfo?(necromantos)
Whiteboard: [needinfo to reporter 2017-09-07]


4 months ago
Rank: 25
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3

Comment 5

3 months ago
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.

Comment 6

3 months ago
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)

Comment 7

3 months ago
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)

Comment 8

3 months ago
They have same issuer and serial but different keys:

        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=SE, CN=OpenWebRTC
            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)
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
Flags: needinfo?(pixelbender)

Comment 9

3 months ago
Thanks. This matches my expectation and I'll see what we can do about making Firefox more robust in this case.

Comment 10

3 months ago
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:  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

I am sure this is also specified in X.509.
Flags: needinfo?(wtc)

Comment 11

3 months ago
Thanks, WTC. But reading the same RFC:  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.

Comment 12

2 months ago
Hello, colleagues, is there any new information on this issue? Its decision is very important for us.
Best regards!
You need to log in before you can comment on or make changes to this bug.