Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(394)

Issue 2113813002: HSTS preload list removals for Chrome 54. (Closed)

Created:
4 years, 5 months ago by lgarron
Modified:
4 years, 3 months ago
Reviewers:
CC:
cbentzel+watch_chromium.org, chromium-reviews
Base URL:
https://chromium.googlesource.com/chromium/src.git@master
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

HSTS preload list removals for Chrome 54. ecosystem.atlassian.net: Covered by atlassian.net redbee.nl: > We cannot support HTTPS on the following subdomains: > • staging.schoolwijzer.redbee.nl - Customer staging environment, out of > our control and just for testing purposes. cerfrance.fr: > We cannot support HTTPS on the following subdomains: > • link.85.cerfrance.fr – use by a email marketing service (sarbacane) > • link.cn.cerfrance.fr – use by a email marketing service (sarbacane) spacecompute.com: > I have no idea how this happened, since I never submitted the domain, but I > would like to remove it because unfortunately it's breaking some services that > integrate with google apps -- which it turns out do not play well with HTTPS > requests. ptsoft.de: > We cannot support HTTPS on the following subdomains: > > • dm8000.ptsoft.de - Forwarding to internal server > • config.ptsoft.de - Forwarding to internal server everythingkitchens.com: [15 subdomains] hosted on separate server than main domain hilti.com, etc. (25 hilti.{eTLD} domains): internal systems with same domain hilti.com do not all support https yet souyidai.com: > We cannot support HTTPS on the following subdomains: > • mail.souyidai.com - cooperation with other company nitho.me: > I am afraid that it due to that blindly following online tutorial. hovie.at: > We cannot support HTTPS on the following subdomains: > > • andrew.hovie.at - I don't have to time to manage my own server > anymore, so I switched to a hosting provider, wildcard certs are > expensive, they do not support certs with multiple domains. > > Also, when I enabled preload, I did not actually know what I am doing, > I was just following the recommendation from https://cipherli.st/. constructdigital.net: > We cannot support HTTPS on all sub-subdomains, since we don't have a wildcard > SSL for them. Also, this domain is meant for development purpose and was > configured as HSTS preload by mistake. groovinads.com: > We cannot support HTTPS on the following subdomains: > • my.groovinads.com - Appnexus does not handshake over https, and it's killing us. > • groovinads.com - same as above > • *.groovinads.com shamka.ru: > We cannot support HTTPS on the following subdomains: > > • [water] - don’t have ssl cert. > • [w] - not open 443 port > • and many new subdomains terravirtua.com: > chalk it up to copy-pasting something without fully understanding what i was > doing... i had added that after doing the ssl checker, following a > recommendation about increasing the 'grade' it returned. i later removed it > (the whole HSTS header) only to discover that everything continued to redirect > to https... and finally realizing i was preloaded. domainkauf.de: > We support HTTPS in another way and so we have problems with the following > subdomains: > • mail.domainkauf.de HTTP Redirect to the main mailserver > • imap /smtp / pop / pop3 / webmail with same reason internl.net: Uses uniquely generated domains per user with second-level subdomains, e.g. www.*.pa.internl.net; this can't be handled using wildcard certs. rinobroer.nl: No citable reason given. sexton.uk.com: > We cannot support HTTPS on the following subdomains: > > • mail.sexton.uk.com - costs for multiple SSL or SAN cert > • webmail.sexton.uk.com - costs for multiple SSL or SAN cert extracobanks.com: > We cannot support HTTPS on the following subdomains: > > • Various internal subdomains - Although our external website, > www.extracobanks.com, exclusively uses HTTPS, we also use extracobanks.com as > our internal domain. Having extracobanks.com on the HSTS preload list is > causing problems for our employees connecting to internal sites, such as our > internal CRM that uses a self-signed certificate. Chrome and Firefox are > giving "certificate authority invalid" errors when connecting to these > internal subdomains. We also have some non-HTTPS 3rd party vendor provided > internal sites that cannot be changed to HTTPS that we cannot connect to at > all. > > Our www.extracobanks.com site was built and is managed by a 3rd party > Marketing firm. I'm sure they added the HSTS header with the best intentions, > but it is causing issues for us internally with our employees. intramanager.co.uk/intramanager.dk: > We cannot support HTTPS on the domain, since we changed our whole SSL setup > and therefore do not support HTTPS on the intramanager.co.uk > [/intramanager.dk] domain anymore. > > We have moved all activity to intramanager.com, where we have full HTTPS > support. thekelvinliu.com: > I have a Tumblr blog at blog.thekelvinliu.com, which does not support https. h-neef.de: > We cannot support HTTPS on the whole Domain including subdomains, because we > moved to a new IP Address and Need it for test purposes! nathancheek.com: > I never intended to be preloaded, nor to include subdomains, but I made the > mistake of adding ‘preload’ and 'includeSubDomains’ to the HSTS header, > without understanding what they entailed. mercurystorm.co.za: > I have moved from a Virtual Private Server to shared hosting, and can no > longer use SSL certificates klaxn.com: > my client is not able to pay for a SSL certificate postpi.com: > self signed certificate stupus.com: > We cannot always support HTTPS on the all of our subdomains. > ... > I can no longer always support HTTPS on my domain because I change server > distributions frequently. upstox.com: > We cannot support HTTPS on the following subdomain: > > help.upstox.com -> We are using this domain to point help.rksv.in with CNAME > record and for rksv.in domain we don't have Wildcard SSL certificate so > whenever we open help.upstox.com it goes to HTTPS in chrome. TBR=palmer@chromium.org BUG=527947

Patch Set 1 #

Patch Set 2 : HSTS preload list removals for Chrome 54. #

Patch Set 3 : HSTS preload list removals for Chrome 54. #

Patch Set 4 : HSTS preload list removals for Chrome 54. #

Patch Set 5 : HSTS preload list removals for Chrome 54. #

Patch Set 6 : HSTS preload list removals for Chrome 54. #

Unified diffs Side-by-side diffs Delta from patch set Stats (+0 lines, -53 lines) Patch
M net/http/transport_security_state_static.json View 1 2 3 4 28 chunks +0 lines, -53 lines 0 comments Download

Messages

Total messages: 6 (4 generated)
commit-bot: I haz the power
Patchset 6 (id:??) landed as https://crrev.com/c2ed5d4ef0dc5dbb94240dadb56a08c2a3f7c9b0 Cr-Commit-Position: refs/heads/master@{#414299}
4 years, 3 months ago (2016-08-25 03:56:28 UTC) #4
lgarron
4 years, 3 months ago (2016-08-25 04:02:13 UTC) #6
Message was sent while issue was closed.
Committed patchset #6 (id:100001) to pending queue manually as
f36657a636738f988e6ba9e91156e86cb9064094 (presubmit successful).

Powered by Google App Engine
This is Rietveld 408576698