Thanks for filing the issue!

@Reporter: Could you please share a sample test File/Web URL which helps us to triage the issue in a better way. Any further inputs from your end may help us.

I think a shorter explanation is that after loading a page with strict-transport-security and max-age=anyvalue, it's not possible to go back to http (unless you use private browsing, or clear all I guess, haven't tried to clear all)

so max-age value doesn't matter,
also it is possible that after this if I remove the certificate and add another one which was not even intended for my domain, than chrome loads page ok, ff says "the owner of this website hasn't configured it correctly"

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

managed to reproduce this even without SSL certificate.
I'm adding the STS in the rewrite rules in web.config (asp.net), like this:
   <rules>
       <rule name="HTTP to HTTPS redirect" stopProcessing="true">
           <match url="(.*)" />
           <conditions>
               <add input="{HTTPS}" pattern="off" ignoreCase="true" />
           </conditions>
           <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                   redirectType="Permanent" />
       </rule>
   </rules>
   <outboundRules>
       <rule name="Add Strict-Transport-Security when HTTPS" enabled="true">
           <match serverVariable="RESPONSE_Strict_Transport_Security"
                  pattern=".*" />
           <conditions>
               <add input="{HTTPS}" pattern="on" ignoreCase="true" />
           </conditions>
           <action type="Rewrite" value="max-age=300" />
       </rule>
   </outboundRules>
and I tried running this just now (without having SSL certificate, haven't run letsencrypt on this new subdomain yet), I got myself locked into https without ever even loading the url successfully,

so I removed all the above code from web.config (waited more than 5 min for the max-age=300) and after typing the domain with http I get redirected to https which obviously doesn't load, because there's no certificate  

Uninstalling the certificate from your server will have no bearing on the HSTS status of the hostname. Sending the Strict-Transport-Security header is a request to disallow access to plain HTTP for the specified time. It's a commitment on your part to deploy HTTPS.

It sounds like you are reporting three different issues. First, you report that HSTS does not honor the max-age value. After you believe the HSTS entry to have expired, please go to chrome://net-internals/#hsts, type in your hostname, and paste what it says.

Second, you report that Chrome and Firefox differ slightly in what certificates they allow. Chrome and Firefox use different trust stores, so it's possible you hit a different there. Or perhaps something was just cached. Please attach a NetLog of that happening per these instructions, and we'll take a look.
https://dev.chromium.org/for-testers/providing-network-details

Third, you report that HSTS is somehow being applied without a certificate in comment #5. Are you sure you're not just seeing your "HTTP to HTTPS redirect" happening? You did set a permanent redirect, which I believe we cache. Please attach a NetLog of that happening, as well as the results of querying this subdomain in chrome://net-internals/#hsts.

Thanks!

I changed the subdomain name, removed the redirect from the web.config, left only the HSTS,

I installed a letsencrypt certificate and loaded the https version, after removed the certificate (by deselecting it in a dropdown in plesk panel)
immediately after that chrome was still loading the website (https) and FF was saying that it is not secure

after 5 minutes chrome also started to say that it is not secure but I still can't go to the http version, shows me the loaded website for 0.1 sec, and after covers it with gray screen and not secure message, and if I click "ADVANCED" at the end I see:

"You cannot visit demo6.aspnetawesome.com right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later."

in chrome://net-internals/#hsts at Query HSTS/PKP domain for demo6.aspnetawesome.com, I get this:
static_sts_domain: 
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains: 
static_sts_observed: 
static_pkp_domain: 
static_pkp_include_subdomains: 
static_pkp_observed: 
static_spki_hashes: 
dynamic_sts_domain: demo6.aspnetawesome.com
dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: false
dynamic_sts_observed: 1514920888.94919
dynamic_sts_expiry: 1601320888.949189
dynamic_pkp_domain: 
dynamic_pkp_include_subdomains: 
dynamic_pkp_observed: 
dynamic_pkp_expiry: 
dynamic_spki_hashes: 

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

dynamic_sts_expiry - dynamic_sts_observed is 86400000, which is 1000 days. We don't even allow more than 365 days from the header.

In fact, 1000 days is what adding it from chrome://net-internals does.
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/net_internals/net_internals_ui.cc?type=cs&sq=package:chromium&l=839

Did you use that UI to add your HSTS entry? I'm guessing you typed it into the "Add HSTS/PKP domain" form, rather than the "Query HSTS/PKP domain" form. Please either do this again on a new subdomain or enter demo6 into the "Delete domain security policies" box and start the test again on it.

(That chrome://net-internals uses an arbitrary timeout which is larger than the header allows is kind of silly, but chrome://net-internals is a debugging and testing tool, so this doesn't hugely matter.)

yes, I did, 

and I tried it now, and "max-age" works as it should,

seems that the whole problem was the caching of the redirect

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ah. Yes, if you tell clients the redirect is permanent, they may indeed cache that thing. :-)

@davidben@chromium.org

the problem with cached redirects to https is that 

if the ssl certificate is absent the request will never reach the server which may have a redirect from https to http, so the user will inevitable see the "Not Secure/Danger" screen, and even if I repeatedly correct the url in the address bar from https to http it still executes the cached redirect

Yes, this is why you probably shouldn't ask the browser to cache something for longer than you intend the stale results to work well. :-)