HSTS preload list removals for Chrome 60.

HSTS preload list removals for Chrome 60.

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}
Committed: https://chromium.googlesource.com/chromium/src/+/b6dd6525ce6d24e9d3713d639eefb9e372095bde

[palmer, 2017-04-20 18:13:15]

lgtm

[lgarron, 2017-05-02 23:02:30]

Patchset #2 (id:20001) has been deleted

[lgarron, 2017-05-20 01:47:17]

Description was changed from

==========
HSTS preload list removals for Chrome 60.

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.

BUG=527947
TBR=palmer@chromium.org
==========

to

==========
HSTS preload list removals for Chrome 60.

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.

BUG=527947
TBR=palmer@chromium.org
==========

[lgarron, 2017-05-24 20:00:21]

The CQ bit was checked by lgarron@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-24 20:00:53]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[lgarron, 2017-05-24 20:37:46]

Description was changed from

==========
HSTS preload list removals for Chrome 60.

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.

BUG=527947
TBR=palmer@chromium.org
==========

to

==========
HSTS preload list removals for Chrome 60.

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.

BUG=527947
TBR=palmer@chromium.org
==========

[lgarron, 2017-05-24 20:45:57]

The CQ bit was checked by lgarron@chromium.org to run a CQ dry run

[lgarron, 2017-05-24 20:46:10]

Description was changed from

==========
HSTS preload list removals for Chrome 60.

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.

BUG=527947
TBR=palmer@chromium.org
==========

to

==========
HSTS preload list removals for Chrome 60.

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
==========

[commit-bot: I haz the power, 2017-05-24 20:46:27]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[lgarron, 2017-05-24 20:49:13]

Patchset #8 (id:160001) has been deleted

[commit-bot: I haz the power, 2017-05-24 20:50:03]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[commit-bot: I haz the power, 2017-05-24 22:56:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-24 22:56:17]

Dry run: This issue passed the CQ dry run.

[lgarron, 2017-05-25 00:36:58]

The CQ bit was checked by lgarron@chromium.org

[lgarron, 2017-05-25 00:36:59]

The patchset sent to the CQ was uploaded after l-g-t-m from palmer@chromium.org
Link to the patchset: https://codereview.chromium.org/2825083004/#ps140001
(title: "HSTS preload list removals for Chrome 60.")

[commit-bot: I haz the power, 2017-05-25 00:37:37]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-25 00:43:09]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1495672618397890,
"parent_rev": "14b8cc4e3063e2de20eed87b6cc22ecee092f869", "commit_rev":
"b6dd6525ce6d24e9d3713d639eefb9e372095bde"}

[commit-bot: I haz the power, 2017-05-25 00:43:25]

Description was changed from

==========
HSTS preload list removals for Chrome 60.

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
==========

to

==========
HSTS preload list removals for Chrome 60.

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}
Committed:
https://chromium.googlesource.com/chromium/src/+/b6dd6525ce6d24e9d3713d639eef...
==========

[commit-bot: I haz the power, 2017-05-25 00:43:26]

Committed patchset #7 (id:140001) as
https://chromium.googlesource.com/chromium/src/+/b6dd6525ce6d24e9d3713d639eef...