It is often cited as a primary point of concern that a single compromised CA can make for significant damage, as all websites (and other entities) that rely on this CA cannot be trusted anymore.

Pardon my ignorance, but why do we not require websites to be validated by, say, 3 certificates of independent CAs? Only if a majority of the certificates agrees on the websites validity, it would be considered acceptable. This seems to solve the above problem to a large degree.

  • If a certificate is issued without proper justification by a single CA, this would not make a website accepted. Only two compromised CAs at the same time could do this.
  • If a CA is not trusted anymore, websites which rely on it still work, as they are validated by two other CAs apart from the one that fell off. This means it is easier to revoke trust in a CA without 'breaking the internet'.

Obviously, such an idea would lead to additional work. But seeing as time and money spent do not increase linearly, this could be acceptable.

It is also easy to run this pattern in parallel to traditional infrastructure, as websites could specify either one or three certificates, and the new rules (and bonuses) would only apply to them.

  • 4
    Interesting question. So far the main defence against a compromised CA is certificate pinning. Worth reading up if you're not familiar.
    – paj28
    Sep 29, 2016 at 11:34
  • 2
    What would have prevented an attacker from downgrading a three certs server to one cert server? How does the server communicate to the client that it should only accept three certs?
    – Lie Ryan
    Sep 29, 2016 at 13:18
  • 1
    @LieRyan Some kind of reliable mutual reference between the certificates in the certificates themselves would not suffice, if I'm not mistaken. So we would need some kind of repository containing all sites which opted in to the 3-way certification. That pattern sounds familiar... is what you're saying?
    – mafu
    Sep 29, 2016 at 16:20
  • 1
    "3 certificates of independent CAs" how is browser supposed to judge their "independence"? By root cert sn? By dn? By CA owner? By CA owner's owner? By country of CA owner's owner's owner? I provide three Chinese root certs - are these independent or not?
    – kubanczyk
    Sep 30, 2016 at 8:28
  • 1
    @LieRyan The problem asks why not require websites to use multiple certificates. If websites are required to use 3 certificates, browsers won't accept fewer certificates.
    – v7d8dpo4
    Oct 1, 2016 at 11:36

3 Answers 3


why do we not require websites to be validated by, say, 3 certificates of independent CAs?

Here are a few reasons:

  1. Cost. Purchasing certificates is already somewhat expensive*; tripling that expense - and forcing purchasers to wade deeper into the pool of potential CAs, where they usually start at the cheap end - would not be welcomed.

  2. Complexity. Currently, if a certificate expires, the site is offline or degraded until IT can scurry around and fix it. It happens surprisingly often given that expiration dates are known and can be planned for. Your proposal would triple the number of certificates that need to be installed correctly, that need to be replaced before expiration, that need correct certificate chains... Some of this stuff is hard enough today with just one CA!

  3. Compatibility. The TLS protocols do not specify a method of operation where multiple certificates must be validated, so you'd have to update or replace the protocol being used, which will take years. There's no way to specify to the client that this particular server requires multi-certificate validation, so downgrade attacks are trivial - again, you'd need to create a method, and then wait years for support to percolate out.

  4. Certificate Pinning. Your idea says "Let's assume the CA model is broken, and as a solution increase our dependence upon the CA model." If one CA can be compromised, why not two (assuming a 2/3 majority wins in your model)? At that point you'll start saying, "Well, obviously we want to trust Entrust more than the Consolidated Republik of Tadpolistan" - at which point you've reached Certificate Pinning, which is already a thing.

  5. WoT else? The other natural conclusion you'll reach, when you decide that some CAs are more trustworthy than others, is that there should be a method of incorporating reputability. This is called the Web of Trust, and is a competing model to the Centralized Trust of CAs today. One implementation of the WoT method is the Perspectives Project, which is an interesting approach to the same problem you describe (and which works in complement to, and in compatibility with, the existing CA model).

* Before someone jumps up and says "Startcom!" or "Let's Encrypt," please remember that businesses drive the CA model today. They pay significant amounts of money, and some of them purchase thousands of certs annually. The cost impact needs to be considered against all players. (And even on the low end, if you want a free cert, now you would have to find 3 reputable free providers, when finding one was already a challenge.)

  • 13
    "If one CA can be compromised, why not two" - that seems a poor argument to me. CA compromises have happened, and a system that protected against that would be useful.
    – paj28
    Sep 29, 2016 at 13:55
  • 4
    @paj28, I concur that a system that protects against it would be useful... I just disagree that slathering more of the same on top is a well-designed protection.
    – gowenfawr
    Sep 29, 2016 at 13:58
  • 1
    After an aeroplane crash the safety investigation often causes recommendations to be made to prevent the same crash happening again. Yet, you would say that since aeroplane crashes still happen, we should stop doing this? (E.g. carrying certain types of flammable goods in certain types of cargo holds is prohibited, but someone did that and they caught fire, so now we require fire suppression systems in those types of cargo holds)
    – user253751
    Sep 29, 2016 at 20:45
  • 2
    So you're telling me I should start a business that automatically alerts sites when their certificates are expiring? Sep 29, 2016 at 21:36
  • 2
    @gowenfawr Of course that was not the point, the point was the attitude of "if it can fail, adding more will just make it fail less often, so don't bother" is stupid, because it assumes that a system that fails less isn't any better.
    – user253751
    Sep 30, 2016 at 3:57

