Diskussion:CAcert

Komplettüberarbeitung

Ich würde den gesamten Artikel gerne noch mehr wikifizieren. Zur Zeit liegt in meinem Benutzernamensraum eine Kopie des Artikels, die ich noch eine Zeitlang bearbeiten werde: Benutzer:SiebenBergeGrizzly/CAcert

Vorschläge für Ergänzungen, Einzelnachweise o.ä. sind willkommen! -- SiebenBergeGrizzly (Diskussion) 23:14, 11. Sep. 2013 (CEST)

Überarbeitung ist vorgenommen. Ich hoffe, dass die neue Struktur Anklang findet. Inhaltlich ist mehr zur Organisation und Prozessen ergänzt worden. Ich habe mich entschieden, den Abschnitt zur Vertrauenswürdigkeit um die Aussagen zum „Nutzereindruck“ von Browser-Fehlermeldungen zu kürzen, da mir dies ohne Belege zu sehr nach WP:TF aussieht und ein wenig am WP:NPOV kratzt. Vielleicht kennt jemand eine Diplomarbeit o.ä., worin das Thema unter Nennung von CAcert behandelt wird? -- SiebenBergeGrizzly (Diskussion) 09:39, 15. Sep. 2013 (CEST)

Sicherheitsanforderungen und deren mögliche Umsetzung

Inzwischen ist diese Seite mehr der Diskussion über Sicherheitsanforderungen und deren mögliche Umsetzung gewidmet, als über den Artikel. Das geht damit (wie der Artikel selbst) meiner Meinung nach an der Idee von Wikipedia vorbei. Wikipedia ist eine Enzyklopädie, aber kein Lehrbuch, keine Datenbank, kein Medium zur Theorienfindung und kein Diskussionsforum. Ich hab das trozdem erstmal dringelassen, weil möglicherweise viele Missverständnisse in solchen Themen bestehen und vielleicht hilft das ja jemandem... --Steffen 18:54, 12. Mai 2007 (CEST)

---

Ich finde den Artikel nicht objektiv. Es wird suggeriert, cacert.org sei "sicher" (vergleichbar mit kommerziellen CAs). Meiner Meinung nach ist das bei Weitem nicht so. (Der vorstehende, nicht signierte Beitrag stammt von STD (Diskussion • Beiträge) 01:03, 12. Apr. 2007 (CEST))

Gut, wie sicher sind kommerzielle CAs?--Habakuk <>< 11:11, 12. Apr. 2007 (CEST)

Wikipedia soll jedenfalls meiner Meinung nach nicht behaupten, irgendwas wäre sicher oder zum Zertifikatimport aufrufen.. Die Frage an sich zeigt meiner Meinung nach schon, dass sowas nicht objektiv geschrieben werden kann. Dann lieber nichts (statt fragwürdiges) schreiben, oder?

Ausserdem ist es schlicht falsch: "wird eine Meldung erhalten, dass die Herkunft des Zertifikates nicht überprüft werden konnte.... Abhilfe schafft der Import...". Das ist falsch, es schafft keine Abhilfe sondern unterdrückt lediglich die (korrekte) Warnung/Meldung (macht es also schlimmer). Bei Verwendung des beschriebene Imports kann die Herkunft das CA-Zertifikats nicht geprüft werden, damit kann das Zertifikat der Gegenstelle, zu der man eine Verbindung aufbaut, natürlich immer noch nicht verifiziert werden und die Herkunft des Zertifikates immer noch nicht überprüft werden - denn dazu kann man ja natürlich kein Zertifikat nehmen, wessen Herkunft selbst nicht geprüft werden kann. Solche Diskussionen gehören aber wohl kaum in eine Enzyklopädie, oder?

Wobei man da auch die Struktur in den Browsern und Mailreadern bemängeln muss. Um ein Zertifikat nutzen zu können, muss ich grundsätzlich der dazugehörigen CA trauen. Richtiger wäre es, das Vertrauen in die einzelnen Zertifikate zu legen, anhand einer Überprüfung des Fingerprints. Un das auch kommerzielle CAs nicht 100%ig Vertrauenswürdig sind, haben diese in der Vergangenheit auch schon oft genug bewiesen. --BjSch 16:14, 12. Mai 2007 (CEST)

