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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Matias Britos
  • 351
  • 3
  • 3
  • 6
    Correct. The concept of "CA" does not scale well. See the answer by makerofthings7 for brief comments on mitigation. – Bob Brown Feb 14 '15 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 '15 at 00: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 '15 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 '15 at 13:31
  • 1
    Related on Super User: [How to know which Certificates to leave in my browser, and which to remove](http://superuser.com/questions/818065/how-to-know-which-certificates-to-leave-in-my-browser-and-which-to-remove) – dotancohen Feb 15 '15 at 18:23
  • Yes, nothing, and yes. – Ajedi32 Feb 16 '15 at 15:19

4 Answers4

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.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
23

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).

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 1
    +1 While the other answers are interesting, I think that this most directly answers the OPs question. – zelanix Feb 16 '15 at 15:21
  • There should only be one CA in the world then. Maybe just two, to prevent monopoly. – Pacerier Feb 16 '15 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. – David Houde Feb 16 '15 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 '15 at 04:05
  • Exactly. This is not a solution to the problem. – David Houde Feb 17 '15 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:

Community
  • 1
Ben Voigt
  • 760
  • 1
  • 10
  • 17
  • 9
    Not if the CA is "too big to fail". – curiousguy Feb 14 '15 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 '15 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 '15 at 21:44
  • @BobBrown: That's part of #1. I'll clarify. – Ben Voigt Feb 14 '15 at 21:47
  • @BenVoigt: *Now* it is, after you've edited your answer. {grin} And it's not a "fake" certificate at all; it's just as valid as the one the domain owner paid for, but probably issued for a nefarious purpose. *That* is the essence of the problem. – Bob Brown Feb 14 '15 at 21:53
  • 1
    @BobBrown: No, the window of vulnerability was the only reason I put a "time passes" step in there to begin with. And I'll use the word "fraud" instead of "fake". It is a fake certificate, although that cannot be detected via purely technical means, because it appears valid. – Ben Voigt Feb 14 '15 at 21:54
  • 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 '15 at 13:27
  • 1
    @kasperd: For a "too big to fail" CA, a certificate will lose trust in the browser, but it won't be the CA root. Instead the intermediate certificate immediately used to sign the fraudulent certificates will be blacklisted. And this will affect other sites. Also, when users see a "This site is not secure" message, their first action is not going to be to throw away the browser. Remember that it doesn't fail mysteriously, there's an explanation shown, with a link to the browser vendor's site, where the betrayal of trust by the CA will be explained. – Ben Voigt Feb 15 '15 at 18:41
  • 4
    "All the other webmasters who bought certificates from that CA sue." Has this ever happened? – Matthew Flaschen Feb 15 '15 at 23:21
  • 1
    @MatthewFlaschen I recall once having heard about a CA that did get removed from the trusted list in all major browsers. I did not hear about any customers suing the CA over it. And what would they sue the CA over anyway? After all it was not the CA, who removed the root certificate from the trusted list. – kasperd Feb 16 '15 at 07:52
  • @kasperd: IANAL, but I believe purchasers of certificates would have legal rights due to [Implied warranty: fitness for particular purpose](http://en.wikipedia.org/wiki/Implied_warranty#Fitness_for_a_particular_purpose) and [Implied warranty: Merchantability](http://en.wikipedia.org/wiki/Implied_warranty#Merchantability) – Ben Voigt Feb 16 '15 at 07:55
  • 1
    @BenVoigt Can you provide any documented case of that being taken to court? – kasperd Feb 16 '15 at 08:28
  • 1
    @MatthewFlaschen, kasperd: Only reason DigiNotar didn't get sued was they voluntarily entered bankruptcy first. And there was a lawsuit against the prior owners: http://www.telecompaper.com/news/former-diginotar-owners-ordered-to-refund-acquisition-price--1030855 – Ben Voigt Feb 20 '15 at 20:45
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.

Arc
  • 652
  • 5
  • 11