Wer auf Nummer sicher gehen möchte, sollte aus seiner Schlüsselbundverwaltung das "DigiNotar Root CA" löschen (zu finden im "System-Roots"-Schlüsselbund).

Hintergrund zum Thema:

Danke!
Habs vorhin bei Heise gelesen und mich gefragt wo die beim Mac eigentlich gespeichert sind. Jetzt weiß ichs

Man kann das Zertifikat nicht löschen. Zumindest habe ich es gerade nicht hinbekommen. Aber man kann es als nicht vertrauenswürdig markieren.

Danke, aber: wie löscht man das Ding? ich kann es nur auf "nicht vertrauenswürdig" setzen.

Mit Rechtsklick auf das Zertifikat - "Zertifikat löschen" wählen - AdminPW eingaben und weg ist es.

Als "nicht vertrauenswürdig" markieren sollte auch ausreichen.

Aber löschen lassen sollte es sich ebenfalls, dafür benötigst Du allerdings Admin-Rechte bzw. sogar root-Rechte (was der Standard-Admin-Account ja aber normalerweise bekommt nach Eingabe des Passwortes).

Was mich mal interessieren würde: Wo genau liegen diese root-Zertifikate und kommt man an sie auch einzeln heran, also ohne die Schlüsselbundverwaltung?

Oder ist das ein *.keychain-file, welches man ohne Schlüsselbundverwaltung gar nicht bearbeiten kann?

Hintergrund: Über SSH per remote dieses gefährliche Zertifikat als "nicht vertrauenswürdig" markieren bzw. direkt löschen.

Weiss jemand welche Zertifikate überhaupt in den Schlüsselbund sein müssen?

Was passiert wenn man alle Zertifikate löscht?

Was ist zB. mit solche Zertifikate?:
3x TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
1x Starfield Services Root Certificate Authority - G2
1x Starfield Root Certificate Authority - G2
1x Starfield Class 2 Certification Authority
usw.

Ich habe ca. 176 Zertifikate in System!! Sind sie zu wenig?

ein Zertifikat mit Namen "ValiCert Validation Network" ist auch in meine System.
Dieses Zertifikat enthält einen Link "www.valicert.com" diese Seite existiert aber nicht. Sehr verdächtigt.

Momentan habe ich sie noch in System .... bis wann jemand mehr darüber berichten kann.

Ich möchte nicht alle Zertifikate mit komischen Namen in Frage stellen, aber wie kann man den Schlüsselbund "bereinigen"?

http://support.apple.com/kb/HT3580?viewlocale=de_DE

Im "System-Roots"-Schlüsselbund sind ohne das besagte "DigiNotar Root CA"-Zertifikat noch 174 weitere Zertifikate vorinstalliert (10.6.8 Snow Leopard).

Normalerweise ist das völlig in Ordnung so.

Problematisch wird es eben, wenn das passiert, was im oben verlinkten Artikel recht ausführlich beschrieben ist …

Und da Apple (wieder einmal) nicht so schnell wie z.B. Microsoft reagiert, ist es eben besser, man sorgt selbst dafür, dass dieses Zertifikat oder besser gesagt alle Zertifikate von vom System verbannt werden.

Zitat: "Microsoft hat vorsichtshalber das DigiNotar-Root-Zertifikat aus der Microsoft Certificate Trust List in Windows entfernt und so alle Zertifikate von DigiNotar unbrauchbar gemacht."

Witzigerweise wird dort das DigiNotar-Stammzertifikat bei Apple noch als vertrauenswürdig gehandelt …

Äh, dort geht es um IOS 3 … daran ändern die jetzt bestimmt nichts mehr.

Muss mich korrigieren, besser ist es wohl doch, das Zertifikat zu löschen, siehe diesen Artikel ganz unten (Update):

Danke...