RTLS neither supports multiple leaf certificates for a single session nor X509 supports multiple issuers for a single certificate. This means there will be changes necessary on the protocol. But lets just ignore the effort to make such changes and look how much more security we get with your proposal. Lets have a look how a bad certificate might get issued, in which situations your proposal helps and how it compares to existing proposals.

How the attacker can get a certificate

A bad certificate can be issued if the CA is compromised by the attacker, i.e. is buggy, hacked or if the CA employs untrustworthy people. In this case your proposal would help because you hope that not all of the multiple CA's have these problems at the same time. Of course this is not that simple, because you better make sure that the different CA's are actually controlled by different entities and run different code, i.e. that a single hack is not actually a hack of multiple CA.

But an attacker can also get a certificate by compromising the domain validation process. This process works similar for all CA and if the attacker gets access to the mail of the domain owner or the server he might manage to get a certificate for the same server from multiple CA's. In this case your proposal would not help at all. But of course in this case the hacker would only get access to a few certificates for badly secured domains, while in the case of a CA compromise he might get lots of certificates even for domains with good security.

What alternative proposals exist

With certificate or public key pinning (HPKP) a domain owner can make sure, that the certificate uses a specific public key. With HPKP is effect the attacker would need to get access to the private key of the existing certificate, i.e. hack the server. This protects domains with good security against misuse of certificates the attacker created by compromising a CA. The nice thing about HPKP is that it is cheap and easy to roll out and that it is already supported by major browsers.

Certificate transparency is a public log which can be used to find out if a CA issued a certificate which it should not and if a CA is aware that it issued a specific certificate. This can be used by the domain owner to check for rogue certificates. While not all CA's have such logs yet the number is growing because the browser vendors push the support as a requirement to be a trusted CA. For now Chrome requires all EV certificates (green bar) to be covered by such a log and some other CA are also required to issue such logs since they showed to have insecurities in the past. The nice thing is that supporting browsers like Chrome know which CA should have such a log and can check against it.

DANE makes it possible for the domain owner to publish its own certificate in the DNS without the need for CA. Of course this has to be somehow protected against DNS spoofing so it needs DNSSec. DANE can be used both with self-signed certificates instead of using a public CA or with CA signed certificates as an additional protection. While not currently implemented in the browsers it is already used for mail by several providers and support in this area is growing.


While your proposal would be useful to increase the security it needs major changes to the existing TLS protocol (serve multiple leaf certificates) or X509 model (multiple issuers for a single certificate). But at least optional multiple certificates are probably possible to implement with the help of TLS extensions, so we don't need to new TLS version for this. It will increase the data transferred in the full handshake though (lots of leaf certificates and chain certificates) which slows down the handshake.

The alternative proposals don't need such protocol level changes since they work outside the TLS protocol. Also, in the case of HPKP and DANE they provide more control over the certificate to the domain owner than your proposal.

But at the end all of these ideas could in theory be used together to increase the security. And while your proposal would increase the security it is probably more disruptive than the others and would cause more costs, and that's why the others are preferred for now.

  • Of course each if the listed technologies gave drawback themselves. Dane lack browser interest and DNSSEC deployment. CT is quite centralized and doesn't really scale well for automated verification by everyone. And for HPKP there's this blog post.
    – SEJPM
    Sep 29, 2016 at 20:12
  • 1
    @SEJPM: nearly all TLDs now supports DNSSEC. The actual DNSSEC deployment varies by TLD though. Most European TLDs have around 50% of DNS record signed, while only 1% of .com is signed.
    – Lie Ryan
    Sep 30, 2016 at 10:50

What you propose would indeed increase security, but at an increased administrative cost and technical complexity. I think CA compromises are simply too rare events to justify those costs. Also, if a similar scheme will be put in practice, it will probably be more elaborated than simple 2 out of 3 voting. For example, having only two certificates, one valid and one aged away, should be enough to confirm the identity while protecting against single CA compromises.

You must log in to answer this question.

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