User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 Steps to reproduce: Enter https://mozilla.org to address bar and go to first url Actual results: Sometimes. Redirect from https://mozilla.org/ to https://www.mozilla.org/ and from https://www.mozilla.org/ to https://www.mozilla.org/ru/ with server IP 63.245.215.20 I see sha-1 certificates: (names and sha2 256 hashes) www.mozilla.org B4:D0:23:24:CF:8A:B6:BB:6B:32:66:BE:D8:87:F6:45:A3:12:48:24:67:C9:37:0D:0D:00:F9:3E:9D:DE:65:30 DigiCert High Assurance EV CA-1 54:1A:F0:19:96:17:60:EF:19:E8:FB:41:34:E6:D4:30:85:B5:E5:E0:87:F3:01:97:DC:42:B2:09:7E:10:48:7E DigiCert High Assurance EV Root CA 74:31:E5:F4:C3:C1:CE:46:90:77:4F:0B:61:E0:54:40:88:3B:A9:A0:1E:D0:0B:A6:AB:D7:80:6E:D3:B1:18:CF Expected results: sha-1 must not be use in mozilla.org

We use SHA-1 certs because we have to service XP SP2 clients. Note that this cert is only served to these older clients.

Excuse me, but how the server knows that such certificates must be submitted? I have Windows 7 and I can see these certificates. I see that my security is violated because customer support for long-obsolete machines.

(In reply to fdsc from comment #2) > Excuse me, but how the server knows that such certificates must be submitted? > I have Windows 7 and I can see these certificates. > > I see that my security is violated because customer support for > long-obsolete machines. The sha1 cert is conditionally served based on the TLS client hello; modern clients should get a sha256 cert. For more details, please see https://blog.cloudflare.com/tls-certificate-optimization-technical-details/. Depending on how you were checking the cert, you may have been seeing a sha1 cert due to not passing in the necessary options to your command line tools to send a TLS client hello that indicates support for a sha256 cert, but if you visit www.mozilla.org with a browser on your win7 machine and inspect the cert you should see that it is sha256. If this is not actually the case please reopen this bug and provide more details about the specific browser and ideally a screenshot of the cert inspection screen.

> but if you visit www.mozilla.org with a browser on your win7 machine and inspect the cert you should see that it is sha256 The fact that the redirect goes to www.mozilla.org . It's on a different IP and there are right certificate. However, at the time of the http redirection, I see a sha-1 certificate with machines to Win 7 (FireFox 47.0.1). This certificate is not displayed in the browser (there is a certificate after redirection). I see it by another way.

Two team members resolved this bug. Feel free to continue the discussion but please leave it resolved until one of said team members decides it can be reopened.

Okay, I can confirm the bug report: the request to mozilla.org goes to the ZLB, and there it is served a SHA-1 certificate, regardless of client. That is, even the latest versions of Firefox and Chrome get a SHA-1 certificate. This is surprisingly hard to test, because every browser ever caches those 301 Redirects, meaning that they almost never actually make a request for mozilla.org. I've attached a pcap of the latest Chrome, cleared session everything, and in incognito mode. The certificate that it receives is the SHA-1 cert. This still might be expected behavior; :ulfr or :jgmize, can you verify? I know that www sits in CloudFlare, but we're still doing the redirection for mozilla.org out of SCL3 and that will break once SHA-1 certs are fully deprecated.

> This is surprisingly hard to test, because every browser ever caches those 301 Redirects I see it quite often. Install http://fxprivacy.8vs.ru/http_useragent_cleaner_o-0.8.4-b05-fx.xpi (or https://addons.mozilla.org/firefox/addon/http-useragent-cleaner/ ) In "HTTP" tab of the Extension options set state in a first and in a second columns in "Cache" filter from disabled (green) to enabled (red). Then go to https:/mozilla.org In Extension in "TLS log" tab see: Remote address is 63.245.215.20:443 And sha-1 is used TLS estimate is 4% on red background To test again, press in the "FireFox" the "reset data" button and try again.

> filter from disabled (green) to enabled (red). Error. to "no cache" state.

> we're still doing the redirection for mozilla.org out of SCL3 and that will break once SHA-1 certs are fully deprecated. download.m.o is in the same boat. We only enabled cert switching on pages rendered in Firefox to avoid the bad UI, but we're still using SHA-1 on a number of sites that need WinXP compatibility. I expect this to change toward the end of the year, but for now I'd consider it a wontfix.

Sounds good, just wanted to verify. :)