35

Can any CA sign any cert for any domain?

If the answer is yes, what prevents having two different CAs creating a valid cert for the same domain?

Does that mean that the whole TLS security has the same level of security of the least secure CA?

6
  • 6
    Correct. The concept of "CA" does not scale well. See the answer by makerofthings7 for brief comments on mitigation.
    – Bob Brown
    Feb 14, 2015 at 15:39
  • 3
    Some large sites actually have multiple versions of their certs signed by different CAs for various reasons (usually changing pricing) and with a wide enough server base this can cause legitimate uses of multiple-CA signings. This happens a lot with amazon.com due to their extremely vast infrastructure, for example.
    – fluffy
    Feb 15, 2015 at 0:29
  • 1
    Yes, but bear in mind that becoming a 'trusted CA' isn't that easy. You could quite easily write your own CA (self signed certificates, basically). These are sufficient to enable encryption, but not enough to verify identity. Getting your CA trusted means proving it should be.
    – Sobrique
    Feb 15, 2015 at 12:30
  • 4
    Yes, security of TLS really does have the security of the least secure CA for exactly the reason that you mention. This is the main problem addressed by validation of certificates through DNSSEC rather than CA infrastructure. Sounds like DANE is the approach most likely to get widely adopted.
    – kasperd
    Feb 15, 2015 at 13:31
  • 1

4 Answers 4

30

Mostly yes, any CA in your trusted root, (or subordinates) can issue a cert for any DNS name.

Name constraints and Enhanced Key Usage can be used to mitigate this, but they aren't enforced everywhere.

DANE, Certificate Pinning, and Certificate transparency are a few projects that help protect from this risk.

24

Can any CA sign any cert for any domain?

In general, yes. Trusted root certs are trusted for anything under the root.

If the answer is yes, what prevents having two different CAs creating a valid cert for the same domain?

Nothing - it's completely legitimate for you, the owner of example.com, to go get a certificate for www.example.com issued by a collection of CAs: Comodo, Entrust, Thawte, whoever. (You usually wouldn't, because it's additional expense with no gain to you, but there's nothing that stops you. This situation usually arises when an organization wants to transition from using one CA to another; during the cutover, they'll usually have valid certs from both CAs for the same set of names.)

Your true concern here is "what prevents a fraudulent certificate from being issued by CA X when a valid certificate is already issued by CA Y". And in this case, the problem is not that a cert can be issued by multiple CAs, it's that a cert can be issued fraudulently. The purpose of "trusted CA" is that you trust the CAs to be diligent in issuing certs to valid and not to unauthorized purchasers.

Does that mean that the whole TLS security has the same level of security of the least secure CA?

Yup! (Unless you're pinning). It's a legitimate weakness of the CA system. (And the weakness here, to be clear, is that any one CA can be tricked or evil and issue certs that don't belong - not that they can do so if a cert in that name already exists).

5
  • 1
    +1 While the other answers are interesting, I think that this most directly answers the OPs question.
    – zelanix
    Feb 16, 2015 at 15:21
  • There should only be one CA in the world then. Maybe just two, to prevent monopoly.
    – Pacerier
    Feb 16, 2015 at 20:05
  • @Pacerier What exactly would a single CA resolve? PKI would still be as weak as the weakest CA and certificates can still be issued more than once. I don't see how this helps anything. Feb 16, 2015 at 22:23
  • @DavidHoude, The weakest CA wouldn't be weak if there's only one CA in the world, since it's also the strongest CA.
    – Pacerier
    Feb 17, 2015 at 4:05
  • Exactly. This is not a solution to the problem. Feb 17, 2015 at 19:20
16

It's prevented through legal (contractual) and not technical means.

What happens if a CA creates an certificate which is not duly authorized by the legitimate domain owner:

  1. Time passes, with users unknowingly trusting the fraud.
  2. Somebody notices and reports it.
  3. Browser vendors remove that CA's root certificate from the next update to the trusted list
  4. All the other websites using certificates from the CA start triggering "Site is encrypted but not secure" messages to users.
  5. All the other webmasters who bought certificates from that CA sue.
  6. CA goes bankrupt.

This has happened before:

13
  • 9
    Not if the CA is "too big to fail".
    – curiousguy
    Feb 14, 2015 at 21:11
  • 2
    @curiousguy: Then replace steps 5 and 6 with "CA pays overtime to all its engineers to give free replacement certificates to all its other customers, reports a multimillion dollar direct loss, and suffers an even larger loss due to customers taking their business elsewhere following the bad press"
    – Ben Voigt
    Feb 14, 2015 at 21:13
  • 1
    7. In the mean time, browser users are subject to man-in-the-middle attacks, especially if the CA is run by a repressive government.
    – Bob Brown
    Feb 14, 2015 at 21:44
  • 5
    @BenVoigt I think your answer to the "too big to fail" scenario is inaccurate. In the case of a "too big to fail" CA, step 3 is unlikely to happen. No browser vendor want to go first, because if one browser vendor remove a major CA from the trusted list, then users will find that a lot of sites stopped working with that browser but keeps working in other browsers. Most of those users will blame the browser and switch to one which "works".
    – kasperd
    Feb 15, 2015 at 13:27
  • 4
    "All the other webmasters who bought certificates from that CA sue." Has this ever happened? Feb 15, 2015 at 23:21
6

Others have mentioned mitigation techniques, here are some examples:

Questionable Compromises

  • Antivirus manufacturers like Kaspersky frequently install a CA in order to "protect" you by eavesdropping on all your connections, including SSL links.

  • In February 2015, media covered the SuperFish adware / malware deliberately installed by Lenovo on its computers*.

    It comes with a CA certificate and key to dynamically issue host certificates.

    One major issue here is that the CA is not only installed on your computer but it is part of the software and thus the same for all computers.

    EFF found thousands of certificate counterfeits via HTTPS Everywhere / SSL Observatory (see below).

    Want to gift SuperFish users with signed software or valid SSL sites?
    Here is the key and cert to do it, along with a story how it was "open-sourced". Hurry up, Microsoft etc. are sending out updates to clean this mess up.

  • Fiddler is an HTTP proxy with SSL interception capability. It will install a CA certificate to tap into encrypted links.

  • Some companies or their firewalls intercept encrypted traffic to detect intrusions and data leaks, or to spy on their employees. Usually corporate computers and mobile devices will come with the company's CAs, so you will not get any warning unless you visit a certificate-pinned site.

Other than those, fake certificates for big sites like Google, Facebook or iTunes have been found in the wild in recent years.

Mitigation

  • Chrome and Firefox have some certificates pinned out of the box, e.g. Google sites in Chrome, Mozilla sites in Firefox and major sites like Twitter (browser-dependent).
  • Certificate Patrol for Firefox pins /stores site certificates and warns you whenever those change.
  • Microsoft's EMET also pins some site certificates since 4.0.
  • HTTPS Everywhere from EFF has an "SSL Observatory" function where SSL certificates are crowd-compared to see if there is something fishy going on. Besides this, it enforces HTTPS/SSL on some sites.

Also, EV (extended validation) certificates - those that display a green lock or a green address bar in major browsers - were invented to profit from and exploit that flaw in the certification system and the related FUD.

EV CAs are not user-editable, in contrast to regular certs, and issuers and browser vendors promise to apply higher validation and security standards for those.

However, this is still just convention, little more.

You must log in to answer this question.

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