Quick search turns up a proposal to deal with it <a href="https:&#x2F;&#x2F;www.ietf.org&#x2F;mail-archive&#x2F;web&#x2F;websec&#x2F;current&#x2F;msg00506.html" rel="nofollow">https:&#x2F;&#x2F;www.ietf.org&#x2F;mail-archive&#x2F;web&#x2F;websec&#x2F;current&#x2F;msg0050...</a> (but hasn&#x27;t been implemented in the actual standard, see below).<p><i>Revocation<p>In the event of pin mismatch, clients MUST check whatever revocation
mechanism is available, and attempt to discover whether the certificate
with the mismatching fingerprint has been revoked. For example:<p><pre><code>  offending_certificate = cert in certificate_chain where
      cert.public_key.fingerprint == mismatched_fingerprint


  revoked = offending_certificate.serial_number in revoked_serials

</code></pre>
If the offending certificate has been revoked, it is unpinned and the UA
can re-evaluate the pin list. If there are no pinned fingerprints left
on the pin list, the browser downgrades the host from Known Pinned HSTS
Host to Known HSTS Host.<p>The revocation mechanism could be an extant mechanism such as CRL or
OCSP, or a new one such as browser updates, whitelists, blacklists, or
an in-built CRL. This document is agnostic about the revocation
mechanism(s) UAs may use.<p>Un-pinning<p>Certificates that are invalidated for any reason and by any means --
revocation by extant or future means, expiration, blacklisting -- are
effectively removed from the pin list. Certificates whose intermediary
or root signers are revoked are also effectively invalidated and removed
from the pin list.<p>HSTS Hosts can un-set pins in clients (un-pin) by setting a pins
directive that contains no pins. UAs MUST NOT obey the un-pinning
directive unless the empty pins directive is set on a response in a TLS
connection that was authenticated with one of the previously pinned
public keys.</i><p>This doesn&#x27;t seem to have made it into the standard, though: <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ietf-websec-strict-transport-sec-02#section-7.3" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ietf-websec-strict-transpo...</a> says<p><i>When connecting to a Known HSTS Host, the UA MUST terminate the
   connection (see also Section 10 &quot;UA Implementation Advice&quot;, below) if
   there are any errors (e.g. certificate errors), whether &quot;warning&quot; or
   &quot;fatal&quot; or any other error level, with the underlying secure
   transport.  This includes any issues with certificate revocation
   checking whether via the Certificate Revocation List (CRL) [RFC5280],
   or via the Online Certificate Status Protocol (OCSP) [RFC5280].</i><p>and <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6797#section-8.4" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6797#section-8.4</a> says<p><i>When connecting to a Known HSTS Host, the UA MUST terminate the
   connection (see also Section 12 (&quot;User Agent Implementation Advice&quot;))
   if there are any errors, whether &quot;warning&quot; or &quot;fatal&quot; or any other
   error level, with the underlying secure transport.  For example, this
   includes any errors found in certificate validity checking that UAs
   employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
   via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
   as via TLS server identity checking [RFC6125].</i>