Closed Bug 1316261 Opened 8 years ago Closed 8 years ago

System CA's cause big and fragmented DTLS messages

Categories

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

Product:
Core
Component:
WebRTC: Networking
Version:
49 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla53
Tracking Flags:
Tracking Status
firefox49 --- wontfix
firefox-esr45 50+ wontfix
firefox50 --- wontfix
firefox51 --- fixed
firefox52 --- fixed
firefox53 --- fixed
Blocking Flags:
backlog webrtc/webaudio+

People

(Reporter: georgios.sakellaris, Assigned: mt)

References

Details

Attachments

(4 files)

Screen_1_Bad_Case.jpg
810.18 KB, image/jpeg
Details
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,
58 bytes, text/x-review-board-request
drno
: review+
gchang
: approval-mozilla-aurora+
gchang
: approval-mozilla-beta+
lizzard
: approval-mozilla-esr45-
Details
Bug 1316261 - Update Firefox 51 to NSS 3.27.2,
58 bytes, text/x-review-board-request
franziskus
: review+
gchang
: approval-mozilla-beta+
Details
Bug 1316261 - Configure trust anchors list to be empty for WebRTC, , a=gchang
58 bytes, text/x-review-board-request
drno
: review+
Details
Attached image Screen_1_Bad_Case.jpg — 
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.35 Safari/537.36

Steps to reproduce:

Version: Firefox ESR 45.4

Initiate an WebRTC call between two Firefox that exist in the same network (peer to peer communication)


Actual results:

The peer connection between two Firefox never established because the DTLS handshake never completed.

Initial Analysis: The "Server Key Exchange" is followed by a big number of "Certificates Requests" that are fragmented to more than 6 fragments, these fragments are never reassembled in the other end, so DTLS handshake is never completed and the peer connection between (A) and (B) is never established

Based on RFC 5246, Section D.4 "Implementation Pitfalls" the handshake messages that are fragmented to multiple TLS records must be handled correctly


Expected results:

The Certificate Request fragments should be handled correctly in order to be able to complete the DTLS handshake

Note: The same test executed with Chrome in the same system. There is only one Certificate Request, the DTLS handshake is completed.
Severity: normal → blocker
OS: Unspecified → Windows 7
Priority: -- → P2
Hardware: Unspecified → x86_64
Summary: During DTLS Handshake the certificate request fragments are not completed → DTLS Handshake fails because the certificate request fragments are incomplete
Whiteboard: DTLS Handshake
Severity: blocker → normal
Component: Untriaged → WebRTC: Networking
Priority: P2 → --
Product: Firefox → Core
Whiteboard: DTLS Handshake
Wireshark is unfortunately not very good in properly analyzing what is going on with DTLS.

First of all I would recommend you to upgrade to a newer version of Wireshark, because the version you use is two years old. Maybe a recent version 2.2.x will show you something different.

Secondly would it be possible to attach the wireshark trace to this ticket?
If you don't want to share the trace publicly, could you send it to me directly?

My suspicion is that these are retransmissions, but we will have to look at the raw data to figure out what is going wrong there.

Another question is: do you know what the MTU is the network at question?
Flags: needinfo?(georgios.sakellaris)
Whiteboard: [needinfo 2016/11/09 to reporter]
George:
Is there anything unusual about the connection setup/certs/etc?

Do calls between these machines on that network work using "standard" apps like apprtc or appear.in?

Thanks!
Users reported that the problem is also reproduced with Firefox 49.0.2

@Nils: I will send you the wireshark traces in a PM from the following scenarios:
- Firefox 45.4 ESR (Fail)
- Firefox 49.0.2 (Fail)
- Chrome 54.0 (Success)

@Maire:Apart from the default certificate authorities, the user has the corporate CAs that also exist in all other systems
Firefox 49.0.2 - Wireshark Traces

The symptom is the same (No audio - No Screen Share) but the DTLS handshake failure is more clear:

Alert 21 - Decode Error 50
   decode_error
      A message could not be decoded because some field was out of the
      specified range or the length of the message was incorrect.  This
      message is always fatal and should never be observed in
      communication between proper implementations (except when messages
      were corrupted in the network).
