2

See here: https://www.cacert.org/index.php?id=1

Chrome, Firefox and Internet Explorer warn that it is not trusted, essentially making the entire thing useless. If I want some kind of ssl certificate, I can just as well create my own with makecert.exe, the effect would be the same, wouldn't it: every browser would warn with huge red letters that it's not valid.

What am I not getting about this system?

Blub
  • 165
  • 1
  • 4
  • http://wiki.cacert.org/InclusionStatus – symcbean Apr 09 '14 at 08:48
  • 1
    alright, so this is essentially a "lets band together and try to make ssl certs cheaper for everyone by lobbying to have ours included / us trusted as a root CA" – Blub Apr 09 '14 at 08:54
  • 1
    the SSL is a technologie that tend to encrypt, insure data consistency and **Authentify with a third party the source of the service** so you're are sure not to speak with someone usurping a website. If you can't have a third party that validate the certificate only the 2 first goal are accomplish but you can't be sure that you're on the real website – Kiwy Apr 09 '14 at 09:14
  • Kiwy, I think that is clear, the point is that many 3rd parties are trying to be seen as "trusted" root CAs, and until they are, they are rather useless to everyone. – Blub Apr 09 '14 at 11:22

2 Answers2

4

One theory is that, ideally, the end-user should manage his own store of trusted root CA, making an informed decision based on the published Certification Practice Statements by existing CA.

Theory and practice match only in theory, though. It is not surprising that most users cannot and will not handle such a management process, if only because it relies on highly technical concepts (not only cryptographic concepts, but also and most importantly legal concepts). Therefore, OS and browser vendors take it upon themselves to decide on a list of "default root CA" that they will put in their browsers, and will be trusted by the overwhelming majority of deployed clients. These vendors do that as part of relatively complex procedures with heavy requirements on the CA, e.g. insurance and detailed procedures in force at the CA side. (See this answer.)

Right now, CAcert is a "wannabe" CA which tries to become a "trusted CA by default", but has not yet reached wide acceptance by OS/browser vendors. Part of the problem is that procedural requirements for a secure CA have a strong financial counterpart: the physical security requirements are not cheap (you won't put a serious CA "in the cloud"; you need secured premises), and the CA must demonstrate that it has the means to keep on working for a long time, or at least to do a "clean closure" in case of cessation of activity. Money is the key. The CAcert stance of "let's give away free certificates" does not help in making enough money for that.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
1

Consumers of the service you are attempting to authenticate with certificates provided by such an "untrusted" third party might be more willing to install the root certificate of some independent party in their trust chain, vs. some one-off root CA that you have created just for your service.

In such a case, cacert (or equivalent entity) assumes the burden of trustworthiness, just as VeriSign or COMODO would; they simply aren't trusted implicitly by your consumers' OSes or browsers.

Ben Mosher
  • 126
  • 4