Does HSTS protect a domain from a publicly trusted CA that has gone rogue issuing a illegitimate valid certificate? Examples of publicly trusted CA's would be any of the members of the Mozilla CA Bundle.

Is there any way to protect a domain from having an illegitimate but publicly trusted CA issue a valid certificate?

  • 1
    Depending on how the HSTS is set-up on the particular site(subdomains and so on..), the browser does not ask anything further than a valid certificate for an HSTS site. That means it doesn’t require the certificate to be same exact as the last time site was visited. You’d think that’s a liability but not so much. Local ARP/DNS spoofing won’t allow you to generate a publicly-trusted CA, all modern browser will throw red flags. There is a risk though that a particular website gets hijacked.. but then would they even need to replace the cert? :) Commented Sep 20, 2019 at 17:11
  • @I'maTIcalculator I suppose my hope was that the certificate wanted to be trusted would be bundled and distributed by, for example, the browser vendor, such that the browser software would have no need to ask the host for any certificate and check validity, but could instead assume any other certificate than the one bundled is invalid. I know that's a lot to ask, and probably far out of line with how much of the industry wants to operate. I suppose what I really want is to require my organizations CA to have signed all certificates that are considered publicy valid for my organizations domains Commented Sep 20, 2019 at 17:20
  • 2
    In-case anyone else is pondering how to become a CA, its amazing: security.stackexchange.com/a/177897/53804 Commented Sep 20, 2019 at 17:59
  • How many man hours did it take you to submit, then audit and so on? Was it worth it in the end? Curious to know what’s the total % or # of sites with a valid CA on the web today, can’t be much.. maybe you know? Commented Sep 20, 2019 at 18:07

1 Answer 1


No, HSTS does not protect against certificate misissuance. HSTS simply tells the browser to only allow connecting to that site over HTTPS, it doesn't have anything to do with checking whether the certificate should be trusted.

There are two things that can help with misissuance to some extent, Certificate Transparency (CT) and Certificate Authority Authorization (CAA).

Certificate Transparency won't prevent misissuance by a CA, but it requires that certificates are publicly logged, so you can check and see if any certificates have been issued for your domain that shouldn't have been. Since 2018 Google Chrome has required that all new certificates issued be CT logged in order to be trusted. Firefox does not yet unfortunately, but in practice all certificates issued these days are CT logged as otherwise they would not work with Chrome.

Certificate Authority Authorization allows you to indicate which CAs are allowed to issue certificates for your domain using a DNS record. This will prevent accidental issuance by a CA, but of course a bad actor will just ignore it. Since CAA is only intended to say which CAs are allowed to issue a certificate at a specific point in time, and not for the lifetime of the certificate (ie if the CAA record changes the certificate is still valid), this is only a useful control for CAs that aren't bad actors, as it can help prevent them from issuing a certificate they shouldn't have which could eventually lead to their being distrusted. In fact, the RFC specifically requires that browsers not check CAA records.

A third option is HPKP, which allows you to pin a specific certificate that must be used for your domain (it needn't be a leaf certificate, pinning your CA's root would be somewhat similar to using CAA, but more effective), but it has fallen out of favor and is no longer supported by Chrome.

EDIT: curiousguy points out an interesting attack to work around CT logging in some cases. If an attacker has a Man in the Middle position, they may be able to tell which browser is establishing a connection early on (eg due to minor behavioral differences in the TLS stack). This could allow them to decide not to attack connections from browsers known to check CT logs, simply forwarding the connection to the legitimate server, but present a misissued and non-CT logged certificate to other browsers in order to impersonate the legitimate server. It seems that the only way to prevent this would be for all browsers to check CT logs.

  • I think your answer beats mine! Delete time... Commented Sep 20, 2019 at 17:41
  • 1
    Unfortunately HPKP is deprecated by Google, so as of writing this comment the only major browsers it works in is Firefox and Opera
    – Bear
    Commented Sep 21, 2019 at 3:34
  • @Bear: IOW 2 out of 4. "All the others" but Safari are just reskinned Chrome with random UI changes and bundled stuff. Commented Sep 21, 2019 at 3:56
  • 1
    Reading this, I figured CAA would be something the browser would also validate, so CA's can't accidentally do something wrong, and when they do something wrong on purpose, it doesn't even work, but... Kinda useless to be honest. Commented Sep 21, 2019 at 15:25
  • 1
    But if a TLS server can detect which browser is asking early, it can present a different cert for Chrome and FF.
    – curiousguy
    Commented Sep 21, 2019 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .