# Who verifies the trust of certificate authorities?

## Background

I am a novice in the field of cryptography and cyber-security, and while studying asymmetric-key encryption, I learned about the potential of a man-in-the-middle attack.

To mitigate this threat, people came up with certificate authorities that essentially "vouches" for the trust of 3rd parties by supplying you their respective public keys signed with the CA's own private keys.

## Question

Here is where I am getting confused.

Can't we just use the same logic to intercept and compromise the transfer of information between the user and the CA (certificate authority)?

If the Certificate authority vouches for the Generic Website to ensure trust and safety, who vouches for the Certificate authority?

• I think the general idea is that "it's much less likely for an attack to happen on the one connection that matters for ownership validation as it is for the many subsequent secured ones" though some validation mechanisms are more robust than others. – SEJPM Dec 5 '19 at 9:01
• What you have discovered is a basic principle: there must be some secure channel for key exchange that is secured by non-crypto techniques. Crypto is a lever that turns the security of the key exchange into the security of the message. There must be a mechanism for securely obtaining the CA public key that does not rely on crypto. – Eric Lippert Dec 5 '19 at 18:15
• The IT Security answer is: the browser makers validate the CAs. They can and will yank a CA from the browsers for misconduct or even a security breach (example). – Michael Hampton Dec 6 '19 at 0:54
• As this is more a practical security issue, that is an issue in society, with humans, not a pure cryptography/math question. You might ask those questions on security.stackexchange.com/ – curiousguy Dec 7 '19 at 15:45
• @MichaelHampton It takes quite a bit of misconduct to get a hard sanction. (Comodo got off easy a few years ago.) – curiousguy Dec 7 '19 at 15:54

Maarten Bodewes answer is correct but I think the heart of your question is a major hurdle people face in understanding certificates and CAs. I think it's worth elaborating on the part of how this works that I think you are missing.

As stated in Maarten's answer, your computer/browser has been preconfigured with a set of trusted CAs. If you are running Windows you can see what these are by running certmgr.msc (you must type the entire name in search). In that application, you will see a number of folders. One of these is named "Trusted Root Certification Authorities". If you expand "Certificates" under that folder, you will see a long list of certificates for various CAs.

When you go to a website and you get a 'trusted' lock icon, that means that the certificate they are presenting has a parentage that includes a certificate in this store. I'm oversimplifying slightly here but this is the core idea. For example, if I look at the certificates at google.com, the grandparent certificate has the friendly name of "Google Trust Services - GlobalSign Root CA-R2". I look at my store and I see that exact certificate which I can verify by looking at the 'thumbprint'.

So the reason that no one can MiTM the root certificates is that you are not going out to the CA to get your trusted CAs, you already have them on your machine. If you browse a website with a CA cert that don't have in your trusted CA store, your browser should throw a lot of warnings at you that the site is not trusted.

I hope this helps. A side note is that this should also help you to understand how much risk there is in importing a new trusted root certificate. For example, let's say you are doing some experimentation and generate your own 'CA' certificate. You import this as a trusted CA and voilà! You now can sign certificates that your browser trusts. But consider what could then happen if someone else gets access to the private key you generated for that root CA. They now can create a certificate for any website and unless you check the cert chain on each site you go to, you could become subject to a MiTM attack.

• For currently supported Windows (8.1 and 10 at least, maybe earlier) that list is not complete; see security.stackexchange.com/questions/81491/… – dave_thompson_085 Dec 6 '19 at 5:48
• Also, I think that Firefox uses it's own cretificate store, and not the system certificates. – Ismael Miguel Dec 6 '19 at 12:51
• As a follow up to importing certificates: A machine you use at your place of employment probably has one or more of the employers certificates as a trusted root. If so, this means your employer can MITM any website you visit. – dbush Dec 6 '19 at 16:36
• @dbush: Your employer and anyone else who obtains access to the private key their MITM appliance is using, which might not even be specific to their installation but reused by the same product elsewhere. – R.. GitHub STOP HELPING ICE Dec 7 '19 at 22:11
• Corporations often install a wildcard certificate CA authority on employees' computers, so that they see the plaintext of all your browser secure connections. They essentially perform a man-in-the-middle attack. – Maxim Egorushkin Dec 11 '19 at 10:57

There has to be some point where you trust something. Operating system come with 'root' certificate authorities. Those certificates are either installed when you install the operating system, or could be downloaded over a secure connection from at least one certificate installed with the operating system.

You can (and many developers do) add your own root certificate to your computer's trusted roots. In this case, you can use the certificate to sign other certificates for development and your browser and apps on your computer or another computer with your certificate installed as a trusted root certificate will happily show the connection as secure.

So you go to https://www.mybank.com in your browser and your browser receives a certificate. This certificate has a chain of trust. In Chrome you can go to the developer console Security tab and view the certificate and the chain of trust, which will lead up to a trusted root certification authority. On windows 10 you can see your computer's certificates with "Manage Computer Certificates".

Notice what mine says for this site:

HDC-PROXY01-1 is a weird address to issue a certificate to stackexchange.com, eh? Turns out my connection is being attacked with a MITM attack by my employer who snoops on everything I do at work. The computer they provided me with has the company's own certificates installed as 'Trusted Root Certification Authorities' for just this purpose. Their proxies can intercept secure connections and provide their certificates instead of the ones belonging to the site you are going to, proxy the data over a secure connection to the site using the site's actual certificate, and re-encrypt the data with the proxy certificate before sending it back to me. My browser trusts the proxy's certificate because it was signed with the company's certificate in my trusted store.

• ._. I hope your employer doesn't see this post – FireCubez Dec 8 '19 at 13:51
• Oddly enough, I hope your employer sees specifically this post – ellman121 Dec 12 '19 at 9:45

No because the browser that you use has a build in security store, so it is perfectly possible to create a secure connection to the CA.

Generally you can only request certs for your specific domain, e.g. by using a domain specific mail address. Generally you should also pay for the services which provider a small amount if traceability.

Of course you should do this from a secure address with a trusted network connection, not from a public wifi hotspot.

For digital signing certificates usually you require some kind of proof that you are in control of an organization. See for instance a list of documents that you could provide here. Kind of obviously, many CA's don't care all that much and the system could definitely be considered broken in many ways. That same list was linked to when asking for a code signing certificate.

More secure certs such as Extended Validation (EV) certificates, such as those for banks require more validation of of the identity of the bank. Those secure certs were not necessarily more secure when it comes to cryptography, but in principle they should have added some level of trust into the issuance of the certificates (see the discussion in the comments below).

I've put it in the past tense because obviously the criteria for EV certificates to make the web a safer place have not really been met.

• How are bank certificates "more secure"? They use the exact same cryptography as free certificates. All they have is additional identity information (which, while verified by the CA, can still be misleading). – user2313067 Dec 5 '19 at 22:08
• Well, they have more verified information. Except for the hash algorithms, the cryptography has precious little influence on the security so far. That kind of verification is just as important as e.g. key sizes and algorithms, if not more so. Of course, just like about anything, the implementation may be broken, but certainly in principle (and I truly belief also in practice) they are more secure. – Maarten Bodewes Dec 5 '19 at 22:18
• This is incorrect. The additional validation has been greatly exaggerated. They're being deprecated in all major browsers. troyhunt.com/extended-validation-certificates-are-dead has a good writeup. Also the only thing they validate is that there's a registered legal business in some country with the stated name. It doesn't have to be unique. See stripe.ian.sh for an example. Just use Letsencrypt. – SAI Peregrinus Dec 5 '19 at 23:03
• @SAIPeregrinus Hmm, I know about the theory of the things. I'll leave it in for now, but if it is practically bust, then it is bust. – Maarten Bodewes Dec 6 '19 at 0:00
• @DamianYerrick Code signing is a very different scenario, but leads back to the same question: Who are we trusting to sign something, and what are we trusting them to check?. Checking that someone paid $10, or that they have a company registered with a particular name, isn't particularly useful, for a website or a software download. – IMSoP Dec 6 '19 at 10:17 One idea I find useful in this context is looking at cryptographic systems not as absolute ways of achieving guaranteed security, but rather, as ways of reducing bigger problems to other problems that are hopefully smaller but still potentially substantial. Seen from this angle, you're basically grasping the following points: • Public key cryptography is a way of reducing the problem of establishing a confidential and authenticated channel with another party to the problem of establishing an authenticated channel with that party. • Public key infrastructure is a way of reducing the problem of establishing authenticated channels with lots of different parties to the problem of establishing an authenticated channel with fewer, trustworthy certificate authorities. But the difference is this way of formulating the topic foregrounds that what you're left with after you've implemented a purely cryptographic solution is also a problem in its own right, whose solution will likely need non-cryptographic elements. For example, operating system vendors have root certificate programs (e.g., Microsoft, Apple) that decide what root certificates to bundle with their operating systems. But even if we assume those programs are infallible (they're not), that doesn't stop, say, Lenovo from preinstalling adware on its laptops that bundled an easily hackable root certificate to perform a man-in-the-middle attack on the user's SSL connection in order to show them ads. This is a real-life example of exactly the sort of attack you worry about: Can't we just use the same logic to intercept and compromise the transfer of information between the user and the CA (certificate authority)? If the Certificate authority vouches for the Generic Website to insure trust and safety, who vouches for the Certificate authority? So the answer is yes, it's possible to compromise the delivery of a root CA bundle, and there's no purely cryptographic solution to it because the tree of trust must come to a root and there the cryptography ends and you're left with the mundane stuff like whether your computer vendor is trustworthy. What reduces the risk beyond that point is non-cryptographic measures to validate that the computers you buy don't have a maliciously configured trust store (e.g., do a fresh operating system install when you first get them, from a copy you've done your best to validate). This is a very good question. Public-key certificates have the purpose to authenticate an assertion, namely that you are communicating with the entity that you intend to communicate with. Specifically, guarding against a Man-in-the-Middle attack (MitM) is done by authenticating the key material that is used. Your issue is the following. Say A and B want to establish a secure channel using their public keys $$K^\mathsf{pub}_A$$ and $$K^\mathsf{pub}_B$$. If they haven't yet established a secure key exchange, a plain exchange is prone to a MitM. So you utilize a trusted entity (CA in PKI, KDC in Kerberos) that vouches for authenticity of the exchanged public keys by way of certificates (see below). Asymmetric crypto has the great advantage that a certificate, once issued, can be reused many times for many communication peers. Compare that to the symmetric case where you cannot reuse Kerberos tickets - that's one of the reasons why certificates have a much longer life time than Kerberos tickets. The only problem that remains is how to establish a secure channel between A and CA and B and CA. This cannot happen ad-hoc in a trustworthy way, which is the central point of your question. So it seems that by utilizing a CA you have just moved the problem around without any progress (even worse, you introduced a new critical dependency), but there is one important difference: You need to establish a secure channel only with one trust anchor - which makes the problem feasible in the first place. You need to take a special route to establish trust between you and a trust anchor. This can be by meeting in person or other suitable out-of-band mechanisms. In Windows Active Directory environments this is you being authenticated on a computer joined to a domain using your credentials. The trick here is to design the process such that it scales well. However, there are still many leaps of faith to make: In principle, a public-key certificate works like any other kind of certificate, including the ones in the real world. 1. If some authority A asserts some property $$\mathsf{Property}(X)$$ for some $$X$$ 2. If A publishes the assertion in a kind-of unforgeable way 3. If some entity Y trusts A then Y has virtually no choice but to believe that $$\mathsf{Property}(X)$$ is true. For public-keys in a X.509-style PKI that means, A is a CA, $$\mathsf{Property}(X)$$ is a claim along the lines of "the key $$K^\mathsf{pub}_X$$ herein belongs to entity $$X$$" and the unforgeable way is via secure digital signatures with adequate key-lengths (for simplicity, I assume that all relevant algorithms are implemented flawlessly...). Moreover, each of the following conditions are crucial: 1. Y needs to have a genuine copy of CA's public key. 2. CA must be trustworthy, which means, they know what they do and they are not corrupt or being corrupted themselves. 3. All devices involved are trustworthy (i.e. not infested by trojans, backdoors and such) Each of those is quite tricky and hard to achieve - if at all. ### Acquiring a public key in a trustworthy way I think this is the issue that gave rise to the question. Since anyone can create arbitrary key pairs and from this, create arbitrary certificates, the trick is to distinguish between the wheat and the chaff, i.e. to tell genuine and fake root certificates apart. This can be done by secure channels, but for that you need some kind of trustworthy "seed". For instance, if you consider how the Web Of Trust works, particular the legendary PGP key signing parties, all involved attendees meet in person and mutually check photo IDs (another brand of certificate...). However, that does not scale. On the other hand, if you consider how root certificates are distributed in web browsers and operating systems, you find that you depend on the software vendors. Now, once upon a time there was the vision of a global PKI with one ultimately trusted root, where a copy of the public key or digital fingerprints thereof would be virtually everywhere posted (e.g. in printed publications). Of course, there was/is no agreement conceivable on who that could be, and thus this position remains vacant. Well, not quite, the software vendors silently filled that vacancy, and this seems to be accepted on the ground that there is nothing better in sight for the moment, and somehow, this seems to work (but see below). Closed organizations like enterprises and government bodies are a special class of cases - whenever you enter the organization, you get your PC, your accounts, and alongside you get your key pair and the public key of the organization root CA (more precisely, this is typically stored in the Windows Active Directory, where the AD architecture with its protocols like Kerberos provide the secure channel). ### CA trustworthiness Running a root CA properly is not easy, especially since they are very attractive attack targets. You need detailed procedures, background checks of the staff, regular training, suitable rooms, etc. etc. etc. And yes, there are audits by the browser forum and possibly other bodies, but the famous glitches of Commodo and DigiNotar show how hard it is to run a CA properly. The humorous application of "Honest Ahmad" for a root certificate sheds some light on the weaknesses of the whole construction. ### Device trustworthiness This is another property that is hard to achieve. General-purpose hardware with general-purpose OSes allow you to install any software that you want - and coincidentally, any software that you don't want, including malware. The average textbook describes an encryption process (say) as Alice encrypts message M with her key K or something like that. But who is Alice? If that refers to a person, then the statement is to be read as Alice instructs her computer to ... . Given the Trojan malware that we saw in the past (particularly Trojans for "alternative" online banking) it is easy to conceive that the computer does something quite different than intended or expected while pretending otherwise. ### Now what? To be honest, nobody knows. Bruce Schneier and others have written a lot about that. But as far as I know (I am not closely watching, though) the whole construction was never thoroughly contested in the courts. Until then it holds what I said earlier: The existing architecture somehow works, despite the many leaps of faith you have to make, and alternatives that are widely accepted are not in sight. I would like to address Maarten Bodewes' answer. Although Extended Validation (EV) certificates, in the past, may have improved the legitimacy of the website you're browsing by requiring further human identity verification, this does not mean that it hasn't been exploited for phishing. One downside of EV certs is the human verification part: human are prone to make mistakes, a simple less experienced worker may accidentally issue an EV cert meant for phishing a less well-known company. Another is a law that allow similar names for companies operating in different field of businesses, or similar names for companies operating in different countries/state. This can be prominently seen in Troy Hunt's (creator of Have I Been Pwned) post: Extended Validation Certificates are (Really, Really) Dead. A company in country/state X (example, James Food) may operate a similarly named company in country/state Y (James Foods), or a company operating as a food chain (Ben's) in country/state X may have a similarly named company operating as a hotel (Ben's hotel) in the same country/state. There's no way to solve this problem, except changing the laws nationally or internationally. Further adding to problem is the cost of EV certs: although EV cert sellers such as Comodo CA lists prices for multiple domains at a flat rate of US\$398/year, the prices increases for each additional domain at US\\$139/domain. This is especially costly for large websites that have multiple subdomains, and impossible for websites using a wildcard and offering subdomains as part of their service (for example, userX.wordpress.com or userX.github.io).

Browsers such as Google Chrome, Firefox, Safari and Edge are also removing EV indicators on the browser due to the above problems (giving a false sense of additional security) as given by Firefox's development forum: Intent to Ship: Move Extended Validation Information out of the URL bar

• The problems with the EV concept were fundamental and obvious from the get go, as anyone with even average understanding of security would have seen by reading the commercial "pitch" of EV vendors: they introduced EV as a "high quality" = "we will really really check the information before giving a cert" which was actually the whole point of the certs in the first place, so they were really writing "we will do our jobs if you pay us more". So it was very clearly a commercial thing not a security oriented thing, or they wouldn't have implied that they would still sell defective products. – curiousguy Dec 7 '19 at 18:48

This is an insightful question, and correctly focuses attention on the hard part of the problem.

One part of the answer is that the Certificate Authority can be more stringent than an ordinary user would be in verifying things since that's their whole job.

For the Web PKI (certificates used by web sites and most stuff you use on the Internet) there are agreed rules often called the Ten Blessed Methods for how the Certificate Authority does this. You definitely wouldn't want to be bothered to conduct any of the Ten Blessed Methods every time you visit a web site, even the relatively simple ones like sending an email and then waiting for the site's owner to click a confirmation link so you know it's really them would be impractical if everybody had to do them just to visit a web site.

CAs are allowed to go beyond these rules and be even more thorough. For example the popular Let's Encrypt service has discussed using an approach in which their verifications would happen near simultaneously from multiple perspectives around the world so as to avoid attacks where a bad guy impersonates your web site only as far as the Let's Encrypt servers are concerned on the West coast of the USA.

And some methods can be further protected with cryptography rooted in the DNS system, DNSSEC, so that imposters would need to break into a Domain Name registrar to get certificates for any names registered through it.

But it is certainly true that what a CA is doing is ultimately only a more thorough version of investigations you could do yourself, the main benefit is that every user gets to benefit from the verification happening just once. If bad guys are able to trick the verification process (and it certainly does happen in some cases) then the system is indeed defeated.

For sites at most risk of such an attack, there is one final line of defence these days - the Certificate Transparency system. Browsers including Chrome and Safari won't accept certificates without proof of publication to the CT logs, and those logs are open to public inspection. So for a site that feels it's at risk of impersonation there's the option to monitor those logs for unexpected certificates so that action can be taken urgently if any are seen.

• What "thorough version of investigations" is done systematically? – curiousguy Dec 12 '19 at 0:32
• As far as I know, the only real investigation that any CA does is probing for the server certificate from many remote locations which makes MitM attack harder. Some "EV" certs may require faxing letterheads but the CA does not know how any letterhead should look so this is just social engineering requirement for an attacker. – Mikko Rantalainen Dec 13 '19 at 6:41
• curiousguy - as an example, Bob wants a certificate from Some CA for his web site bobs-plumbers.example. Method 3.2.2.4.4 Constructed Email goes like this: Some CA looks up the WHOIS records for bobs-plumbers.example and sees that the contact is bob@example.com so they deliver an email to bob@example.com with a code in it and a verification link to the Some CA web site. Bob gets the email follows the link and copy-pastes the code. Some CA has now verified that Bob - the owner of bobs-plumbers.example - wanted this certificate. – tialaramex Dec 14 '19 at 18:53

There are several great answers here that give a lot of information about the PKI system and Certificate Authorities in general, but none have specifically answered the question, "who vouches for the Certificate authority?"

The answer to that question is that the Certificate Authority (CA) vouches for itself through a comprehensive annual audit. The audit verifies that the CA meets or exceeds the regulations and standards that are established by the Certificate Authority / Browser Forum (CA/B Forum), which is a collection of CAs, Browsers, and other interested parties. The CA/B Forum works together to establish guidelines for issuing digital certificates for websites, code signing, and other uses.

A Trusted CA will have seals on their website to indicate that they are a SysTrust or WebTrust certified website. To quote the explanation that appears when you click the on the seal, "the applicable SysTrust or WebTrust Seal of assurance symbolizes that [the] site has been examined by an independent accountant. Further, the Seal represents the practitioner's report (see below) on management's assertion(s) that the entity's business being relied upon is in conformity with the applicable Trust Services Principle(s) and Criteria.

"The Trust Services Principles and Criteria is an international set of principles and criteria for systems and electronic commerce developed and managed jointly by the American Institute of Certified Public Accountants and the Canadian Institute of Chartered Accountants. By demonstrating compliance with Trust Services criteria through an examination by an independent practitioner, entities earn the right to display the seal of assurance."

While each operating system, browser, and even hardware/software manufacturers can have their own Trust Store of approved CAs, with their own criteria foe entry into said trust stores, they almost all require that any Certificate Authority that wants to be listed first obtain an unqualified audit report, which indicates that the policy and procedures of the CA are being followed in conformity with the AICPA/CICA WebTrust for Certification Authorities Principles and Criteria, as per CA/B Forum regulation.

TL;DR: There is a set of industry regulations that all CA's must meet. To prove they abide by these regulations the CA undergoes an annual audit, the results of which are available on that CA's website via the WebTrust Seal.

There have been several cases where root-CA had been compromised. But one part of the whole mechanism is that the root-CA work in a network together. Their CA-ability hangs on held certificates of trust, signed by other root-CA. As soon as it became apparent that one of the CA wasn't trustworthy the very same mechanism "kicked" them out, as the certificates signing the trustworthiness of the root-CA in question were declared invalid. Thus in turn the certificates of that special CA became invalid .. problem fixed by self-correcting organization, although it took some time to propagate through the internet.

• Yes, when a CA is caught red-handed, it might get a slap. But in many cases rogue certificates escape detection (who keeps a log of the certificates one's devices come to trust). And should that be detected, a competent CA will have hard-to-contradict (perhaps even true) demonstration that they followed their policy. I would not be the least surprised to learn that a competent Three Letters Agency (four where I live) can obtain a valid certificate for anything in a snap. – fgrieu Dec 6 '19 at 11:44

My answer is: nobody. The various public CA either do not guarantee anything or have a rather limited guarantee. As for the certificates stored in your browser, I don't think it would be too difficult for hackers to install a fake certificate of their own. The public PKI/CA structure is in my opinion "better than the alternatives" but not much more than that. A tightly controlled private PKI, such as is used by banks and other organizations, is much better.

Yes, as others have explained, there are (essentially) a set of public keys of "trusted" authorities pre-loaded into your browser.

Let me add a couple of points that have not already been discussed.

One important question is: who decides which CAs are "trusted"? The answer is that, for most general users, this is determined by the browser vendor. And the CAs that the browser vendors think should be trusted may not be the same as the CAs that the end user actually wants to trust. So you can review and change the list. Many organizations' IT departments will configure end users' machines with a different set of trusted CAs. This is quite common, for example, in government and military organizations.

Also, your question about MITM attacks is quite valid. In fact, some organizations will configure end users' machines with a trusted CA specifically to enable a MITM inspection of traffic going to and from the internet. This allows them to open and inspect all traffic, even if it's encrypted with TLS. If this is done, the organization should tell their users that their communications is being monitored.

In the scientific community CAs are under scrutiny of the IGTF: Interoperable Global Trust Federation. The IGTF sets the rules for how CAs operate, and CAs that are trustworthy get accredited. Trustworthiness is determined through audits. The IGTF regularly compiles a list with accredited CA's root certificates that you can download and install. Untrustworthy CAs get booted from that list. The IGTF is organized in regional PMAs (Policy Management Authority);

• TAGPMA for North and South America
• EUGridPMA for Europe, Africa, Middle East
• APGridPMA for Asia Pacific region