Closed
Bug 967596
Opened 10 years ago
Closed 10 years ago
https://firefox.com gives invalid certificate, auth prompt
Categories
(Infrastructure & Operations :: SSL Certificates, task)
Infrastructure & Operations
SSL Certificates
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: corey, Assigned: cturra)
Details
Attachments
(1 file)
64.26 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.73.11 (KHTML, like Gecko) Version/7.0.1 Safari/537.73.11 Steps to reproduce: Visit https://firefox.com or https://www.firefox.com Actual results: My browser presents a certificate warning, because the server gives me a certificate valid for only the following names: static-san.mozilla.org , addons.mozilla.com , autoconfig-live.mozillamessaging.com , autoconfig.thunderbird.net , broker-live.mozillamessaging.com , live.mozillamessaging.com , live.thunderbird.net , nightly.mozilla.org , getfirefox.com , www.getfirefox.com , opensearch-live.mozillamessaging.com , dnt.mozilla.org , support.live.mozillamessaging.com In addition, visiting https://firefox.com causes the server to prompt my browser for an HTTP Basic/LDAP login Expected results: A correct certificate for *.firefox.com and firefox.com should be presented. Rather than getting an HTTP Basic/LDAP prompt or a certificate error, I would expect to be redirected to the correct site with no errors, or whatever the firefox.com domain should be doing.
Updated•10 years ago
|
Assignee: server-ops → server-ops-webops
Component: Server Operations → WebOps: SSL and Domain Names
Product: mozilla.org → Infrastructure & Operations
QA Contact: shyam → nmaul
Assignee | ||
Comment 1•10 years ago
|
||
to clarify, the content served for {www.}firefox.com is through our static redirect server and does /not/ have ssl enabled for that domain. however, due to the way SNI (server name indication) is enabled for other interfaces in that web cluster, our load balancer is trying to do ssl termination on these requests. i have updated the way the redirects work for the vhost that was returning these basic auth requests. as a result, you will still be presented with an ssl warning if you go to https, however, if you accept that warning will be directed to the same place. * i looked through the logs and there are close to zero request for this via https so see little value in adding full support for ssl at this time. $ curl -Ik https://firefox.com HTTP/1.1 301 Moved Permanently Server: Apache X-Backend-Server: pp-web01 Vary: Accept-Encoding Content-Type: text/html; charset=iso-8859-1 Date: Tue, 04 Feb 2014 18:14:37 GMT Location: https://www.mozilla.org/firefox/?utm_source=firefox-com&utm_medium=referral Transfer-Encoding: chunked Connection: Keep-Alive X-Cache-Info: caching $ curl -Ik http://firefox.com HTTP/1.1 301 Moved Permanently Server: Apache X-Backend-Server: pp-web02 Vary: Accept-Encoding Cache-Control: max-age=0 Content-Type: text/html; charset=iso-8859-1 Date: Tue, 04 Feb 2014 18:15:24 GMT Location: https://www.mozilla.org/firefox/?utm_source=firefox-com&utm_medium=referral Expires: Tue, 04 Feb 2014 18:15:24 GMT Transfer-Encoding: chunked Connection: Keep-Alive X-Cache-Info: not cacheable; response specified max-age <= 0
Assignee: server-ops-webops → cturra
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•