Open Bug 1397177 Opened 5 years ago Updated 2 months ago
Problem with the second peer connection in one browser tab (Web
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?
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.
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.
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?
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)...
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: 184.108.40.206. 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.
Thanks, WTC. But reading the same RFC: 220.127.116.11. 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!
You need to log in before you can comment on or make changes to this bug.