offtopic Vertrauen funktioniert anders. Du kannst einer kommerziellen CA trauen, weil Du einen Vertrag hast. Die CA garantiert Dir, ihre Policies einzuhalten usw. Für die Firma, die die CA betreibt, führt ein Missbrauch vermutlich zu Schadensersatzforderungen und schnell zu einer Existenzgefährdung für die CA. Das heisst also, ggf. schützt der Staat Deine Interessen (juristisch eben dadurch, dass man den Vertrag einklagen kann). Bei einer Hobby-CA mit mehr oder weniger anonymen "Sicherheitsbeauftragten" (die sich vielleicht einfach selbst dazu erklärt haben!), kann man nichts weiter einklagen, wenn diese überhaupt nicht garantiert, irgendwelche Richtlinien einzuhalten. Wenn so eine CA z.B. jemandem Zugriff auf den Zertifizierungsschlüssel erlaubt (was bei CAcert wohl ab einer bestimmten Punktzahl mehr oder weniger direkt, egal, der Fall ist), verletzt das also auch keine Garantie. Hat nichts mit Vertrauen zu tun. Sie versprechen ja nichts! Das erhöht damit natürlich auch keine Sicherheit. --Steffen 18:54, 12. Mai 2007 (CEST)

zur Frage: Das hängt natürlich von den Policies ab (Beispiel). Versign z.B. zertifiziert über änderlokale Ansprechparnter, die Ahnung vom lokalen Recht haben sollten und z.B. einen Handelsregisterauszug erkennen können. Beispielsweise gibt es Business Identity Authentication FAQ. Klar, muss jeder selbst wissen. Im Fall eines Misbrauches kann man rechtliche Schritte unternehmen (saubere, klare Vertragsbeziehungen etc). Bleibt zu hoffen, dass es überhaupt kein Zugriff via Netzwerk auf den signing key / private root key möglich ist (auch nicht über serielle Kabel) usw. Na ja, das ist ein weites Feld... Essentiell ist aber, dass dokumentiert ist, wie es funktioniert. Man kann anrufen, mails schreiben oder auf der Webseite nachlesen und herrausfinden, wie sicher sie sind. Natürlich gilt auch hier, dass man nicht einfach irgendwelche root-Zertifikate in die browser db importieren sollte! Auch die voreingestellten Zertifikate sollten konfiguriert werden: per Voreinstellungen traut man sonst nämlich vielen CAs, von denen man vermutlich noch nie etwas gehört hat. Aber das ist ein anderes Thema :) -- Steffen 11:26, 13. Apr. 2007 (CEST)

Auch scheint der Artikel zu lang. (Der vorstehende, nicht signierte Beitrag stammt von STD (Diskussion • Beiträge) 01:03, 12. Apr. 2007 (CEST))

Beispiele

Erster Absatz spricht von "Identität ausreichend belegt", bezieht sich auf Meinung von cacert.org. Vielleicht besser vorsichtig ausdrücken: "gewisse Hinweise auf Identität" oder etwas.

"Client-Zertifikate" seien "personalisiert" müsste mit direktem Zitat aus cacert.org Zertifizierungsrichtlinien belegt werden (link!). Es gibt nicht-personalisierte Zertifikate (die als Client-Zertifikate genutzt werden können), damit ist die Aussage vermutlich schlicht falsch. Später schreibt der Artikel dann auch "Ein einfaches E-Mail-S/MIME-Zertifikat kann man bereits ab 0 Punkten bekommen.".

"Server-Zertifikate" verbinden, wie Zertifikate überhaupt, öffentliche Schlüssel oder andere technische Informationen ("Zahlenkolonnen") mit menschenverständlichen Daten. Hier wird eine allgemeine Forderung beschrieben, nicht jedoch, ob und wie cacert.org diese erfüllt. Der Leser bezieht diesen (und den vorherigen) Abschnitt aber sicherlich auf "Folgende Zertifikate und Signaturen werden angeboten:", weil das darüber steht! Es werden (irgendwelche) Zertifkate geboten, dass diese etwas sicherstellen würden, ist jedoch fraglich und steht da unbegründet.

"Allgemeine Hürde" erklärt, dass das CAcert-Zertifikate nicht als vertrauenswürdige Zertifizierungstelle in Browser eingetragen sind und damit keine Signatur geprüft werden kann. Das ist korrekt. Dann: "Abhilfe schafft der Import des CAcert-Root-Zertifikats, das unter https://www.cacert.org/index.php?id=3 erhältlich ist.". Das ist falsch. Das führt dazu, dass der Browser nicht mehr "weiss", dass die CA nicht vertrauenswürdig sei und fälschlicherweise würde von cacert.org signierten Zertifikate vertraut werden, ohne das die CA selbst oder wenigstens auch nur das Zertifikat geprüft wurde. Dabei soll man sich das Zertifikat von einem Server laden, dem man überdies nicht trauen kann (weil nicht gültig zertifiziert). Das verwendete HTTPS suggeriert wieder Sicherheit, die überhaupt nicht vorhanden ist.

Technisch ist dies so, da ein "man in the middle" Angriff durchgeführt werden kann. Genau davor soll ein Zertifikat aber nun schützen. Dieses "Henne-Ei" Problem kann man nicht durch einen Mausklick lösen.

offtopic Eben, man braucht dazu Verträge und Prozesse (vorgeschriebene Abläufe), die man ggf. einklagen kann. --Steffen 18:54, 12. Mai 2007 (CEST)

Jeder, der dieses Zertifikat in seinen Browser installiert, reduziert damit die Sicherheit erheblich, da der Browser danach Zertifikate akzeptiert, die von mehr oder weniger Unbekannten, nur indirekt von obstrusen Punktesystemen "bewerteten" Personen ausgestellt wurden. Da Browser in der Regel sämtlichen importierten Zertifikaten voll trauen, könnten plötzlich Bankgeschäfte über derartige Zertifikate abgewickelt werden. So ein Szenario halte ich nicht für übertrieben.

Hintergründe

Web of trust und obstruse Punktesysteme ermöglichen es phantom-Identitäten sich "gegenseitig" zu zertifizieren und so zu hohen Punkten zu kommen. Weiterhin gibt es sogar bereits Zertifikate, die nur ein CN mit einem DNS Hostnamen ohne jegliche Identität (OU, U, ...) zertifizieren (und damit die pure Existenz eines Names zertifizieren?).

man kann hier "nur" eine Maximalpunktzahl erreichen, damit eben kein "ich bin der bessere Punktesammler" entsteht. ich sehe da kein problem drin.

Das zeugt meiner Meinung nach von gefährlichem technischem Unverständnis, da der Benutzer keinen DNS Hostnamen auswendig wissen sollte, sondern ja ein Zertifikat benutzen können soll, um festzustellen, ob es zu der erwarteten Institution passt. Weiterhin muss es natürlich nachvollziehbar sein (z.B. E-Mail-Kontakt).

bitte verfahrensweise nochmal durchlesen (ggf. im CAcert-wiki). Hier werden einige Sachen durcheinander geworfen. --Wonderer4711 15:35, 10. Mai 2007 (CEST)

Anfragen per Mail an cacert.org wurden erst nach Wochen beantwortet (die Antwort selbst empfand ich dann auch nicht sehr zufriedenstellend).

hatte ich auch schon. nach nachfragen kam dann aber positives und gutes feedback. Nur wer richtig fragt bekommt auch richtig Antwort ;-) --Wonderer4711 15:35, 10. Mai 2007 (CEST)

offtopic Ja, ich hatte vermutlich falsch gefragt, nach Zertifizierungsrichtlinien oder sowas, schon klar. SCNR. --Steffen

Es war mir auch nicht möglich, genaue verbindliche Zertifizierungsrichtlinien zu erfahren. Ein Bekannter berichtete mir nämlich, dass "E-Mail-Authentifizierung" möglich sei. Technisch würde das bedeuten, dass ein Angriff auf die DNS-Informationen ausreicht, um Mail und Web umzuleiten. Damit könnte der Angreifer ein neues Zertifikat per Mail authentifizieren und es für den gefälschten Webserver nutzen. Genau davor soll ein SSL-Zertifikat (HTTPS) schützen - tut es hier (cacert.org) aber gar nicht!

Für Deine eigene E-Mail Adresse bist Du selbst verantwortlich, nicht eine andere Organisation. Die Anmeldung selbst bei CAcert erfolgt doch per https (-> sehe also kein Problem)

Die Verifizierung Deiner identität erfolgt nach dem 4-Augen Prinzip. Das heisst selbst wenn derjenighe diesen Aufwand für ein kostenloses Zertifikat betreiben möchte müsste er dann spätestens einen Personalausweis fälschen, vorher ist es ein namenloses Zertifikat (analog zum "Dumy" zertifikat eines eigenen LAMP oder XAMP Systems) -> Also Unsinnig. --Wonderer4711 15:35, 10. Mai 2007 (CEST)

offtopic (Ich versteh nicht, was daran so schwer zu verstehen zu sein scheint). Das TLS/HTTPS hilft doch überhaupt nichts. Der Browser baut Verbindung zu jemandem auf, der selbst "beweist", dass er er selbst ist. Das ist ja so, als ob Du Dir selbst einen Pass bastelst, und dann in die USA einreisen möchtest. Aber selbst wenn Du die Identität des Webservers da prüfst, nützt es (für den Fall hier) nichts. Das Mail-Zertifikat soll doch verhindern, dass ein Angreifer sich als der E-Mail-Addresseninhaber ausgeben kann, selbst wenn er Zugriff auf die Mailbox (Server, was auch immer, egal) hat. Die Idee ist, dass jemand anders vielleicht Zugriff auf die Mailbox (...) bekommt, nicht aber auf den entsprechenden (geheimen) Schlüssel (eines Schlüsselpaares). Daher verwendet der Inhaber diesen Schlüssel, um die Authentizität zu beweisen - jemand anders kann die jeweils erzeugte Signatur und den verwendeten Schlüssel prüfen und gewinnt dann Klarheit über den Inhaber, weil dessen Name (und weitere Eigenschaften wie Land, Organisation, ...) über das Zertifikat mit dem Schlüssel verknüpft sind. Wenn nun aber dieses Zertifikat per E-Mail beantragt werden kann und der einzige Schutz in einer E-Mail Rückfrage versteht, kann der Angreifer, der Zugriff auf die Mailbox (...) hat, sich ganz "legal" so ein Zertifikat für einen selbstgebastelten Schlüssel besorgen! Genau davor sollte das aber schützen! Steht im Zertifikat gar kein Name (...) drin, sondern z.B. nur eine E-Mail Adresse oder ein DNS Hostname (www.domain.de), ist das auch schlecht. Das Zertifikat soll ja zertifizieren, zu wem der Kommunikationspartner gehört. Wenn das aber gar nicht drin steht, wird ja gar nichts zertifiziert! Das ist kein Problem von Schlüssellängen oder SSL/TLS mit oder ohne HTTPS und S/MIME - das ist einfach ein ganz logisches Problem - man kann es nicht rein technisch (automatisch) lösen. Ein selbstgemalter Pass ist sogesehen ja "echt", es nützt nur nichts. Wenn in dem Pass nichtmal der Name des Passinhabers steht, nützt er auch nichts. Und wenn so ein Pass dann von einem zwölfjährigen Chinesen ausgestellt wurde (was man nichtmal so einfach rauskriegt), kann man auch gar nichts einklagen, weil das chinesische Recht das nicht hergibt. Aber man kann ja sowieso nichts einklagen, weil ja gar nichts versprochen (garantiert) wird! --Steffen 18:54, 12. Mai 2007 (CEST)

Ich halte den Artikel so für nicht objektiv, da diese Fakten unerwähnt bleiben, cacert.org kritiklos als "sicher" hingestellt wird.

ich lese da nirgendwo diese Aussage -> ist also schlicht FALSCH. --Wonderer4711 15:35, 10. Mai 2007 (CEST)

Der Artikel verkommt langsam zu einer Warnung vor CAcert. Richtig wäre es evtl. die Kritik an einer Stelle zu sammeln, und nicht in jeden Absatz eine eigene Warnung einzubauen. Oder wirklich Kritik und Fürsprache ganz rauszulassen, und den Artikel ohne Wertung zu verfassen --BjSch 16:14, 12. Mai 2007 (CEST)

Vorschläge

Entsprechende Zitate / Verweise sind mindestens notwendig.

Der Artikel kann auch kurz und knapp umgeschrieben werden, sollte dann Bedenken auch nur knapp erwähnen. Dabei sollten Meinungen und Wertungen vermieden werden, stattdessen mit evtl. mit Fakten untermauern (fiktives Beispiel: "Die von ACME durchgeführte Sicherheitsbegutachtung führte zu einer Zertifizierung nach XYZ").

Produktlisten und Abläufe vielleicht entfernen. Vielleicht einfach kurz Idee, Umsetzung/Organisation und Vor-/Nachteile beschreiben?

Meiner Meinung nach muss der Hinweis auf den Import des self signed root certificates von cacert.org auf jeden Fall entfernt werden. Dies könnte Laien täuschen (und das passiert tatsächlich!) und ist daher gefährlicher, als gar kein Zertifikat (dann sind die Benutzer wenigstens misstrauisch!).

--Steffen 01:03, 12. Apr. 2007 (CEST)

Beim Import des root zertifikates ist natürlich noch der Fingerprint zu überprüfen. --Wonderer4711 15:35, 10. Mai 2007 (CEST)

Also konkret meinst du, dass CAcert weniger vertrauenswürdig sei als "kommerzielle CAs" - kannst du das durch externe Quellen belegen (Hint: Wikipedia:Theoriefindung)? --Habakuk <>< 11:15, 12. Apr. 2007 (CEST)

Zur Theorienfindung: ich finde, der orginale Artikel ist ein Beispiel für Theorienfindung. Ohne Verweise auf Fachliteratur, Zertifizierungen, Zulassungen oder Gutachten, spricht aber von "Identität ausreichend belegen" (ausreichend?) und "stellen die Identität eines Servers sicher" (sicher?). Das ist nicht überprüfbar. -- Steffen 11:35, 13. Apr. 2007 (CEST)

Ich vertraue ehrlich gesagt kommerziellen CAs nicht mehr als CAcert. Es gibt Gerüchte, dass sich kommerzielle CAs für ein kleines Trinkgeld in den Zertifikatsspeicher gewisser Browser einkaufen können. Wenn man dadurch Bankgeschäfte manipulieren kann, tja, vielleicht lohnt es sich ja durchaus diese Summe an eine gewisse Firma zu zahlen. Woher soll ich wissen, dass diese Zertifizierungsstelle, hinter der unter Umständen nur eine einzige mir unbekannte Person sitzt, wirklich vertrauenswürdig ist? Bei CAcert gibt es eine Gemeinschaft mit tausenden Mitgliedern... also für mich ist das auch Theoriefindung. --th 15:58, 12. Apr. 2007 (CEST)

Wenn man bei einer kommerziellen CA Anruft und möchte sein zertifikat ausstellen oder verlängern lassen ... wer sagt einem, das da nicht noch die Putzfrau da was erstellt und das die Identitätsprüfung überhaupt durchgeführt wird ... nur mal so als Gedankenpunkt... --Wonderer4711 15:35, 10. Mai 2007 (CEST)

offtopic Die Policies (Zertifizierungsrichtlinien) sagen das. Beispielsweise dürfen nur Sicherheitsbeauftragte die kryptographischen Schlüssel benutzen und sie sind persönlich dafür verantwortlich, diese nur zu "erlaubten Zwecken" zu nutzen (in der Regel, in dem jeder Sicherheitsbeauftragte entsprechende Verträge unterzeichnen muss). Was genau das bedeutet, steht in den jeweiligen (verbindlichen) Richtlinien bzw. Policies. Oft wendet man das "Vier-Augen-Prinzip" bzw. "dual control" an. Die Sicherheitsbeauftragten müssen prüfen, ob die Bedingungen erfüllt sind (wurde der Pass von einer namentlich dazu berechtigten Person geprüft, sind die Formalien erfüllt, etc). Wer wann was gemacht hat, wird unveränderbar gespeichert und ist daher nachvollziehbar. Ein "Nebeneffekt" ist, dass die Sicherheitsbeauftragten (die das ja wissen) bei "nicht sorgfältiger" Arbeit ein grosses persönliches Risko eingehen würden und dies daher natürlich vermeiden. --Steffen 18:54, 12. Mai 2007 (CEST)

Meiner Meinung nach ist es nicht die Aufgabe von Wikipedia, dieses zu diskutieren. Ob es überhaupt "sichere" CAs gibt, sei dahingestellt. Solange es nicht absolut klar ist, sollte man es aber nicht behaupten (Sicherheit funktioniert aber anders, ist relativ und hängt im Wesentlichen von Verträgen und nicht (nur) von Schlüssellängen. ab). Man könnte das so alles schreiben, mit allen wichtigen Meinungen und so weiter, aber ich persönlich fände das viel zu viel für eine Enzyklopädie. Daher lieber weglassen, was nicht ganz klar ist.

DEM stimme ich auch zu. --Wonderer4711 15:35, 10. Mai 2007 (CEST)

zur Diskussion: Jeder muss selbst entscheiden, was für ihn sicher ist. Es geht hier auch nicht um Vergleiche. Wikipedia-Artikel sollten aber nicht behaupten, irgendwas wäre sicher oder sich "anmassen", Sicherheitsniveaus von Zertifizierungsstellen begutachten zu wollen. Es sollten Fakten kurz und bündig genannt werden, nicht über mehr oder "weniger vertrauenswürdig" gemutmasst werden - und natürlich auch keine Benutzer verführt werden, solche Zertifikate zu installieren.. Das gilt allgemein (und nicht nur bei cacert.org). Wikipedia soll auch nicht schreiben, "installieren Sie sich gleich das Windows Genuine Advantage Program" oder sowas. Sowas sind doch Standpunktfragen, wo verschiedene Meinungen existieren. Da kann man höchstens beide (alle) Standpunkte beschreiben, aber ich persönlich finde, dass das über eine Enzyklopädie hinausgeht (eher was für einen Diskutierclub). Eine "Gemeinschaft mit tausenden Mitgliedern" trägt meiner Meinung nach nicht zur Sicherheit bei, ganz im Gegenteil. Und ja, ich halte mindestens eine kommerzielle CA für sicherer als cacert.org. Aber das ist Meinungssache und gehört hier nicht her, finde ich. --Steffen 11:26, 13. Apr. 2007 (CEST)

English version

Hello. The german version of this article is more complete than the english one, probabily by the fact that there are a majority of german CAcert assurers ;). Could you take the time to add the extra information to the english version? So, other languages will benefit from it :). Thanks! --PabloCastellano 03:19, 9. Feb. 2010 (CET)

seriös oder eher fragwürdig?

Auf Grund der durch die verwendete Vorlage:Infobox gemeinnützige Organisation zwingend erforderliche Georeferenzierung, hab ich mal versucht die Adresse dieser Organisation heraus zu finden: Mit keinem Ergebnis!

• Auf deren Homepage (ein Wiki) gibt es kein Impressum!
• Keine direkte Adresse nur ein Postfach [1]: (CAcert Inc. PO Box 66 Oatley NSW 2223 Australia)
• wenn man über die history [2] geht sieht man alte Adressen (auch nur Postfächer!) mit einem link "Please note, this is a page about the history of CAcert. Do not use this historical adresses to contact CAcert." der dann auf eine Seite verweist, die diese FireFoxMeldung erzeugt: "Dieser Verbindung wird nicht vertraut. Sie haben Firefox angewiesen, eine gesicherte Verbindung zu www.cacert.org aufzubauen, es kann aber nicht überprüft werden, ob die Verbindung sicher ist."
• aber da steht wie man denen Geld zukommen lassen kann (auch wieder ohne das man weiß wo das hingeht):[[3]] mit einem weiteren nichts über das Ziel aussagenden Link zu paypal
• dann gibts ja auch noch die supportseite mit dem Abschnitt Snailmail(wieder nur Postfach):

Snail Mail

