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.