Closed
Bug 1193832
Opened 10 years ago
Closed 10 years ago
Certificate for incoming.telemetry.mozilla.org uses SHA-1
Categories
(Webtools Graveyard :: Telemetry Server, defect)
Webtools Graveyard
Telemetry Server
Tracking
(firefox43 affected)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox43 | --- | affected |
People
(Reporter: vladan, Unassigned)
References
Details
When Firefox sends a Telemetry ping to Mozilla servers (incoming.telemetry.mozilla.org), the following warning gets logged to the Browser Console:
"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]"
for https://incoming.telemetry.mozilla.org
Can we update the certificate?
Comment 1•10 years ago
|
||
Wes, do you know if / how we can fix the SSL cert we're using on that endpoint?
Flags: needinfo?(whd)
Comment 2•10 years ago
|
||
This certificate is expiring next month, so we need to update it anyway. I'll get a new one generated and uploaded.
Flags: needinfo?(whd)
Comment 3•10 years ago
|
||
I need to determine how we want to proceed with this, due to the proliferation of telemetry microservices. The current certificate is a SAN cert that doesn't support all the current and forthcoming domains (some of which are TBD). Our options are to (a) continue to use SAN, updating the cert every time a new endpoint is added, (b) individual certs for each microservice, (c) use a wildcard cert. (c) has the least administrative overhead, but opsec has traditionally been against this (for good reasons).
:ulfr, which method would you recommend?
Flags: needinfo?(jvehent)
Comment 4•10 years ago
|
||
*.telemetry.mozilla.org is its own set of services and nothing else than telemetry data lives on there, so it seems reasonable to me to give it a wildcard cert.
r+
Flags: needinfo?(jvehent)
cert request submitted at digicert
Comment 6•10 years ago
|
||
Thanks to :ckolos the new cert has been generated and is available for use. I'll update incoming.telemetry.mozilla.org to use the new cert this week, but the new cert is available, so I'm removing blocking status from dependent bugs. I'll be sending :rvitillo the ARN to use out of band. Once I've updated incoming.telemetry.mozilla.org I'll close this bug.
Comment 7•10 years ago
|
||
The new certificate is in place:
$ curl -vvv https://incoming.telemetry.mozilla.org
* Connected to incoming.telemetry.mozilla.org (52.26.105.201) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_DHE_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
* subject: CN=*.telemetry.mozilla.org,O=Mozilla Corporation,L=Mountain View,ST=California,C=US
* start date: Aug 25 00:00:00 2015 GMT
* expire date: Aug 29 12:00:00 2018 GMT
* common name: *.telemetry.mozilla.org
* issuer: CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•