Flags: needinfo?(georgios.sakellaris)
Version: 45 Branch → 49 Branch
Thanks for sending the traces via email.

Both Firefox 45 ESR and Firefox 49 include in their "Certificates Requests" the Distinguished Names of all the system CA's as per https://tools.ietf.org/html/rfc5246#section-7.4.4

Now with Firefox 45 it appears that even though it wants to send 34836 bytes for the CA names it stops after 6 packets (which adds up to 8184 bytes only). I'm assuming that is some kind of bug in the NSS version shipped with Firefox 45.

Firefox 49 actually send 24 packets, which adds up to 31988 bytes. A little strange is that Wireshark shows me the expected length should be 34836 bytes. But Firefox sends after that enormous certificate requests message encrypted handshake messages. So it looks like Firefox in this case proceeds normally with the DTLS handshake, but after another round of Client Hello followed by the same enormous server hello the client actually sends an alert "decode error (50)".

Martin, is it on purpose that Firefox actually includes all CA's DN's in it's Server hello message, or is that by itself already a bug?
Flags: needinfo?(martin.thomson)
Awesome.  It appears as though this is a case where our copy of NSS is initialized with the standard Firefox database.  That's not good; I think that we have assumed that we were operating without a database.

The simple fix here is to initialize the set of trust anchors.  I only have code inspection to back that up.  I don't have a lot of time this week, so I'd appreciate it if you could try my patch and see if it works for you.
Flags: needinfo?(martin.thomson)
Status: UNCONFIRMED → NEW
backlog: --- → webrtc/webaudio+
Ever confirmed: true
Priority: -- → P2
Whiteboard: [needinfo 2016/11/09 to reporter]
George could please download this build https://archive.mozilla.org/pub/firefox/try-builds/martin.thomson@gmail.com-0e318cceb373d8e971f0f76f1c5718702371a6d1/try-win32/firefox-52.0a1.en-US.win32.zip and report back if it fixes the problem for you?
Flags: needinfo?(georgios.sakellaris)
In case you want or need a different build for a different platform you can find them here https://treeherder.mozilla.org/#/jobs?repo=try&revision=0e318cceb373&selectedJob=30937988
@Nils, I will try to do the test as soon as possible, based on user's availability. Thank you for the quick responce
Comment on attachment 8809991 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,

https://reviewboard.mozilla.org/r/92464/#review92550

LGTM.
I would suggest to wait with landing this after we have feedback from the reporter if it fixes the issue.
Users confirmed that the problem has been solved with the build 52.0a1

I have also ask for wireshark traces in order to evaluate DTLS handshake with the fix.

Thank you for your support!
Nils: What are the planned dates for releasing this fix?
Will be included in the ESR version of Firefox?
Comment on attachment 8809991 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,

https://reviewboard.mozilla.org/r/92466/#review92648
Attachment #8809991 - Flags: review?(drno) → review+
Pushed by drno@ohlmeier.org:
https://hg.mozilla.org/integration/autoland/rev/18a3d8e8a789
Configure trust anchors list to be empty for WebRTC, r=drno
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox-esr45: --- → affected
Summary: DTLS Handshake fails because the certificate request fragments are incomplete → System CA's cause big and fragmented DTLS messages
(In reply to George Sakellaris from comment #15)
> Nils: What are the planned dates for releasing this fix?
> Will be included in the ESR version of Firefox?

Unfortunately the timing is not ideal as today is a release day. I think we should request uplift of this to everything. But as our policy is to only allow security fixes into release builds I fear this is only going to be released with the release of 51 in January, see https://wiki.mozilla.org/RapidRelease/Calendar
I think we can also request uplift to ESR. But I can't judge how are our chances to get it approved.
Flags: needinfo?(georgios.sakellaris)
Could you please at least request an uplift to ESR (if not done already)? Thanks a lot.
https://hg.mozilla.org/mozilla-central/rev/18a3d8e8a789
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment on attachment 8809991 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: Presumably enterprise customers are more likely to have additional CA certs installed on their systems, and no direct control over these. As these CA's are not relevant for WebRTC but prevent enterprise users from using WebRTC with Firefox it would be helpful to fix this issue for ESR users.

User impact if declined: Users can not establish WebRTC connections if there OS has one or more additional CA certificates installed.

Fix Landed on Version: 53

Risk to taking this patch (and alternatives if risky): The risk is pretty low as we only use existing NSS code to not use an empty trust anchor instead of the system default.

String or UUID changes made by this patch: N/A

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #8809991 - Flags: approval-mozilla-esr45?
[Tracking Requested - why for this release]: This problem most likely affects enterprise customers more then the users of Firefox regular release.
tracking-firefox-esr45: --- → ?
Comment on attachment 8809991 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,

Approval Request Comment
[Feature/regressing bug #]: The issue existed in Firefox since the initial landing of WebRTC.

[User impact if declined]: Users of Firefox which have additional CA certs installed on their system might not be able to establish WebRTC connections as the DTLS handshake might fail.

[Describe test coverage new/current, TreeHerder]: The basic connection establishing of WebRTC is covered by plenty of tests in our CI systems. We have no additional test which checks that additional CA certs on the system are no longer utilized by WebRTC as that would require specially prepared test machines, but the reporter has manually verified that the patch successfully fixes the issue.

[Risks and why]: The risk should pretty low as we only utilize existing functionality from NSS to use an empty trust anchor instead of the system default one.

[String/UUID change made/needed]: N/A
Attachment #8809991 - Flags: approval-mozilla-beta?
Attachment #8809991 - Flags: approval-mozilla-aurora?
Comment on attachment 8809991 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,

Fix an issue that users might not establish WebRTC connections. Beta51+ and Aurora52+. Should be in 51 beta 2.
Attachment #8809991 - Flags: approval-mozilla-beta?
Attachment #8809991 - Flags: approval-mozilla-beta+
Attachment #8809991 - Flags: approval-mozilla-aurora?
Attachment #8809991 - Flags: approval-mozilla-aurora+
See Also: → 1317959
Backed this out from beta for leaks. tc-M(5,c2,mda) and tc-M-e10s(mda) seem to permafail:

https://hg.mozilla.org/releases/mozilla-beta/rev/4ae2ca71ea3f13b5fb419abca01de6750fbc7bb8

Push with failures (the bc failure are from a different patch): https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=bcafa3ea224b818b4ffb165da4fa7a51f3d80280
Failure log (example): https://treeherder.mozilla.org/logviewer.html#?job_id=1930654&repo=mozilla-beta

[task 2016-11-17T16:47:48.008854Z] 16:47:48     INFO -  ==1276==ERROR: LeakSanitizer: detected memory leaks
[task 2016-11-17T16:47:48.009083Z] 16:47:48     INFO -  Indirect leak of 8192 byte(s) in 4 object(s) allocated from:
[task 2016-11-17T16:47:48.010870Z] 16:47:48     INFO -      #0 0x4b247b in malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52:3
[task 2016-11-17T16:47:48.014237Z] 16:47:48     INFO -      #1 0x7fa54e74fa24 in PL_ArenaAllocate /home/worker/workspace/build/src/nsprpub/lib/ds/plarena.c:127:27
[task 2016-11-17T16:47:48.016443Z] 16:47:48     INFO -      #2 0x7fa54e50a81f in PORT_ArenaAlloc_Util /home/worker/workspace/build/src/security/nss/lib/util/secport.c:274:9
[task 2016-11-17T16:47:48.016830Z] 16:47:48     INFO -      #3 0x7fa54e50a9da in PORT_ArenaZAlloc_Util /home/worker/workspace/build/src/security/nss/lib/util/secport.c:295:9
[task 2016-11-17T16:47:48.017182Z] 16:47:48     INFO -      #4 0x7fa54dfb0798 in CERT_DistNamesFromCertList /home/worker/workspace/build/src/security/nss/lib/certhigh/certhigh.c:714:14
[task 2016-11-17T16:47:48.017421Z] 16:47:48     INFO -  Indirect leak of 672 byte(s) in 4 object(s) allocated from:
[task 2016-11-17T16:47:48.019341Z] 16:47:48     INFO -      #0 0x4b2604 in calloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
[task 2016-11-17T16:47:48.020621Z] 16:47:48     INFO -      #1 0x7fa54ebd3407 in PR_NewLock /home/worker/workspace/build/src/nsprpub/pr/src/pthreads/ptsynch.c:142:12
[task 2016-11-17T16:47:48.021737Z] 16:47:48     INFO -      #2 0x7fa54e50a63a in PORT_NewArena_Util /home/worker/workspace/build/src/security/nss/lib/util/secport.c:230:18
[task 2016-11-17T16:47:48.022918Z] 16:47:48     INFO -      #3 0x7fa54dfb0778 in CERT_DistNamesFromCertList /home/worker/workspace/build/src/security/nss/lib/certhigh/certhigh.c:711:13
[task 2016-11-17T16:47:48.026330Z] 16:47:48     INFO -      #4 0x7fa54da88c68 in SSL_SetTrustAnchors /home/worker/workspace/build/src/security/nss/lib/ssl/sslsecur.c:1069:13
[task 2016-11-17T16:47:48.029018Z] 16:47:48     INFO -  Indirect leak of 288 byte(s) in 4 object(s) allocated from:
[task 2016-11-17T16:47:48.031438Z] 16:47:48     INFO -      #0 0x4b2604 in calloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
[task 2016-11-17T16:47:48.031787Z] 16:47:48     INFO -      #1 0x7fa54e50a611 in PORT_ZAlloc_Util /home/worker/workspace/build/src/security/nss/lib/util/secport.c:114:14
[task 2016-11-17T16:47:48.040125Z] 16:47:48     INFO -      #2 0x7fa54e50a611 in PORT_NewArena_Util /home/worker/workspace/build/src/security/nss/lib/util/secport.c:225
[task 2016-11-17T16:47:48.044826Z] 16:47:48     INFO -      #3 0x7fa54dfb0778 in CERT_DistNamesFromCertList /home/worker/workspace/build/src/security/nss/lib/certhigh/certhigh.c:711:13
[task 2016-11-17T16:47:48.046589Z] 16:47:48     INFO -      #4 0x7fa54da88c68 in SSL_SetTrustAnchors /home/worker/workspace/build/src/security/nss/lib/ssl/sslsecur.c:1069:13
[task 2016-11-17T16:47:48.048438Z] 16:47:48     INFO -      #5 0x7fa53ae26d4b in mozilla::TransportLayerDtls::Setup() /home/worker/workspace/build/src/media/mtransport/transportlayerdtls.cpp:518:10
[task 2016-11-17T16:47:48.049927Z] 16:47:48     INFO -  -----------------------------------------------------
[task 2016-11-17T16:47:48.051386Z] 16:47:48     INFO -  Suppressions used:
[task 2016-11-17T16:47:48.052846Z] 16:47:48     INFO -    count      bytes template
[task 2016-11-17T16:47:48.055445Z] 16:47:48     INFO -       40        986 libc.so
[task 2016-11-17T16:47:48.057078Z] 16:47:48     INFO -     1457      44880 nsComponentManagerImpl
[task 2016-11-17T16:47:48.061040Z] 16:47:48     INFO -       50       7200 mozJSComponentLoader::LoadModule
[task 2016-11-17T16:47:48.063100Z] 16:47:48     INFO -        1        384 pixman_implementation_lookup_composite
[task 2016-11-17T16:47:48.065464Z] 16:47:48     INFO -      361      20088 libfontconfig.so
[task 2016-11-17T16:47:48.067071Z] 16:47:48     INFO -        2      65568 nr_reg_local_init
[task 2016-11-17T16:47:48.071701Z] 16:47:48     INFO -      195      18592 r_log_register
[task 2016-11-17T16:47:48.073409Z] 16:47:48     INFO -       60       2761 nr_reg_set
[task 2016-11-17T16:47:48.075080Z] 16:47:48     INFO -        1         32 libdl.so
[task 2016-11-17T16:47:48.076662Z] 16:47:48     INFO -       26       6492 libglib-2.0.so
[task 2016-11-17T16:47:48.078238Z] 16:47:48     INFO -        1         28 libresolv.so
[task 2016-11-17T16:47:48.079960Z] 16:47:48     INFO -  -----------------------------------------------------
[task 2016-11-17T16:47:48.081860Z] 16:47:48     INFO -  SUMMARY: AddressSanitizer: 9152 byte(s) leaked in 12 allocation(s).
[task 2016-11-17T16:47:48.383513Z] 16:47:48     INFO -  TEST-INFO | Main app process: exit 0
[task 2016-11-17T16:47:48.383962Z] 16:47:48     INFO -  TEST-INFO | LeakSanitizer | To show the addresses of leaked objects add report_objects=1 to LSAN_OPTIONS
[task 2016-11-17T16:47:48.385745Z] 16:47:48     INFO -  TEST-INFO | LeakSanitizer | This can be done in testing/mozbase/mozrunner/mozrunner/utils.py
[task 2016-11-17T16:47:48.386122Z] 16:47:48  WARNING -  TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at PL_ArenaAllocate, PORT_ArenaAlloc_Util, PORT_ArenaZAlloc_Util, CERT_DistNamesFromCertList
[task 2016-11-17T16:47:48.388163Z] 16:47:48  WARNING -  TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at PORT_ZAlloc_Util, PORT_NewArena_Util, CERT_DistNamesFromCertList, SSL_SetTrustAnchors
[task 2016-11-17T16:47:48.389426Z] 16:47:48  WARNING -  TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at PR_NewLock, PORT_NewArena_Util, CERT_DistNamesFromCertList, SSL_SetTrustAnchors
Flags: needinfo?(martin.thomson)
Assignee: nobody → martin.thomson
status-firefox49: affected → wontfix
status-firefox50: affected → wontfix
Let's aim this at the next ESR in December (45.6.0) since this seems more likely to affect ESR users. 
Marking as fixed in 51 based on comment 26.
status-firefox51: affected → fixed
Comment 27 backed it out again from 51 :-)

More discussion happened over in bug 1317959, see for example https://bugzilla.mozilla.org/show_bug.cgi?id=1317959#c9, as that bug revealed that landing this actually causes a memory leak and requires at least NSS 3.28 to fix the leak. So in bug 1317959 I concluded that it's not wroth taking the risk of uplifting NSS 3.28 to 51.
For enterprise customers it would certainly be nice to get this fix into the ESR 45, but I have no idea which NSS version is currently in use in ESR 45, or what it would take to uplift NSS if needed.

@Liz: FYI in case you want to reconsider with that new information.
status-firefox51: fixed → wontfix
Flags: needinfo?(martin.thomson) → needinfo?(lhenry)
Nils, I am in the process of revising releasing NSS 3.27.2 with the necessary fix.  I'm happy to stop if you think that's not needed.
Comment on attachment 8815148 [details]
Bug 1316261 - Update Firefox 51 to NSS 3.27.2,

Approval Request Comment
[Feature/Bug causing the regression]: 1316261 
[User impact if declined]: Some WebRTC calls will fail if Firefox has additional trust anchors.
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]:  No; reporter has verified the fix
[List of other uplifts needed for the feature/fix]: The adjacent commit
[Is the change risky?]: No
[Why is the change risky/not risky?]: This is a very simple change that has been well tested.
[String changes made/needed]: None
Attachment #8815148 - Flags: approval-mozilla-beta?
Comment on attachment 8815149 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC, , a=gchang

