Closed Bug 1068715 Opened 11 years ago Closed 10 years ago

Upgrade SHA1 SSL certificates with SHA-256

Categories

(Infrastructure & Operations :: SSL Certificates, task)

Product:
Infrastructure & Operations
Component:
SSL Certificates
Platform:
x86_64
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gozer, Assigned: Atoll)

References

(
URL
)

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/139] )

Browsers will start rejecting SHA1 SSL certificates in a while. DigiCert makes it really simple to just 'rekey' and get our existing certificates reissued with SHA-256 hashes. No reason to delay this. And, this is a potential security issue, so it's important.
For reference, from the DigiCert report: 00460149 peekaboo.mozilla.org SSL Plus 2016-12-08 00459169 *.allizom.org WildCard Plus 2016-12-06 00455878 *.bugzilla-dev.allizom.org WildCard Plus 2016-11-30 00452332 passwordreset.mozilla.org SSL Plus 2016-11-16 00444813 generic-san.mozilla.org Unified Communications 2016-10-20 00453458 hg.mozilla.org SSL Plus 2016-09-28 00437876 aus4.mozilla.org SSL Plus 2016-09-27 00436087 Code Signing 2016-09-21 00457727 saml.mozilla.org SSL Plus 2016-08-03 00453709 pfs.mozilla.org SSL Plus 2016-07-20 00458219 graphite.mozilla.org Unified Communications 2016-05-17 00451154 bzr.mozilla.org SSL Plus 2016-05-05 00454208 aus2.mozilla.org SSL Plus 2016-04-27 00453843 nagios.mozilla.org SSL Plus 2016-04-20 00454223 ldap.mozilla.org SSL Plus 2016-03-02
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/1289]
fyi, if the fingerprint changes we'll need to have advance notice for hg.mozilla.org as developers may pin it in their hgrc.
The fingerprint would change on hg.mozilla.org, so I guess we do need to notify folks. Anyone know what's the right group to tell, and how much notice they would need? There's no good way server-side to have both work for a while, so it's going to be a hard cut-over whenever it's done. We could probably provide the new fingerprint in advance of putting it in place, if that helps any. I don't know anything about how problematic the code signing one might be. Probably best to get more details on what it is and then ask RelEng. generic-san *might* be a concern. In particular, blog.mozilla.org is an official PR channel, and so might be more sensitive than some other things. AUS2 might be a concern. That's only used by old Firefox's. Firefox supports SHA-2 as of version 1.5 (yes 1.5), so the vast majority won't matter, but there's a small possibility that a very small % of our users won't be able to update. By extension AUS4 would have the same concern, because AUS2 redirects to 3, which will soon redirect to 4. AUS3 is SHA-1 (issued by Thawte, so not in this dashboard), expiring Sep 8, 2017, so this is currently not broken for these users. None of the others really bother me.
Actually, for hg.m.o how 'bout I just deal with it since I still have digicert access and can handle the notification?
Assignee: server-ops-webops → gozer
"AUS3 is SHA-1 (issued by Thawte, so not in this dashboard), expiring Sep 8, 2017, so this is currently not broken for these users." But note that the intermediates listed in http://lxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js are all SHA1 ones. I will file a separate bug about this.
Filed bug 1116409 .
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/1289] → [kanban:https://webops.kanbanize.com/ctrl_board/2/139]
Depends on: 1116409
Assignee: gozer → rsoderberg
# Revised list hg.mozilla.org SSL Plus 2016-09-28 bzr.mozilla.org SSL Plus 2016-05-05 *.allizom.org WildCard Plus 2016-12-06 pfs.mozilla.org SSL Plus 2016-07-20 crash-reports-xpsp2.mozilla.com EV Multi-Domain 2016-12-30 SHA1 for compatibility reasons. *.cdn.mozilla.net WildCard Plus 2016-12-30 SHA1 for compatibility reasons. *.bugzilla-dev.allizom.org WildCard Plus 2016-11-30 bug 1147505 aus4.mozilla.org SSL Plus 2016-09-27 bug 1116409 aus2.mozilla.org SSL Plus 2016-04-27 bug 1116409 ldap.mozilla.org SSL Plus 2016-03-02 bug 1147499
Depends on: 1147548
Depends on: 1071161
Does this report also cover the following? The browser console gets flooded with warnings when opening a new tab. tiles.cdn.mozilla.net snippets.cdn.mozilla.net
Can you provide an example warning for each?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150506030206 about:newtab I can't seem to reproduce the issue. I only see connections to tiles.services.mozilla.com now, which don't result in a browser console warning. I'll post an additional comment should that change. about:home This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1. [Learn More] [1] | default [2] [1] https://developer.mozilla.org/docs/Security/Weak_Signature_Algorithm [2] https://snippets.cdn.mozilla.net/4/Firefox/40.0a1/20150506030206/WINNT_x86_64-msvc/en-US/nightly/Windows_NT%206.1/default/default/
Depends on: 1169612
Warnings shown in the Browser Console, using a fresh profile, on opening a new tab: 10:46:02.815 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 tiles.cdn.mozilla.net 11:12:50.679 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 developer.cdn.mozilla.net 11:12:51.433 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 mozorg.cdn.mozilla.net Warnings shown for visiting various Mozilla sites: 11:14:35.000 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 support.mozilla.org 11:14:35.529 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 support.cdn.mozilla.net 11:14:40.244 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 www.mozilla.org 11:17:06.400 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 bugzilla.mozilla.org 11:21:16.332 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 hg.mozilla.org 11:18:12.127 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 air.cdn.mozilla.net Plus these: 11:14:37.148 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 d2bnxibecyz4h5.cloudfront.net 11:14:37.880 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 surveygizmobeacon.s3.amazonaws.com
Depends on: 1195445
(In reply to Kendall Libby [:fubar] from comment #4) > Actually, for hg.m.o how 'bout I just deal with it since I still have > digicert access and can handle the notification? Based on https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/ it sounds like hg.m.o might stop working in a little less than 6 months. From previous comments about cert pinning, I gather that there's some amount of developer outreach necessary prior to changing the cert. How much lead time do we need here?
Flags: needinfo?(klibby)
Alright. As of now, we've updated the vast majority of our certificates to SHA-2. Any that are remaining extant - to the best of my knowledge - will either expire, are kept SHA1 intentionally, or are actively being worked on by other teams. This bug has reached the end of its useful life, and so I'm going to close it now. Please file new bugs about individual remaining SHA1 instances. There are three bugs linked to this one still open, and I'll review them each next, but we've otherwise concluded this work.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(klibby)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.