61

I am reading this post and not understanding the answer.

The answer ends with the words

...your browser can verify one cert against the next, all the way to the root CA, which your browser inherently trusts.

How my browser can inherently trust a CA? Does in contain hard coded public key of the CA? If so, why does not it expire? Where can I see what CAs are inherently trusted by the browser?

Chloe
  • 1,668
  • 3
  • 15
  • 30
polina-c
  • 631
  • 1
  • 5
  • 6
  • 47
    it's not a great system, you're right... – dandavis May 08 '17 at 04:37
  • 1
    Are you asking how it is done technically (meaning, cryptographicaly) or perceptually, how can the browser afford to trust a third party CA? – MiaoHatola May 08 '17 at 05:49
  • @dandavis why isn't this a great system, you mean the chain of trust? sounds pretty good to me :) – EralpB May 08 '17 at 07:56
  • 35
    Browsers trust them, because they have enough money to be root CA. Money == trust. If someone have enough money to register international organization, they can't be bad guys, right? And since they are trusted to be decent people, we can safely assume, that they security is *flawless*. I mean, how can someone possibly acquire a lot of money without hiring top-notch security experts? – user1643723 May 08 '17 at 08:24
  • 4
    @EralpB: because consumers don't know who's who in terms of CAs and cryptographic primitives, different browser/versions trust different places/things, CAs charge money for what should be a free/public service, and the whole setup is still subject to mitm, phishing, and distrust. – dandavis May 08 '17 at 09:23
  • 7
    @dandavis All your points except cost are in my opinion positives. Consumers not needing to understand TLS seems like a good thing. Different trust sounds like an OPEN platform. The whole system has been working quite successfully, and for phishing, "they can always build a better idiot". CAs do charge money, which does help to increase the barrier for scamming, and verification of an identity by its very nature is very resource intensive (otherwise TLS would be obsolete). – Aron May 08 '17 at 10:07
  • 8
    You might want to google "StartCom WooSign Firefox Chrome" to see what happens when a few browser vendors decide to withdraw their inherent trust – Hagen von Eitzen May 08 '17 at 10:48
  • 1
    this defcon video about ssl security problems seems relevant: https://www.youtube.com/watch?v=UawS3_iuHoA – martinkunev May 08 '17 at 15:17
  • 13
    @user1643723 Not true. As pointed out by other comments here, there have been numerous cases where CAs with _lots_ of money became untrusted by browsers after it was discovered that said CAs were not worthy of that trust. In reality CAs are trusted not based on money (though you do need a pretty big budget to run a successful CA) but on their adherence to the Baseline Requirements and their ability to pass a number of checks browsers impose on them as detailed in their root certificate programs. For example, here's Microsoft's: https://technet.microsoft.com/en-us/library/cc751157.aspx – Ajedi32 May 08 '17 at 18:29
  • 1
    @Ajedi32 You seem to be impervious to [sarcasm](https://en.wikipedia.org/wiki/Sarcasm) - or you have a _very_ dry sense of humour ;) – Tobias Kienzler May 10 '17 at 07:11
  • 2
    @TobiasKienzler I'm well aware that user1643723 was being sarcastic in the sense that he himself doesn't believe money == trust. However, the context of his comment makes it sound like he believes that browser vendors do think that way, which is not the case. – Ajedi32 May 10 '17 at 11:47
  • @Ajedi32 That makes sense. Well, it _is_ the impression you might get when you realize how long it sometimes takes for them to remove violating CAs, though (obviously?) exaggerated. – Tobias Kienzler May 10 '17 at 11:51

1 Answers1

78

How my browser can inherently trust a CA? Does in contain hard coded public key of the CA?

Your browser (and possibly your OS) ships with a list of trusted CAs. These pre-installed certificates serve as trust anchors to derive all further trust from. When visiting an HTTPS website, your browser verifies that the trust chain presented by the server during the TLS handshake ends at one of the locally trusted root certificates.

If so, why does not it expire?

Root certificates do expire, but they tend to have exceptionally long validity times (often about 20 years). You can expect that with an update of your browser or OS, you will get fresh root certificates before the old ones expire.

Where can I see what CAs are inherently trusted by the browser?

That depends on your browser. Some browsers will just use the central root certificate store of your OS, if available.

For Mozilla Firefox, you can find information about the included certificates here and in this source code file. From within Firefox, you can view all your installed certificates by going to about:preferences and to Advanced > Certificates > View Certificates.

For Google Chrome, the root certificate policy can be found here. From within Google Chrome, you can go to the settings, click Show advanced settings... and under HTTPS/SSL you click Manage certificates to view all installed certificates.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • Expiry - I would also guess that as long as there is one CA able to provide new trusted certificates, if able to authenticate the other CAs using it, you can get copies of their new certificates. I would also assume that replacement certificates are generally issued while the old ones are stil valid. I expect you could run into issues if you were to try to install a very old version of your browser, on a new install of an old OS, if all the shipped certificates had expired. – Baldrickk May 08 '17 at 13:04
  • For IE you can view trusted certificates by going to `Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities` – Tom Carpenter May 08 '17 at 16:35
  • 4
    @Baldrickk CA certificates cannot be fetched proactively by the browser, as there is no central resource to fetch them from; instead, the entire chain from leaf back to possible roots is provided in the TLS handshake by the web server you are connecting to. So if you only had a single root certificate installed, web server administrators would have to configure their servers to include an intermediate certificate signed by that one root. The only way root certificates are automatically added (or removed) is when the product (browser or OS) updates. – IMSoP May 08 '17 at 17:02
  • 3
    Windows, since about 2010 IIRC, can automatically add a root to the store when needed by IE or Edge, and I believe Chrome-Windows, that wasn't previously visible by looking at the store. See https://security.stackexchange.com/questions/81491/are-there-other-roots-of-trust-on-my-computer-aside-from-these-46-root-certifica also https://security.stackexchange.com/questions/46332/browsers-silently-adding-trusted-root-certificates-in-windows . @IMSoP: many (most?) public certs nowadays use AIA and client _can_ fetch intermediates, although TLS does require server to send them. – dave_thompson_085 May 09 '17 at 06:03
  • @dave_thompson_085 Ah, interesting. I guess the MS fetches could be seen as there still being a single root store, but "in the cloud", since the new roots presumably aren't trusted based on the current store contents, but on a separate MS signature. I guess theoretically a certificate chain could be constructed by recursively downloading intermediates until you reached a single trusted anchor, but it would require quite some co-ordination among CAs for you to be able to get from any "root" (which would no longer be a root if it was counter-signed) to any other. – IMSoP May 09 '17 at 11:40
  • do all the certificates (from x-th level intermediate to the root) must present in the client side in order to complete the verification? Or some certificates along the way can be verified on some other "trusted" machines, like can the verification process be delegated? – zgulser Apr 26 '21 at 10:53