Ich kann bei mir, weder unter Snow Leopard noch Lion, das Zertifikat löschen. Lediglich exportieren oder kopieren. Für Löschen ist im Kontextmenü kein Eintrag. Unter "Bearbeiten" ist "Löschen" ausgegraut. Ich habe auch Admin-Rechte. Und anscheinend bin ich ja auch nicht der einigste, bei dem das so ist. Sie auch meinen Screenshot.

Tobi

@Tobi1051: Versuche mal, einen neuen Benutzer mit administrativen Rechten anzulegen und schaue, ob es dort funktioniert. Wenn ja, Deinen alten Admin-Account löschen und in Zukunft mit dem neu angelegten Admin-User den Rechner administrieren.

PS: Ich gehe davon aus, dass Dein Account für die tägliche Arbeit einer ohne administrative Rechte ist …

vielleicht liegt es ja daran, dass im Screenshot oben explizit in "System-Roots" gesucht wird. Bei mir jedenfalls war das Löschen von einem Normal-User aus kein Problem (Name und Passwort eines Admin-Users wurden natürlich abgefragt).

Daran sollte es nicht liegen, habe das auch schon auf mehreren Rechnern direkt im "System-Roots"-Schlüsselbund gesucht und erfolgreich gelöscht.

Mich würde aber wirklich interessieren, was ich um 16:19 Uhr bereits gefragt habe …

Wo genau liegen diese root-Zertifikate und kommt man an sie auch einzeln heran, also ohne die Schlüsselbundverwaltung?

Oder ist das ein *.keychain-file, welches man ohne Schlüsselbundverwaltung gar nicht bearbeiten kann?

Hintergrund: Über SSH per remote dieses gefährliche Zertifikat als "nicht vertrauenswürdig" markieren bzw. direkt löschen.

http://www.apple.com/certificateauthority/ca_program.html

Klick

Danke, das hat geklappt.

Äh, nur krieg ich das Zertifikat nicht aus dem Camino-Browser gelöscht …

Ich habe grade mal überprüft, was ich evtl. anders gemacht habe.
Lasse ich mir alle Zertifikate anzeigen kann ich auch nicht löschen. Erst wenn ich nach einem Zertifikat suche, kann ich es auch löschen.


Ohne Suche:

Mit Suche:

@onicon & Oceanbeat: Dort wird ja nur beschrieben, wie man bei Apple root-Zertifikate einreichen kann, so dass sie mit in die vertrauenswürdigen Zertifikate des Systems aufgenommen werden (wenn ich es richtig verstanden habe).

Ich möchte aber wissen, wo genau diese auf einem Mac mit Mac OS X abgelegt sind und ob ich sie auch ohne Schlüsselbundverwaltung einzeln löschen kann?

/System/Library/Keychains
/System/Library/Keychains/SystemRootCertificates.keychain

Danke, so geht es!

Danke Dir, hatte ich dann auch entdeckt …

Die Frage wäre jetzt: Wie kann man diese keychain-files per Terminal (SSH) bearbeiten?

Ok, ein "man security" hilft wohl erst einmal weiter …

Spenni

Vielen Dank

Röchtöch!!

$ man security

(oder auch die Manpage online hier )

Zudem: Google-Suche, Stichworte "Mac+keychain+terminal"

Ich würde aber das Fummeln an diesen Root-Zertifikaten sein lassen (und wenn schon, dann nur mit Sicherheitskopie) und stattdessen warten, bis Apple ein Update raushaut und nur dann ggf. Fummeln, sollte sich Apple mal wieder zuviel Zeit damit lassen.

Siehe auch:

heise: Falsches Google-Zertifikat ist Folge eines Hacks

Mozilla: Firefox Help: Deleting the DigiNotar CA certificate
Interessant und unterhaltsam sind mal wieder Felix von Leitners (aka Fefe), Kommentare zu dem ganzen GAU: und

Ok, hatte jetzt mal Zeit, mir den security Befehl genauer anzusehen.

Für z.B. per Apple Remote Desktop respektive SSH verwaltete Systeme wäre der folgende Befehl korrekt (mit Hilfe von sudo bzw. per root-shell):


