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
Review URL: https://codereview.chromium.org/2113813002 .
Cr-Commit-Position: refs/heads/master@{#414299}