cbtistexcalac.mx:
> The reason is because many of our clients use PC without have correctly set
> the date and also have pcs with very old windows versions and many times just
> don’t want to pay for a SSL.
pflege.de:
> we just removed the HSTS header at pflege.de because of problems with the subdomains.
fyrkat.no, jornane.no, jornane.nl, jornane.me:
> The reason is that due to the recent blacklisting of free CA StartCom, I
am not confident that I am able to provide HTTPS in the future. In this
case, I want to revert to opportunistic HTTPS, which I cannot do while
the domain is HSTS preloaded.
monarcasystems.com:
> • The reason is because many of our clients use PC without have correctly set
> the date and also have pcs with very old windows versions and many times just
> don’t want to pay for a SSL.
skhosting.eu:
> We use subdomains on internal network just with selfsigned certificates and
> access them trought VPN. Nowadays we have to allow access them from public
> network and use letsencrypt certificates. But we would like to use this
> subdomains accessible only from our internal network for security reasons.
lincolncollege.edu:
> • http://libguides.lincolncollege.edu/ - libguides is hosted from a service
> provider not associated with Lincoln College. The SSL certificate being used
> is not associated with Lincoln College and is therefore throwing security
> errors when the subdomain is masked with lincolncollege.edu.
47ronin.com:
> One of the subdomains: live.47ronin.com is on Tumblr and SSL does not work
> properly on custom domains, and it seems this may never be fixed.
opinello.com:
> • www.kiosk.opinello.com
> • www.ruch.opinello.com
> • and all new future domains in format www.*.opinello.com
>
> The reason is the high cost of buying new certificates for the next domains in
> www.*.opinello.com format. We are going to create a many subdomains in
> specified format.
hosted-service.com:
> A technician inadvertently copy/pasted a configuration that included the
> preload directive, and this was not discovered for some time. The directive
> has been removed and we are now serving max-age=0.
blupig.net:
> We have some internal devices that does not support TLS at all, or very
> difficult to enable and maintain + update certificates in them, since they are
> all in internal network, it would be ok for us to access without https.
avenelequinehospital.com.au:
> This is being hosted on a business catalyst (Adobe) site that does not support
> custom SSL certificates
tomwiggers.nl:
> - simagine.tomwiggers.nl (redirect)
> - svmware.tomwiggers.nl (redirect)
> - helios.tomwiggers.nl (self signed VMware certicate, it's an ESXi host, I use
> Let's Encrypt for (sub)domains I can provide good HTTPS for but with VMware
> this is difficult)
> - webmail.tomwiggers.nl (redirect)
>
> Users keep getting HSTS errors in Chrome when they visit any of the above
> websites because they are either redirects or do not support proper HTTPS.
>
> Earlier when I implemented HSTS on my webserver I did not realise HSTS
> preloading does not just apply to one subdomain but the whole domain,
> everything. I realised this too late.
wholesalesolar.com:
> We have decided to aggressively move our entire web and marketing
> infrastructure onto Hubspot's Marketing platform, COS (Content Optiimzation
> System).
> ...
> We have been informed by Hubspot that they are unable to support HSTS headers
> in conjunction with HTTPS due to Akamai's CDN network.
marquiseclub.se:
> Domain name has previously been used by another company. We do not need hsts,
> so please remove as soon as possible
mea.in.ua:
[Could not get a reason.]
BUG=527947
TBR=palmer@chromium.org
Review-Url: https://codereview.chromium.org/2825083004
Cr-Commit-Position: refs/heads/master@{#474497}