Den SHA-1 hash des betroffenen Zertifikates kann man sich direkt in der Schlüsselbundverwaltung anzeigen lassen (C0 60 ED 44 CB D8 81 BD 0E F8 6C 0B A2 87 DD CF 81 67 47 8C).

Hat hier wunderbar funktioniert und so wurden "in einem Rutsch" >45 Macs vom diesem Zertifikat befreit.

Und es nimmt kein Ende:

Lies mal:

ITworld (August 31, 2011): Mac OS X can't properly revoke dodgy digital certificates
After DigiNotar hack, many Mac OS X users are having a hard time properly revoking the company's digital certificates

besonders mit Augenmerk auf diese Passage hier:
heise (31.08.2011): CA-Hack: Noch mehr falsche Zertifikate

@sierkb: Na rate mal, warum ich die Zertifikate gelöscht habe …

Aber in Firefox und Chrome läuft das ja eh anders, betrifft also nur die Safari-Nutzer.

Ist wohl die sicherste Methode. Was nicht da ist, kann auch weder benutzt noch irgendwie raktiviert werden.
Die Frage, die sich in dem Fall jetzt stellt ist die, welche eventuellen Nachteile/Konsequenzen es bzgl. anderer darauf vertrauender Zertifikate hat, wenn diese DigiNotar-Zertifikate physikalisch nicht mehr vorhanden sind bzw. ob und inwieweit es von den Folgen her einen Unterschied macht, ob diese Root-Zertifikate zwar zurückgezogen/gesperrt aber physikalisch noch vorhanden oder ob sie komplett gelöscht und damit auch physikalisch nicht mehr vorhanden sind.

In diesem Fall kann man wohl sagen: glücklicherweise läuft das da anders.

Zuvorderst Safari. Ja. Aber: wo liegen denn diese Zertifikate für Safari-Nutzer, worauf greift Safari denn da zu?
Ist Safari das einzige Programm unter MacOSX, das dafür auf den Mac-Schlüsselbund zugreift?

Sollte man Comodo eigentlich auch löschen?
http://www.heise.de/security/meldung/SSL-GAU-zwingt-Browser-Hersteller-zu-Updates-1212986.html

s_ko:

Schau mal auf das Datum der von Dir rausgesuchten Meldung. Sowohl Comodo als auch die Browser-Hersteller haben diesbzgl. inzwischen schon längst reagiert. Steht aber auch in der von Dir genannten Meldung.

Allerdings ein ganz anderer Satz in der von Dir angemerkten heise-Meldung sollte mal wieder Anlass zum Nachdenken geben:

Das ist halt der Nachteil bei solchen zentralen Certificate Authorities (CA). Sind sie einmal an dieser entscheidenden Stelle, also an der Wurzel, kompromitiert, kann der daraus resultierende direkte wie auch indirekte Schaden immens und ziemlich weit verzweigt sein. Zumal so ein System eben genau deswegen ganz besonders attraktiv ist für Angriffe. Da lohnt es sich für Angreifer dann so richtig, wenn sie es einmal geschafft haben, da reinzukommen, das ist dann fast wie eine Lizenz zum Gelddrucken, wenn ein Angreifer auf diese Weise einen Generalschlüssel in den Händen hat bzw. mit einem solchen offiziellen Dienstsiegel eine falsche Identität vortäuschen kann.

Wer sichert die CAs? Wie werden die be- und überwacht und kontrolliert? Angesichts deren so zentraler Bedeutung und Wichtigkeit für das zentrale CA-System können die ja eigentlich nicht abgesichert genug sein. Deren Firmengebäude müssen einer Festung gleichen. Und deren IT müsste atombombensicher und gegen jeden auch nur denkbaren Angriff gesichert sein. Die Praxis zeigt uns wieder einmal, dass dem wohl nicht so ist.

In diesem Punkt ein Vorteil von dezentralen CAs bzw. von Mechanismen, die auf dem "Web of Trust"-Prinzip aufbauen. Da ist das Risiko und die Anfälligkeit gerade in diesem Punkt nicht so hoch bzw. kann leichter eingegrenzt werden (ist einer in Deinem Web of Trust, der sich als nicht vertrauenswürdig herausstellt, kann es parallel dazu aber noch genügend andere in Deinem Keyring geben, die Dir trotzdem noch ihre Vertrauenswürdigkeit aussprechen und Deine Glaubwürdigkeit dann weiterhin von deren Zertifikaten gedeckt ist). Das Thema und die Problematik betrifft auch die Diskussion S/MIME (ebenfalls aufbauend auf centralen CAs) versus PGP/GPG (dezentrale Verwaltung, Web of Trust). PGP/GPG hat sich nicht ohne Grund gegenüber S/MIME in der Praxis da draußen durchgesetzt bzw. wird besonders von IT-nahen Firmen (z.B. Apple, Microsoft, Sun/Oracle etc. pp.) (nicht nur) im email-Verkehr mit ihnen gegenüber dem S/MIME-Verfahren bevorzugt und empfohlen.

Bei Mozilla denkt und handelt man inzwischen genauso wie Du:

Mozilla Security Blog (02.09.2011): DigiNotar Removal Follow Up :


Und von Apple immer noch nicht mal die kleinste Reaktion und Stellungnahme in dieser Angelegenheit angesichts solcher Aussagen wie dieser -- und damit gebotener Dringlichkeit und Eile:

Heftig:

Und von Apple nach wie vor keine Reaktion …

Und weiter gehts ...
Quelle:

Niederländische Regierung übernimmt Kontrolle über DigiNotar

Bei dem Einbruch in die Systeme des Zertifikatsherausgebers //www.diginotar.com/:DigiNotar wurden offenbar auch Teile der vom niederländischen Staat betriebenen PKI "PKIoverheid" kompromittiert. Dies gab die niederländische Regierung in einer Mitteilung bekannt. Aufgrund des Vertrauensverlusts gegenüber DigiNotar und und um einen weiteren Missbrauch zu verhindern, habe die niederländische Regierung die Kontrolle über DigiNotar übernommen.

Die Regierung gibt selbst Zertifikate für verschiedene Zwecke heraus und unterzeichnet sie mit "Staat der Niederlanden". Dazu nutzt sie Systeme, die bei DigiNotar betrieben werden. In der vergangenen Woche hatte DigiNotar noch betont, dass PKIoverheid von den Angriffen nicht betroffen sei. Neuen Erkenntnissen zufolge hatten die Eindringlinge offenbar doch Zugriff auf PKIoverheid. Ob die Angreifer dies aber wirklich zur Ausstellung von Zertifikaten ausgenutzt haben, ist derzeit unklar.

Bislang wurde das PKIoverheid-Stammzertifikat jedoch noch nicht zurückgezogen, weil dies sonst zu Ausfällen bei der Kommunikation von Computersystemen führen können, die auf verschlüsselte Verbindungen angewiesen sind.

Marcel_75@work:
promac:

Fefes Blog: :
Radio Netherlands Worldwide: Security of Dutch government websites in jeopardy
The Dutch Interior Minister Piet Hein Donner has given a press conference in the early hours of Saturday morning after an internet security firm appears to have been hacked by Iranian hackers. (Published on 3 September 2011 - 1:33am):


Und Apple schweigt. Bin gespannt, ob's morgen, am Dienstag von Apple ein diesbzgl. Security- oder/und Safari-Update geben wird. So langsam wird's Zeit.

DA bekomme ich langsam Angst wenn ich das so lese ...
Quelle:

DigiNotar-Hack: Kritische Infrastruktur war unzureichend geschützt


Die kritische Infrastruktur bei der kompromittierten Zertifizierungsstelle DigiNotar war unzureichend geschützt. Das geht aus dem Zwischenbericht (PDF) des Sicherheitsunternehmens Fox-IT hervor. Demnach standen die CA-Server zwar in einer sicheren Umgebung, waren jedoch über das Management-LAN erreichbar. Dadurch konnte sich der Angreifer wohl von außen zu den CA-Servern weiterhangeln. Die Server seien mit einem schwachen Passwort geschützt gewesen, das man leicht per Brute Force hätte knacken können.

Alle CA-Server waren dem Bericht zufolge Mitglied einer Windows-Domain, sodass der Angreifer mit den einmal erbeuteten Zugangsdaten auf sämtliche Server zugreifen konnte. Auf kritischen Servern entdeckten die Sicherheitsexperten Schadsoftware, die von gängiger Antivirensoftware mühelos erkannt wird – eine solche war auf den Systemen allerdings nicht installiert. Zudem war die Software auf den öffentlich zugänglichen Webservern laut dem Bericht veraltet.

Auf den kompromittierten Systemen fanden die Ermittler zudem neben ganz profanen Security-Tools wie Cain & Abel auch speziell für diesen Einsatz zugeschnittene Tools und Skripte. Das Skript, das der Hacker offenbar zur Signierung der falschen Zertifikate eingesetzt hat, nutzt ein spezielles API, das nur im Umfeld von CAs eingesetzt wird. In diesem Skript hat sich der Angreifer in englischer Sprache mit den Worten verewigt: "Ich weiß, dass euch mein Können schockiert. […] Es gibt keine Hardware oder Software auf dieser Welt, die meine heftigen Attacken stoppen kann."

Signiert ist das "Bekennerschreiben" mit den persischen Worten "Janam Fadaye Rahbar", was man mit "Ich opfere mich für den großen Führer" übersetzen kann. Diese Worte finden sich auch in dem Manifest, das schon der mutmaßliche Comodo-Hacker ins Netz gestellt hat. Ob es sich um dieselbe Person handelt oder eine Gruppe von Hackern den gleichen Spruch benutzt, ist unklar.

Der Zwischenbericht bestätigt die Zahl der 531 durch den Angreifer ausgestellten Zertifikate. Allerdings sei nicht auszuschließen, dass darüber hinaus bei dem Vorfall noch weitere Zertifikate ausgestellt wurden, da nach dem Einbruch Log-Dateien gelöscht wurden. Aus diesem Grund wurde laut Bericht auch das Google-Zertifikat nach der ersten Analyse des Einbruchs nicht zurückgerufen – DigiNotar wusste schlicht und ergreifend nicht von dessen Existenz.

Der Angreifer hatte auch Zugriff auf den CA-Server PKIoverheid, der von den niederländischen Behörden genutzt wird. Allerdings sind die Log-Dateien hier vollständig, was nach Meinung der Experten darauf hindeutet, dass der Server nicht missbraucht oder manipuliert wurde, berichtet Fox-IT. Zwar fanden sie hier zwei Seriennummern von bis dato unbekannten Zertifikaten, es sei jedoch möglich, dass diese von der CA-Software temporär erzeugt worden sind oder durch einen Bug entstanden seien, so die Experten.

Bei der Logfile-Auswertung des OCSP-Responders, an den die Browser beim Besuch einer von DigiNotar signierten Seite eine Anfrage senden, stelle sich heraus, dass bislang wohl nur das Google.com-Zertifikat im großen Stil für Abhörmaßnahmen missbraucht wurde. Es gingen rund 300.000 verschiedene Anfragen (Unique IPs) ein, davon über 99 Prozent aus dem Iran.

Auch TrendMicro hat einen drastischen Anstieg von OCSP-Anfragen an DigiNotar aus dem Iran registriert. Besonders besorgniserregend ist die Tatsache, dass die Zugriffe laut TrendMicro von über 40 verschiedenen ISPs und Unis ausgingen. Eine derart großflächlig angelegte Abhörmaßnahme ist kaum ohne staatliche Hilfe umzusetzen.

[Update]Der mutmaßliche Comodo- und DigiNotar-Hacker hat eine weiteres Manifest veröffentlicht. Darin gibt er an, Zugriff auf vier weitere Certificate Authorities zu haben, um sich jederzeit beliebige Zertifikate auszustellen. Namentlich nennt er in seinem Manifest jedoch nur GlobalSign. Daneben will er auch der Hacker gewesen sein, der im Juni in die Server des israelischen Zertifikatsherausgeber StartCom eingedrungen ist.[/Update]

Eigentlich ist es unsinnig von DigiNotar ausgestellten Zertifikaten jetzt nicht mehr zu vertrauen. Das ist Marketing.

Natürlich beugt man so Missbrauch durch zu unrecht ausgestellten Zertifikaten von DigiNotar vor, aber das System an sich ist schon kaputt. Da wird ganz offensichtlich gar nicht geprüft, ob die CAs wirklich „ehrlich” sind. CNNIC zum Beispiel.

Also ich würde Achmed eher vertrauen als CNNIC .

Protecting Your Mac From the DigiNotar.nl Certificate Compromise

Radiotope: Updated: For Security's Sake: Remove Diginotar CA Certificate

ComputerWeekly.com: Microsoft warns of fraudulent digital certificate issued by DigiNotar

Microsoft Security Response Center: TechNet Blogs > MSRC > Microsoft Releases Security Advisory 2607712

Microsoft Technet: Microsoft Security Advisory (2607712)
Fraudulent Digital Certificates Could Allow Spoofing

Eine wenig verantwortungsbewusste Aussage, die Du da tätigst, finde ich.

Dass das System an sich seine Schwächen hat und leicht aus den Angeln gehoben werden kann, ist schon verschiedentlich deutlich gemacht worden (siehe auch mein Posting weiter oben vom 02.09.11 20:14), und auch hier wird es gesagt:
Und trotzdem ist das kein Grund, deshalb dann sämtliche Schilde runterzunehmen und fatalistisch zu sagen "Das System hat vom Grundsatz her eh Schwächen und is anfällig, an der Wurzel komprommitiert zu werden, also brauchen wir uns, wenn die Hütte dann tatsächlich brennt, eh nicht mehr löschen und uns um unsicher gewordene Root-Zertifikate nun eh nicht mehr zu kümmern."

Mit dieser Einstellung wie der von Dir geäußerten, bräuchte man also ein brennendes Haus auch nicht löschen, sondern sollte es runterbrennen lassen und ggf. das Feuer auf andere Häuser übergreifen lassen, sollte man wissen oder festgestellt haben, dass dessen Brandschutz unzureichend oder evtl. null Brandschutz vorhanden ist...
Lassen wir den Dingen also ihren Lauf und ergeben wir uns unserem Schicksal, oder wie?
Mit dieser fatalistischen Einstellung wie der Deinigen wäre der Alptraum von Japans Ex-Regierungschef Kans bzgl. Fukushima und dem Fall Japans wohl wahr geworden: .

Denn:

und auch:

Das ist kein Marketing, so wie Du das runterzuspielen/zu verniedlichen versuchst, sondern das ist das Löschen und Eindämmen eines Brandes. Das sind Notfallmaßnahmen, deren Unterlassung zu unkalkulierbaren Schäden in allen möglichen Bereichen führen kann und im Einzelfall möglicherweise sogar schon zu echtem Schaden geführt hat.
Wenn der Brand gelöscht ist, dann kommt die Zeit des Aufräumens und das Nachdenken darüber, wie man sowas für die Zukunft verhindern kann. Aber erstmal muss das Feuer gelöscht bzw. unter Kontrolle gebracht werden.

Hallo,

nochmal meine Frage zum Camino-Browser v. 2.0.7:

Das DigiNotar Root Zertifikat läßt sich von mir nicht löschen (auch mit Admin-Rechten nicht), sondern es wird – nach dem Klick auf den 'Löschen'-Button – in roter Farbe "Kann nicht überprüft werden" angezeigt und dieses Zert ist immer noch da …

Hat jemand eine Idee?

kix:

mozillazine: Fraudulent SSL certificate can be used to impersonate Google

und besonders diese Antwort hier:

Sprich: das ist für Camino derzeit normal bzw. nicht anders möglich. Abwarten, bis es ein Update von Camino gibt. Oder, wenn es Dich so sehr stört, den aktuellen Firefox 6.0.2 verwenden.

Ich habe nirgends geschrieben, dass Achmed als eine CA anerkannt werden sollte. Allerdings verstehe ich Achmeds Anfrage als Gag (und finde es sehr lustig).
Nein, aber man sollte weitere CAs nicht mehr anerkennen (im Sinne von Vertrauen entziehen). Zeit genug hatten sie um einen weiteren Patch zu veröffentlichen.

Um bei dem Beispiel zu bleiben: Die brennenden Häuser zu löschen ist dringend notwendig, aber es nicht damit getan nur zu handeln, nachdem es brennt. Man sollte Brandentstehung auch vorbeugen. Wissentlich fehlenden Brandschutz zu ignorieren und erst zu handeln, wenn es dann brennt, ist doch keine Lösung.

Das es Probleme bzgl. der Vertrauenswürdigkeit einiger CAs schon vorher gab war Mozilla bewusst, oder es wurde ihnen zumindest berichtet.

Ich möchte diese interessante Diskussion noch einmal in eine andere Richtung lenken:

Wie sieht es mit den unter iOS (iPhone/iPad/iPod) hinterlegten Zertifikaten aus

Zumindest auf meinem privaten 3G konnte ich dank Jailbreak schon mal ein paar Nachforschungen anstellen - es gibt dort auch Keychain-Files (genaue Pfade und Dateinamen kann ich gern nachliefern), aber es existiert z.B. keine Implementierung des "security"-Befehls, mit dessen Hilfe man auch ohne eine Schlüsselbundverwaltung problematische Zertifikate unter Mac OS X löschen kann …

Wie also bewerkstelligt man das beim iOS?

Davon abgesehen gäbe es ohne einen Jailbreak meines Wissens nach gar keine Möglichkeit, Zertifikate als nicht mehr vertrauenswürdig zu markieren oder (meist wohl besser/sicherer) diese direkt zu löschen.

Zwar gibt es das iPhone Configuration Utility, mit dessen Hilfe man z.B. eigene Zertifikate implementiert (für TLS-Authentifizierung im Netzwerk z.B.), an die schon auf dem Gerät vorhanden und von Apple in das System eingepflegten Zertifikate ist damit aber kein herankommen.

Dieser Vorteil des iOS (man kann im Prinzip kaum noch etwas "kaputt konfigurieren" wie z.B. unter Mac OS X) gereicht dem System in diesem Fall zum Nachteil!

Insbesondere wenn man sieht, dass Apple derzeit offensichtlich nur noch Kapazitäten für den möglichst reibungslosen iCloud/iOS 5/10.7.2 Start hat und eine Sicherheitsaktualisierung weiterhin auf sich warten lässt … macht man sich da so seine Gedanken.

Ganz zu schweigen von Geräten, die nicht mehr mit Updates versorgt werden (mein 3G ist davon auch betroffen, mit 4.2.1 war Schluss).

Ich erwarte ja auch gar nicht von Apple, dass sie alle möglichen neuen Features in ein betagtes Gerät implementieren. Aber ich hätte gehofft, dass zumindest Sicherheitslücken über einen längeren Zeitraum gefixt werden!

Und was ist jetzt besser: Alle löschen oder alle als nicht vertrauenswürdig markieren?

Löschen … Da das "als nicht vertrauenswürdig markieren" in Mac OS X nicht korrekt funktioniert, Zitat:

Owing to an apparent deficiency in the way Safari behaves with respect to root certificate trust (about which I’ve already filed a bug report), it may be better to simply delete the DigiNotar Root CA certificate altogether, since this will result in a more obvious response from Safari when visiting a site that depends on it.

Quelle: