CAcert.org – A community-driven Certificate Authority issuing free certificates | Hacker News Reader

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

cacert.org

69 pointsvecio41 comments

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

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

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

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)

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.

Yeah, you don't want to use this.

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

I do not want to support a non-commercial and community driven CA cert authority[sic] that does not meet commonly accepted CA audit requirements.

My favorite open source project's login page can use self signed cert. I can download the ssl.key.asc or project.crt.asc that the project publishes on the web page or git repository and verify the signatures using the same gpg key I use to verify the project tarballs.

None of what you are saying actually matters (regardless of one's position on those issues), because it's trumped by the fact that if you use cacert, users can't reach your site. It's wrong to defer this problem to the user, always.

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

They can even be picked up for free.

At least one commercial CA issues free certificates as a matter of routine and (unlike CAcert) has its root certificate in all major OSes and browsers.

Alternatively, if you already have a paid cert then some providers offer a free cert via 'competitive upgrade' programmes, if you switch to them (rather unethically, this also used to work to freely upgrade short-term trial certificates to full ones).

Startcom charge for revocations though, which IMO is a very bad thing.

They do, but I'm not convinced that it matters - I'd be very surprised if there's any overlap between websites that use the free StartSSL cert, and websites that are worth the effort of hijacking the cert and MITMing.

Where would this be? And do they attempt to charge money on things that really don't need it? I.e. rekeys and renewals? What about wildcard domains? The same damn cert with a *. instead of a domain. shouldn't cost 10x more.

I sell certificates: https://www.volcanicpixels.com/ssl/

You can get the same certificates for much cheaper here: https://www.thesslstore.com/

The certificates are absolutely identical, my customers use my site because it is well designed and easy to use and I do everything I can to provide great support, but if you know exactly what you are doing then I would recommend getting them directly from thesslstore - unless you have a desire to help pay for my uni education ;)

Thanks for pointing it out to me, but there are still some big failures there.

First, the site appears broken. The "Purchase SSL" link on the front page goes to a 404.

Second, the absolute cheapest certificate I could find anywhere was Certum's BasicID which costs $9.95 for one year.

Third, the dark pattern of presenting a lower price up front ($8), but then you find that this only applies if you spring for more than one year. Misleading and weak.

Finally, A wildcard certificate from the same company appears to cost $65.83/yr, (which goes up to $79.00 once you click on the link and realize that was the three year price.)

Not going to lie, this website leaves me feeling very skewed out, and still costs too much for what you're getting anyways.

Sorry, I haven't looked at the site in a while and it has changed a lot.

Wildcard certificates are rarely economical compared with just buying individual certs for the subdomains.

> the dark pattern of presenting a lower price up front ($8), but then you find that this only applies if you spring for more than one year. Misleading and weak.

Absolutely agree!

If you send me an email then I'll make you a coupon to get a certificate for £5 (just over cost price) on my site: https://www.volcanicpixels.com/ssl/ (which is open source: https://github.com/volcanicpixels/volcanicpixels/)

The offer is appreciated but I'll pass - my reason for wanting SSL is not a business one, rather an annoyance one (i.e. alerts every time I hit my self-signed sites).

Aside: the way you keep mentioning your URL over and over seems really spammy.

That's nice, but spamming your product all over the comments to this post rather discourages me from using your services.

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?

"not-trustworthy"

The process of obtaining an SSL certificate does not involve divulging your private key to the CA so what are you trusting them with? In reality you are trusting them not to sign certificates for sites not owned or administered by the person requesting it, they could (in theory) do this whether you got your certificate from them or not. In practice they cannot do this on a widespread scale without it being detected (e.g. Chrome sends info to Google if a certificate for a google domain is valid but not from the Google Internet Authority) and as soon as that happens then they lose their business (as is what happened to a CA that got hacked).

It's the same kind of non-trust you (and others) assert over CAcert.

See how well that model worked with Comodo and TurkTrust - both of which are still in business and in default CA lists, which is counter to your assertion that careful CA operation makes business sense.

Unfortunately there's no will with browser vendors to _really_ improve matters (maybe TACK?), so something like CAcert is great should it get implemented (providing some heat to CA providers) and even when not (by showing the browser vendors' hypocrisy).

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.

http://en.wikipedia.org/wiki/Reductio_ad_absurdum

A 10 year old with a hobby site in a third world country doesn't need a $5 certificate. Neither does a rich 10 year old with a hobby site for that matter, but he can purchase one if he wants.

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?

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.

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.

Reason why?

Because he works for a CA.

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

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

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)

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

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)

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.

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.

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.

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://github.com/volcanicpixels/volcanicpixels/

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

Distrust Diginotar certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=682927

That is simply not true:

http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on...

OTOH Comodo is still in business: http://www.wired.com/2011/03/comodo-compromise/

I was wrong.

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.

My mistake. I'd been under the impression that the discussion of removing Diginotar from the trust list had fizzled, like Trustwave's did [1,2]. It's good to learn that I was wrong.

There are counterexamples, though. Comodo[3] and Verisign[4] are still in the trust store— they're too big to fail, I expect.

[1] http://www.computerworld.com/s/article/9224082/Trustwave_adm...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=724929

[3] http://www.wired.com/2011/03/comodo-compromise/

[4] https://www.schneier.com/blog/archives/2012/02/verisign_hack...

Reply on news.ycombinator.com