Snail Mail should be used for practically nothing. All formal disputes, services of notices, etc should be emailed to support @c.o where CAcert's support team  will forward it to the appropriate place.

Postal Address:
CAcert Inc.
P.O. Box 4107
Denistone East NSW 2112
Australia

If by law you must send a snail mail, make sure you email the contents as above to support @c.o, and indicate that a snail mail is to follow.

• und zuletzt: CAcertBerlin hat ein Impressum: [4]

• (aber das nützt ja nix für die Artikelkoordinate)

Also für mich sieht da alles eher nach ner Briefkastenfirmaaus der man eher nicht vertrauen sollte.

Aber was wird nun mit dem Lagewunsch? Soll der ewig stehen bleiben und in den Wartungsseiten für Blindleistung sorgen? Oder nehmen wir di Vorlage raus? Denn ob das wirklich gemeinnützig ist, möchte ich in Frage stellen. --Jmv (Diskussion) 00:31, 26. Jun. 2015 (CEST)

Was genau ist das Problem?

Hallo,

ich sehe nicht genau wo dein Problem liegt. Ein Postfach sollte doch ausreichend sein, um Kontakt aufzunehmen, sofern du das wirklich per Post tun möchtest. Vielleicht möchten sie einfach nicht ihre privaten Adressen offenlegen. Wer weiß wen die CA-Mafia sonst so vorbei schickt ;).

Ich wäre jedenfalls sehr vorsichtig damit CAcert als "gefährlich" einzustufen. Die Jungs sind auf diversen Konferenzen mit Ansprechpartnern direkt vor Ort vertreten (Chemnitzer Linux Tage, FOSDEM, etc.) und leisten (technisch gesehen) wirklich gute Arbeit. Über die praktische Relevanz hingegen kann man diskutieren, solange da Root Zertifikat nicht in den Trust Stores gängiger Browser landet ...

--188.195.222.255 00:37, 26. Jun. 2015 (CEST)

Das Problem ist es gibt durch die Verwendung der "Vorlage:Infobox gemeinnützige Organisation" zwingend einen Lagewunsch der aber nicht duch ein Postfach erledigt werden kann, denn die Koordinaten ermittelt man mitels einer Adresse. Somit ist das dann ein Ewiger Lagewunsch der die Wartungsseiten vollmüllt. --Jmv (Diskussion) 13:19, 29. Jun. 2015 (CEST)

Derzeit nicht erreichbar

Aktuell (Mai 2016) gibt es keinen SSL/TLS-Zugriff mehr auf CAcert.org, zumindest nicht mit Firefox oder Chrome unter Ubuntu-Linux.

Die Fehlermeldungen sind ein wenig unübersichtlich. Die wahrscheinlichste Ursache ist das Root-Zertifikat (muss händisch installiert und das Vertrauensniveau angepasst werden), das mit MD5-RSA signiert ist. MD5 wird als unsicher betrachtet und entsprechende Zertifikate sollen nicht mehr akzeptiert werden, was allerdings schon seit mindestens 2011 diskutiert wird. Allerdings sind wesentlich größere Modul- und Public Key-Längen notwendig, um tatsächlich ein Zertifikat fälschen zu können.

Bislang sind keine Stellungnahmen vom Support zu erhalten gewesen.

Gilbert Brands (Diskussion) 22:08, 10. Mai 2016 (CEST)

Stimmt

An sich ist es schade dass CAcert nicht wirklich gefruchtet hat, da deren "Dienstleistung" für die Erstellung von Zertifikaten wie für Server, E-Mail-Klienten, digitale Unterschrift und Verschlüsselung von E-Mail-Nachrichten sowie auch die Client-Anmeldung per Client-Zertifikat auf deren Seite im CP als auch mit eingerichteter Client-Authentifizierung auf dem eigenen Server möglich war. Bei dem "Konkurrent-Produkt" Let's Encrypt wurde das Projekt erfolgreich gestartet und die Stammzertifikate sind in der Regel in allen Browsern integriert. Let's Encrypt beschränkt sich laut dem Web nur auf SSL-Zertifikate für Server, mehr nicht. Aktuelle Browser verweigern die Verbindung zu der Hauptseite von CAcert.