Note that this is the same patch that already received approval, but I'm requesting again to verify that we still want this uplifted.

Approval Request Comment
[Feature/Bug causing the regression]: 1316261 
[User impact if declined]: Some WebRTC calls will fail if Firefox has additional trust anchors.
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]:  No; reporter has verified the fix
[List of other uplifts needed for the feature/fix]: The adjacent commit
[Is the change risky?]: No
[Why is the change risky/not risky?]: This is a very simple change that has been well tested.
[String changes made/needed]: None
Comment on attachment 8815148 [details]
Bug 1316261 - Update Firefox 51 to NSS 3.27.2,

https://reviewboard.mozilla.org/r/96166/#review96370
Attachment #8815148 - Flags: review?(franziskuskiefer) → review+
Comment on attachment 8815148 [details]
Bug 1316261 - Update Firefox 51 to NSS 3.27.2,

Fix a WebRTC issue. Beta51+. Should be in 51 beta 5.
Attachment #8815148 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8815148 [details]
Bug 1316261 - Update Firefox 51 to NSS 3.27.2,

Let's just hold this beta uplift request for a moment.

Hi :drno,
Per comment #30, do you think we need this in Beta51?
Flags: needinfo?(drno)
Attachment #8815148 - Flags: approval-mozilla-beta+ → approval-mozilla-beta?
Comment on attachment 8815149 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC, , a=gchang

https://reviewboard.mozilla.org/r/96168/#review96584
Attachment #8815149 - Flags: review?(drno) → review+
(In reply to Gerry Chang [:gchang] from comment #37)
> Comment on attachment 8815148 [details]
> Bug 1316261 - Update Firefox 51 to NSS 3.27.2,
> 
> Let's just hold this beta uplift request for a moment.
> 
> Hi :drno,
> Per comment #30, do you think we need this in Beta51?

Gerry my statement about not including it in 51 was based on the assumption that the effort for uplifting the relevant pieces of NSS to 51 would be too big. Since Martin has invested the effort I think we should included it in 51 if we can.
Flags: needinfo?(drno)
Attachment #8815148 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
That sounds like a lot of change in NSS, I don't think we should do that in ESR 45.7.0 (to go along with Firefox 51) but rather keep that to the new major ESR (52). Martin, is that ok with you?
Flags: needinfo?(lhenry) → needinfo?(martin.thomson)
We could uplift 3.27.2, but again, that's a fair change too.  It does seem to be very stable (it's been in Beta now for a while).  I don't know the status regarding the trust anchors though.

kathleen, is NSS 3.27 different from NSS 3.21 in ways that you care about such that it couldn't be uplifted to an ESR?
Flags: needinfo?(martin.thomson) → needinfo?(kwilson)
(In reply to Martin Thomson [:mt:] from comment #43)
> kathleen, is NSS 3.27 different from NSS 3.21 in ways that you care about
> such that it couldn't be uplifted to an ESR?

My personal opinion is that it would be fine/good to pick up the root cert changes that happened between NSS 3.21 and NSS 3.27. However, the ESR drivers need to decide. They typically do not like to have root certs removed in minor ESR releases.

Here's the list of CA changes between NSS 3.21 and NSS 3.27, with commentary about the removed certs in "[]".

NSS 3.22 -- no root cert changes

NSS 3.23
The following CA certificates were Removed
CN = Staat der Nederlanden Root CA [CA retired this root]
SHA-256 Fingerprint:
D4:1D:82:9E:8C:16:59:82:2A:F9:3F:CE:62:BF:FC:DE:26:4F:C8:4E:8B:95:0C:5F:F2:75:D0:52:35:46:95:A3
    
CN = NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado [CA retired this root]
SHA-256 Fingerprint:
E6:06:DD:EE:E2:EE:7F:5C:DE:F5:D9:05:8F:F8:B7:D0:A9:F0:42:87:7F:6A:17:1E:D8:FF:69:60:E4:CC:5E:A5
    
CN = NetLock Kozjegyzoi (Class A) Tanusitvanykiado [CA retired this root]
SHA-256 Fingerprint:
7F:12:CD:5F:7E:5E:29:0E:C7:D8:51:79:D5:B7:2C:20:A5:BE:75:08:FF:DB:5B:F8:1A:B9:68:4A:7F:C9:F6:67
    
CN = NetLock Uzleti (Class B) Tanusitvanykiado [CA retired this root]
SHA-256 Fingerprint:
39:DF:7B:68:2B:7B:93:8F:84:71:54:81:CC:DE:8D:60:D8:F2:2E:C5:98:87:7D:0A:AA:C1:2B:59:18:2B:03:12
    
CN = NetLock Expressz (Class C) Tanusitvanykiado [CA retired this root]
SHA-256 Fingerprint:
0B:5E:ED:4E:84:64:03:CF:55:E0:65:84:84:40:ED:2A:82:75:8B:F5:B9:AA:1F:25:3D:46:13:CF:A0:80:FF:3F
    
Friendly Name: VeriSign Class 1 Public PCA – G2 [CA retired this root]
SHA-256 Fingerprint:
34:1D:E9:8B:13:92:AB:F7:F4:AB:90:A9:60:CF:25:D4:BD:6E:C6:5B:9A:51:CE:6E:D0:67:D0:0E:C7:CE:9B:7F

Friendly Name: VeriSign Class 3 Public PCA [CA retired this root]
SHA-256 Fingerprint:
A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05
    
Friendly Name: VeriSign Class 3 Public PCA – G2 [CA retired this root]
SHA-256 Fingerprint:
83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E:DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B
    
CN = CA Disig [root cert expired]
SHA-256 Fingerprint:
92:BF:51:19:AB:EC:CA:D0:B1:33:2D:C4:E1:D0:5F:BA:75:B5:67:90:44:EE:0C:A2:6E:93:1F:74:4F:2F:33:CF

The following CA certificates were Added
CN = SZAFIR ROOT CA2
SHA-256 Fingerprint:
A1:33:9D:33:28:1A:0B:56:E5:57:D3:D3:2B:1C:E7:F9:36:7E:B0:94:BD:5F:A7:2A:7E:50:04:C8:DE:D7:CA:FE
CN = Certum Trusted Network CA 2
SHA-256 Fingerprint:
B6:76:F2:ED:DA:E8:77:5C:D3:6C:B0:F6:3C:D1:D4:60:39:61:F4:9E:62:65:BA:01:3A:2F:03:07:B6:D0:B8:04

The following CA certificate had the Email trust bit turned on
CN = Actalis Authentication Root CA
SHA-256 Fingerprint:
55:92:60:84:EC:96:3A:64:B9:6E:2A:BE:01:CE:0B:A8:6A:64:FB:FE:BC:C7:AA:B5:AF:C1:55:B3:7F:D7:60:66


NSS 3.24 -- no root cert changes

NSS 3.25
The following CA certificate was Removed
CN = Sonera Class1 CA [CA retired this root]
SHA-256 Fingerprint:
CD:80:82:84:CF:74:6F:F2:FD:6E:B5:8A:A1:D5:9C:4A:D4:B3:CA:56:FD:C6:27:4A:89:26:A7:83:5F:32:31:3D

The following CA certificates were Added
CN = Hellenic Academic and Research Institutions RootCA 2015
SHA-256 Fingerprint:
A0:40:92:9A:02:CE:53:B4:AC:F4:F2:FF:C6:98:1C:E4:49:6F:75:5E:6D:45:FE:0B:2A:69:2B:CD:52:52:3F:36
CN = Hellenic Academic and Research Institutions ECC RootCA 2015
SHA-256 Fingerprint:
44:B5:45:AA:8A:25:E6:5A:73:CA:15:DC:27:FC:36:D2:4C:1C:B9:95:3A:06:65:39:B1:15:82:DC:48:7B:48:33
CN = Certplus Root CA G1
SHA-256 Fingerprint:
15:2A:40:2B:FC:DF:2C:D5:48:05:4D:22:75:B3:9C:7F:CA:3E:C0:97:80:78:B0:F0:EA:76:E5:61:A6:C7:43:3E
CN = Certplus Root CA G2
SHA-256 Fingerprint:
6C:C0:50:41:E6:44:5E:74:69:6C:4C:FB:C9:F8:0F:54:3B:7E:AB:BB:44:B4:CE:6F:78:7C:6A:99:71:C4:2F:17
CN = OpenTrust Root CA G1
SHA-256 Fingerprint:
56:C7:71:28:D9:8C:18:D9:1B:4C:FD:FF:BC:25:EE:91:03:D4:75:8E:A2:AB:AD:82:6A:90:F3:45:7D:46:0E:B4
CN = OpenTrust Root CA G2
SHA-256 Fingerprint:
27:99:58:29:FE:6A:75:15:C1:BF:E8:48:F9:C4:76:1D:B1:6C:22:59:29:25:7B:F4:0D:08:94:F2:9E:A8:BA:F2
CN = OpenTrust Root CA G3
SHA-256 Fingerprint:
B7:C3:62:31:70:6E:81:07:8C:36:7C:B8:96:19:8F:1E:32:08:DD:92:69:49:DD:8F:57:09:A4:10:F7:5B:62:92

NSS 3.26
The following CA certificate was Added
CN = ISRG Root X1
SHA-256 Fingerprint:
96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6

NSS 3.27
The following CA certificates were Removed
CN = IGC/A, O = PM/SGDN, OU = DCSSI [CA retired this root]
SHA256 Fingerprint:
B9:BE:A7:86:0A:96:2E:A3:61:1D:AB:97:AB:6D:A3:E2:1C:10:68:B9:7D:55:57:5E:D0:E1:12:79:C1:1C:89:32
CN = Juur-SK, O = AS Sertifitseerimiskeskus [root cert expired]
SHA256 Fingerprint:
EC:C3:E9:C3:40:75:03:BE:E0:91:AA:95:2F:41:34:8F:F8:8B:AA:86:3B:22:64:BE:FA:C8:07:90:15:74:E9:39
CN = EBG Elektronik Sertifika Hizmet Sağlayıcısı [root cert expired]
SHA-256 Fingerprint:
35:AE:5B:DD:D8:F7:AE:63:5C:FF:BA:56:82:A8:F0:0B:95:F4:84:62:C7:10:8E:E9:A0:E5:29:2B:07:4A:AF:B2
CN = S-TRUST Authentication and Encryption Root CA 2005:PN [not compliant with BRs, no current audits, CA agreed with removal]
SHA-256 Fingerprint:
37:D8:DC:8A:F7:86:78:45:DA:33:44:A6:B1:BA:DE:44:8D:8A:80:E4:7B:55:79:F9:6B:F6:31:76:8F:9F:30:F6
O = VeriSign, Inc., OU = Class 1 Public Primary Certification Authority [no current audit, CA agreed with removal]
SHA-256 Fingerprint:
51:84:7C:8C:BD:2E:9A:72:C9:1E:29:2D:2A:E2:47:D7:DE:1E:3F:D2:70:54:7A:20:EF:7D:61:0F:38:B8:84:2C
O = VeriSign, Inc., OU = Class 2 Public Primary Certification Authority - G2 [no current audit, CA agreed with removal]
SHA-256 Fingerprint:
3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1
O = VeriSign, Inc., OU = Class 3 Public Primary Certification Authority [no current audit, CA agreed with removal]
SHA-256 Fingerprint:
E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70
O = Equifax, OU = Equifax Secure Certificate Authority [no current audit, CA agreed with removal]
SHA-256 Fingerprint:
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78
CN = Equifax Secure eBusiness CA-1 [no current audit, CA agreed with removal]
SHA-256 Fingerprint:
CF:56:FF:46:A4:A1:86:10:9D:D9:65:84:B5:EE:B5:8A:51:0C:42:75:B0:E5:F9:4F:40:BB:AE:86:5E:19:F6:73
CN = Equifax Secure Global eBusiness CA-1 [no current audit, CA agreed with removal]
SHA-256 Fingerprint:
5F:0B:62:EA:B5:E3:53:EA:65:21:65:16:58:FB:B6:53:59:F4:43:28:0A:4A:FB:D1:04:D7:7D:10:F9:F0:4C:07
Flags: needinfo?(kwilson)
Thanks for the further explanation. I still lean towards waiting for the major version change, in 52esr. The planned release date for 52.0esr is in early March 2017.
Comment on attachment 8809991 [details]
Bug 1316261 - Configure trust anchors list to be empty for WebRTC,

The jump in NSS version should wait till 52esr.
Attachment #8809991 - Flags: approval-mozilla-esr45? → approval-mozilla-esr45-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: