

CAcert.org – A community-driven Certificate Authority issuing free certificates - vecio
http://www.cacert.org/

======
dfc
I am curious why this was submitted now, especially in light of the recent
removal of cacert from Debian's ca-certificates package.[^1][^2] It seems that
the discussion of cacert's removal highlighted serious concerns about cacert's
process. A request to include cacert in mozilla's certs sat in bugzilla for
four years before it was--thankfully--closed.[^3]

[^1]: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=718434](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=718434)

[^2]: [https://lwn.net/Articles/590879/](https://lwn.net/Articles/590879/)

[^3]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=215243](https://bugzilla.mozilla.org/show_bug.cgi?id=215243)

~~~
rurban
No serious concerns. Just the typical overly debian knee-jerk reaction to
bring someone down by bullying "because we can" and not for technical merits.
There was no argumentation why cacert should be removed.

Maybe Assange was right? (I still doubt it, debian politicians are just as
stupid and like to abuse their powers as any other politicians are)

~~~
dfc
Argument: (In order of how persuasive I found the argument)

    
    
      1.  "There was no argumentation why cacert should have been included
          initially."  
      2.  No audit of CACert's process and infrastructure.
      3.  Mozilla and FreeBSD have had previous discussions and decided CACert 
          was unacceptable. (reliance-on/agreement-with)
      4.  Questionable license.

------
lawnchair_larry
Yeah, you don't want to use this.

~~~
rurban
You do want to support a non-commercial and community driven CA cert
authority, because you don't want to rely on commercial-only cert's which are
not based on technical merits, just on friendship and common business
interests.

You really want a free HTTPS connection to your favorite open source projects
login page, and do not force them to pay yearly CA update fees to not
trustworthy cert authorities for no reason.

Currently you need to add the cacert into your keychain on some distros
manually. See
[http://wiki.cacert.org/FAQ/ImportRootCert](http://wiki.cacert.org/FAQ/ImportRootCert)

~~~
abritishguy
Certificates are not expensive, they can be picked up for $5.

~~~
nomailing
5$ is expensive. Don't you know that there are other countries in the world
and that the Internet is not only used by the US. There are also other age
groups. If a 10 year old boy has a hobby website 5$ might be a price which is
unacceptable.

what would you say if I as a billionaire tell you that cars for less than 50
000 $ are not needed because all Ferraris are not expensive. So please don't
use your subjective experience as an argument against cheap security
solutions. They have a point to exist. Nobody should have the right to set the
lower limit of how much you have to pay to secure your website. Commericial
CAs cannot guarantee the security of your favorite site as we all learned from
the heartbleed bug. So there is nit argument to favor them and block community
solutions.

~~~
abritishguy
I'm not American, so yes I am well aware.

>If a 10 year old boy has a hobby website 5$ might be a price which is
unacceptable. Why would this site need SSL?

~~~
aragot
Because he has users and he wants to keep their private info under encrypted
channels?

Hobby sites quickly become apps (even as small as phpBB) and it would be good
if we SSL'd everything.

------
rakoo
A community-driven effort is always commendable, but we must ditch the whole
CA model, not fix it.

Proposed solution: use namecoin's _.bit_ domains [0], add TLS records, and use
dsnchain [1] as a bridge between DNS and namecoin to keep using our current
applications.

 _Disclaimer: I participated in dnschain_

[0]
[https://wiki.namecoin.info/index.php?title=Domain_Name_Speci...](https://wiki.namecoin.info/index.php?title=Domain_Name_Specification)

[1]
[https://github.com/okTurtles/dnschain](https://github.com/okTurtles/dnschain)

------
null_ptr
_www.cacert.org uses an invalid security certificate.

The certificate is not trusted because no issuer chain was provided.

(Error code: sec_error_unknown_issuer)_

~~~
thejosh
Yes, because it is self signed, and your OS/distro must have CACert.org's
certs to be able to verify.

~~~
ithkuil
Not technically correct a "self signed certificate":

A self-signed certificate is an identity certificate that is signed by the
same entity whose identity it certifies. ([http://en.wikipedia.org/wiki/Self-
signed_certificate](http://en.wikipedia.org/wiki/Self-signed_certificate))

The certificate certificates your identity, and it's signed by the certificate
of the CACert certificate authority.

The problem is caused by the fact that your browser/OS doesn't trust CACert's
certificate by default; each user would have to add it manually.

~~~
pharaohgeek
Also not technically correct. Root certificates -- such as the one that
provides the top-level of CACert's trust hierarchy -- are, by definition,
self-signed certificates. So, you're both right. The CACert root is a self-
signed certificate, which is not in the trust store of the browser.

~~~
ithkuil
Trust of root certificates is not obtained through signing. Browser or OSes
contain a key store which includes a bunch of CA along with a few flags which
define how should certificate signed by those CAs be trusted (e.g. sites, code
signing). So, by definition root certificates are not even self signed; they
are trusted by virtue of being included in some authoritative key store.

The comment was referring to the following error message: "www.cacert.org uses
an invalid security certificate. The certificate is not trusted because no
issuer chain was provided sec_error_unknown_issuer"

This error is reported when the CA is unknown; If the certificate itself was
self-signed the user would see:

"www.cacert.org uses an invalid security certificate. The certificate is not
trusted because it is self signed. (Error code: sec_error_untrusted_issuer)"

In this case the line is blurred because arguably both www.cacert.org and the
cacert CA is run by the same entity. But if you obtain a certificate for your
site, signed by cacert's CA, an arbitrary user will get
sec_error_unknown_issuer not sec_error_untrusted_issuer.

The distinction of those two cases is however relatively useless, and I'm
sorry I'm contributing into veering this topic into pure nitpicking. That
said, computers nitpick by definition, so it's always useful being able to
clearly understand what different sets of initial conditions will trigger a
different output (In this case "sec_error_unknown_issuer" vs
"sec_error_untrusted_issuer").

NOTE: if you add cacert's CA certificate to your key store but don't set the
appropriate trust flags, you will get "sec_error_untrusted_issuer"; this
obviously means that this error message is not a reliable way to determine if
a given certificate is self-signed.

------
abritishguy
The problem with a community driven CA is that there is no repercussions if it
is infiltrated. If one of the commercial CAs got hacked then they would be
removed as a trusted CA and their business would cease from that point on.
They have a commercial interest in being secure and therefore invest lots of
money in solutions to this (including expensive HSMs).

Certificates are not expensive - you can pick them up for $5.

I sell SSL certs for £35, every one of my customers could have got the exact
same certificate for £5 - they pay the extra for a well designed, intuitive
website that makes the process incredibly easy with great support.

Most of my customers hear about my site through word of mouth, I often give
out free or cost-price certificates to Open Source software or charitable
sites.

[https://www.volcanicpixels.com/ssl/buy](https://www.volcanicpixels.com/ssl/buy)

[https://github.com/volcanicpixels/volcanicpixels/](https://github.com/volcanicpixels/volcanicpixels/)

~~~
wiml
Experience shows that there are no repercussions [edit: usually no
repercussions] if a commercial CA is hacked, either (or even if it
intentionally issues fraudulent certificates).

~~~
abritishguy
That is simply not true:

[http://googleonlinesecurity.blogspot.co.uk/2011/08/update-
on...](http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on-attempted-
man-in-middle.html)

~~~
pornel
OTOH Comodo is still in business: [http://www.wired.com/2011/03/comodo-
compromise/](http://www.wired.com/2011/03/comodo-compromise/)

~~~
abritishguy
I was wrong.

~~~
mike_hearn
DigiNotar got revoked partly because they got hacked, but mostly because they
had zero acceptable followup. There was no good enough postmortem describing
their mistakes and how they would correct them, and they also engaged in a
coverup.

Browser makers do not engage in instant execution of any CA that makes a
mistake, because CA's are run by humans and to err is human. What they insist
on is coming clean when mistakes are made, and steps taken ASAP to restore
confidence, like publishing a real post mortem and making business changes to
ensure the same mistake can't happen again.

