Nginx – HSTS exclude specific subdomain with “includeSubdomains”

To be accepted, your pin must :

1. Contains at least one key of the current certificate chain
2. Contains at least one key NOT in the current certificate chain (a "Back up key"). I think this one was missing in your case.

To test it :

• use firefox developper edition, go in the network tab, select a request, select the security tab of the right. It must indicate "Public Key Pinning" with the status
• if you really want to produce the error, use the option "include subdomains", and sign any subdomain with a new key. Firefox should refuse the connection.

Some docs : https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning

To be more specific : "If I don't include the certificate's pin-sha256 (nor any intermediate or root certificate's)", then the browser don't save the pin. The browser display at connection error only when an already saved pin list doesn't match the current certificate chain.

https://scotthelme.co.uk/hpkp-toolset and https://report-uri.io/home/pkp_analyse can help

Yes, in fact the redirect contains octets that are above 7-bit (greater than 0x80 hexadecimal). Various application will convert those octets to various visual representation on your screen; that depends on what encoding they decide to use.

If somebody would use UTF-8 they would likely get a fine cyrillic text, but that's accidental; off-topic to the question.

https://www.rfc-editor.org/rfc/rfc7230#section-3.2 states quite precisely that:

Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data.

and

obs-text = %x80-FF

This means, that practically any octets can be sent. The software that displays a header, for example a browser that converts the octets to some visible representation on your screen, should use ISO-8859-1 for this conversion.

But the server that receives the data in a HTTP session is also free to use the octets for his operations, which is something that does not involve displaying any visual representation on any screen. In this case HTTP server uses the octets to serve you a page. Since HTTP server just gets some octets of input and produces some octets of output, the "encoding" does not really apply here (the HTTP server never needs to convert bytes into something that it shows on a screen or on a printer).