5 ms·

CAcert.org – A community-driven Certificate Authority issuing free certificates

69 points by vecio 12y ago

dfc 12y ago
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 12y ago
  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 12y ago
    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 12y ago
Yeah, you don't want to use this.
- dfc 12y ago
  I thought it was a great idea for strengthening the gpg/gpg web of trust. Outside of debian there is/was very little in the way of organized efforts to improve the web of trust. However I do not think it is a great idea for browser certificates. At least not until there are serious improvements to the CA configuration UI and user education.
- thejosh 12y ago
  Reason why?
  - jlgaddis 12y ago
    Because he works for a CA.
- rurban 12y ago
  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 12y ago
    Certificates are not expensive, they can be picked up for $5.
    - rurban 12y ago
      Why should I pay a not-trustworthy company, when I can get one for free, from a widely respected and completely open sourced and community managed authority?
null_ptr 12y ago
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 12y ago
  Yes, because it is self signed, and your OS/distro must have CACert.org's certs to be able to verify.
  - ithkuil 12y ago
    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 12y ago
      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 12y ago
        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 12y ago
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 12y ago
  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).
  - dfc 12y ago
    Distrust Diginotar certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=682927 https://bugzilla.mozilla.org/show_bug.cgi?id=682927
  - abritishguy 12y ago
    That is simply not true: http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on-attempted-man-in-middle.html http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on...
    - pornel 12y ago
      OTOH Comodo is still in business: http://www.wired.com/2011/03/comodo-compromise/ http://www.wired.com/2011/03/comodo-compromise/
rakoo 12y ago
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_Specification https://wiki.namecoin.info/index.php?title=Domain_Name_Speci... [1] https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain

69 points by vecio 12y ago

dfc 12y ago

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 12y ago
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 12y ago
  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 12y ago

Yeah, you don't want to use this.

dfc 12y ago
I thought it was a great idea for strengthening the gpg/gpg web of trust. Outside of debian there is/was very little in the way of organized efforts to improve the web of trust. However I do not think it is a great idea for browser certificates. At least not until there are serious improvements to the CA configuration UI and user education.
thejosh 12y ago
Reason why?
- jlgaddis 12y ago
  Because he works for a CA.
rurban 12y ago
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 12y ago
  Certificates are not expensive, they can be picked up for $5.
  - rurban 12y ago
    Why should I pay a not-trustworthy company, when I can get one for free, from a widely respected and completely open sourced and community managed authority?

null_ptr 12y ago

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 12y ago
Yes, because it is self signed, and your OS/distro must have CACert.org's certs to be able to verify.
- ithkuil 12y ago
  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 12y ago
    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 12y ago
      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 12y ago

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 12y ago
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).
- dfc 12y ago
  Distrust Diginotar certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=682927 https://bugzilla.mozilla.org/show_bug.cgi?id=682927
- abritishguy 12y ago
  That is simply not true: http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on-attempted-man-in-middle.html http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on...
  - pornel 12y ago
    OTOH Comodo is still in business: http://www.wired.com/2011/03/comodo-compromise/ http://www.wired.com/2011/03/comodo-compromise/

rakoo 12y ago

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_Specification https://wiki.namecoin.info/index.php?title=Domain_Name_Speci... [1] https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain