I believe the issue is that HSTS entry is for www.gov.uk, not gov.uk.  If you navigate to http://www.gov.uk, HSTS is honored as expected.

We do have HSTS headers on www.gov.uk: they are working as expected.

We've just added them on the raw gov.uk domain (which forwards to www.gov.uk), and it's for this domain that the header value isn't being stored/honoured.

~|⇒ curl -vv https://gov.uk 2>&1 | grep max-age
< Strict-Transport-Security: max-age=3600

Looks like you're right.

It may be because gov.uk is a registry controlled domain (i.e., foo.gov.uk and bar.gov.uk can't share cookies, so it's kind of a magic domain, as foo.gov.com and bar.gov.com can share cookies).  This may also be affecting the HSTS logic, not sure.  I'll defer to the domain security policy owners.

Yea, think that's the issue - while we accept the certificate, it runs afoul of a "non-unique" name check, since it's for the registry controlled domain itself, so we don't allow it to be added to the HSTS list.

No idea if this behavior is desired or not.

(More particularly, it ran into the IsCertStatusError check in url_request_http_job, just above where we process the Strict-Transport-Security header)

Yup, comment #4 is spot on. .gov.uk is still in the PSL - https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat#L6181

Moving it from the ICANN section to the PRIVATE section would permit this, for example, if the registry does indeed permit/allow/expect an A record at "http://gov.uk"

@mmenke: can you explain what you mean by a "non-unique name check" in this situation? We want to understand the ramifications of moving the domain from the ICANN to the PRIVATE section in the PSL.

The comment for the method to determine if a name is "unique" is:

// Returns true if |hostname| contains a non-registerable or non-assignable
// domain name (eg: a gTLD that has not been assigned by IANA) or an IP address
// that falls in an IANA-reserved range.

I don't know the motivation for the logic.

@Comment 7: We can happily follow up on https://github.com/publicsuffix/list (I'm a maintainer over there, so you don't have to reexplain the issue :P)

The motivation is the CA/Browser Forum's prohibition of "internal server names" and non-registerable domains. That is, you don't want a valid, publicly trusted certificate for https://webmail issued. This is because there's no way to validate "webmail" is unique and unambiguous - because it's neither an ICANN-delegated gTLD or an IANA-assigned [cc]TLD.

Similarly, you don't want a misissued certificate for "*.com" to be issued (which is actually a common target for CA compromise events), because then the certificate could be valid for "google.com", "yahoo.com", "microsoft.com" all at once.

So there are checks in place to ensure that the name portion indicates it is a registrable domain (e.g. operated by a registrant through agreement with a registry), that it's not for the registry itself (e.g. "http://com"), and that it's a valid TLD (e.g. not "http://webmail").

I'm surprised that navigating to https://gov.uk even works at all - I thought we (intentionally) blocked navigations to the ICANN portion of the public suffix list, but I could be misremembering. Either way, the change would go in the PSL, which provides the ability to distinguish between such cases.

#9 - I reckon gov.foo is a special case in all of the countries.
gov.il also works, for example.
(I was always surprised by the existence of that domain as a full domain name)

@rsleevi -- A gentle ping, is there any update on this issue.

Thanks!

Given comment #9, I expect this would be WontFix.

As a workaround, I'm happy to preload gov.uk (with or without subdomains) if you want HSTS to work for that domain.

As per comment #12 marking it as wont fix, please reopen or raise a new issue if this is a valid bug.

Thanks!