HSTS preload list removals for Chrome 59.

HSTS  preload list removals for Chrome 59.

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

BUG=527947
TBR=palmer@chromium.org

Review-Url: https://codereview.chromium.org/2732883005 .
Cr-Commit-Position: refs/heads/master@{#464668}
Committed: https://chromium.googlesource.com/chromium/src/+/3467ad55e36b4780b267826f53530e41d0ec6b09

[lgarron, 2017-04-14 03:32:28]

Description was changed from

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

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

BUG=527947
==========

to

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

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports
only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

BUG=527947
==========

[lgarron, 2017-04-14 03:34:58]

Description was changed from

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

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports
only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

BUG=527947
==========

to

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

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports
only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

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

[lgarron, 2017-04-14 03:36:20]

Description was changed from

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

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports
only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

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

to

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

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports
only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

BUG=527947
TBR=palmer@chromium.org

Review-Url: https://codereview.chromium.org/2732883005 .
Cr-Commit-Position: refs/heads/master@{#464668}
Committed:
https://chromium.googlesource.com/chromium/src/+/3467ad55e36b4780b267826f5353...
==========

[lgarron, 2017-04-14 03:36:21]

Committed patchset #2 (id:20001) manually as
3467ad55e36b4780b267826f53530e41d0ec6b09 (presubmit successful).