Beiträge von WismutKumpel

Hallo Valerie,

Zuerst muss ich dir gleich mal sagen, dass ich (privat) ein reiner Linux-Nutzer bin, ich kann also zu den Verhältnissen auf der WinDOSe nicht allzuviel sagen. (Mein MCSE-Lehrgang ist länger her, als es Mozilla gibt ... .)

Ja, die von dir erwähnte cert8.db ist die "Client Zertifikat-Datenbank". Es spielt aber auch noch die key3.db (mit den evtl. vorhandenen eigenen Schlüsseln) und auch die secmod.db ("Datenbank der Sicherheitsmodule") eine Rolle. gerade bei der letzten kann ich noch nicht einmal genau sagen, was deren exakte Funktion ist.
Aber in der cert8.db sind nicht nur die Zertifikate diverser Zertifizierungsstellen enthalten, sondern auch noch die von TLS-gesicherten Servern, welche du kontaktiert hast. Meine cert8.db zeigt zum Bsp. das heutige Datum.

Unter Linux besteht der Fx und der TB aus mehreren Installationspaketen (die eigentlichen Programme, deren Sprachdateien, die erwähnten Zertifikatspakete, mozilla-nss = das Mozilla-eigene openSSL usw.). Und alle diese Dateien werden unabhängig von den beiden Programmpaketen recht häufig aktualisiert. Ich weiß, dass unter Windows das alles eine Installationsdatei (je Programm) ist, und dass diese wohl nur bei Versionswechseln ausgetauscht werden.

Zurück zur erwähnten "ca-certificates-mozilla".
In diesem Paket sind alle per se im TB und Fx installierten Herausgeberzertifikate drin. Diese werden dann bei der Installation dieses Paketes einzeln nach /usr/share/pki/trust/ entpackt. (Und eben ab und an ergänzt/gelöscht/aktialisiert)
Wenn du wegen Problemen mit dem Zertifikatsmanager die cert8.db löschst, ist sie beim Neustart des Programms wieder da, und auch vollständig befüllt. Jetzt weißt du, woher diese Befüllung bei einem Linux-Rechner kommt!
Ich gehe mal davon aus, dass das auf dem Fenster-Betriebssystem nach einem ähnlichen Mechanismus funktioniert, denn auch da wird diese Datenbank immer wieder neu und befüllt angelegt.
[Vermutung]
Und jetzt meine, diesen Thread betreffende Vermutung: Ein händisch aus dem Zertifikatsstore des Fx oder TB gelöschtes Herausgeberzertifikat wird wohl ebenso wiederhergestellt werden.
[/Vermutung]
Ich werde das zu gegebener Zeit mal austesten, indem ich das Herausgeberzertifikat meiner eigenen "Privat-CA" als .pem-Datei in das o.g. Verzeichnis packe. Dann müsste, wenn ich mich nicht an dieser Stelle irre, dieses bei einem neuen Testprofil "von ganz alleine" installiert sein. Schau mer mal .... .

MfG WK

Hallo fjord1234,

Deine Antwort ("...das ich mir nicht vorstellen kann, Websiten zu besuchen auf denen ich TürkTrust-Zertifikate benötige...") zeigt mir zumindest, dass du die Zusammenhänge mit den Herausgeberzertifikaten verstanden hast.
Trotzdem betrachte ich dein Ansinnen nicht unbedingt als sinnvoll oder besser gesagt, als nicht notwendig.

Warum?
Der Herausgeber eines Browsers, Mailclients, Betriebssystems (=> einer Zertifikate prüfender Software) sollte sich verpflichtet fühlen, anhand einer sorgfältigen Prüfung der Policy ("Zertifizierungsrichtlinien") eines jeden TrustCenters verantwortungsvoll die einzelnen Herausgeberzertifikate vorzuinstallieren - oder besser nicht. In diese Prüfung sollten selbstverständlich auch aktuelle Meldungen über Unregelmäßigkeiten eingehen.

Meiner Erfahrung nach reagieren Microsoft, Mozilla & Co. schon recht zügig auf derartige bekannt gewordene "Unregelmäßigkeiten" und löschen betroffene Zertifizierungsstellen (=> DigiNotar als Beispiel) komplett oder auch nur "verbrannte" Herausgeberzertifikate dieser TrustCenter im Rahmen von Updates aus den jeweiligen Zertifikatsstorer - ohne dass sich die Nutzer darum kümmern müssen. Mitunter ziehen problembehaftete TrustCenter nur die betreffenden Herausgeberzertifikate zurück und verschwinden nicht unbedingt komplett vom Markt, wie es mit DigiNotar passierte.
Wenn du "einfach so" ein TrustCenter rausschmeißt, dann ist es beim nächsten Update wieder drin. Gerade unter Linux kann ich beobachten, dass der Mozilla-Zertifikatsstore (ca-certificates-mozilla) recht häufig geupdated wird.

Zitat

Ich habe mal ein wenig recherchiert und mir die Datei certmgr.msc in Win angesehen.

Die Produkte von Mozilla nutzen nicht den Zertifikatsstore der WinDOSe sondern bringen einen eigenen Zertifikatsstore mit. Hat was damit zu tun, dass der Fx und der TB ja auch auf den alternativen Betriebssystemen laufen.

HTH

MfG WK

Hallo kevlar,

diese Fehlermeldung kommt immer dann, wenn versucht wird, das Programm "Thunderbird" unter ein und dem selben Benutzerprofil ein zweites mal zu starten. Der TB verhindert damit, dass ein in Nutzung befindliches "Profil" mehrfach angesprochen wird, es wird also "gelockt" (gesperrt).
Vermutlich will dein Fx-Add-on genau diesen Start des TB bei der scriptgesteuerten Erzeugung einer neuen E-Mail tun - oder der Thunderbird reagiert "nur" entsprechend darauf.
Genauer kann ich dir das nicht sagen.
Tipp: poste mal dein Problem bei uns im Thunderbird-Forum.

MfG WK

Guten Morgen Firfox-Nutzer,

dann gib doch mal iin die Adresszeile des Fx "about:config" ein und dann den Suchstring "security.tls.version.min"
Dessen Wert setzt du auf "1" und das dürfte es schon gewesen sein.

Mit freundlichen Grüßen!
WK

edit: etwas zu langsam ...

Hallo Andreas,

woher weißt du, dass ULrika überhaupt einen Mailclient benutzt? Und wenn, dann den Thunderbird?
Vielleicht nutzt sie sogar einen gruseligen Webmailclient mit dem Firefox? Soll es ja alles geben ... .

Zitat

Wie kann ich das ändern?

Indem du uns (hier oder im TB-Forum) Informationen lieferst. Sonst wird das leider nix.

MfG WK

Nicht nur der Feuervogel.
Hier sind auch viele weitere Leser und auch Helfer aus dem TB-Forum aktiv oder zumindest "Mitleser".

Deshalb gebe ich dir noch einen Hinweis:
Du solltest dich einmal gründlich über die Bedeutung von und die Unterschiede zwischen:
- IMAP
- POP3 und
- Webmail
informieren!
Gerade deine letzte Bemerkung im TB-Forum zeugt von der Notwendigkeit.

MfG WK

... und im Thunderbird-Forum erwarten wir zuerst einmal die Antwort auf unsere dort gestellten Fragen:

TB-Version?
POP3 oder IMAP <= genau darauf kommt es nämlich an, falls es sich wirklich nur um das Abonnieren handelt
Provider? <= hier natürlich weniger relevant

Wobei ich diese Bemerkung:

Zitat

nach einem Problem mit dem Internetzuganng mußte ich meine e-mail Konten neu sortieren

beim besten Willen nicht verstehe!
- Ich habe es noch nie erlebt, dass ein Problem mit dem Internetzugang den TB "kaputt macht"!
- Und was es mit dem "Sortieren der E-Mailkonten" auf sich hat, ist mir auch unklar.

MfG WK

Hallo stammersdorfer,

ich versuche mal hinter dein Projekt zu steigen bzw. heraus zu bekommen, was du da so beabsichtigst.
Darf ich davon ausgehen, dass dein "kleiner NAS Server" einer der kommerziellen Geräte von Synology (DSxxx), QNAP oder etwas anderes derartiges ist. Sicherlich weißt du, dass alle diese Geräte unter Linux arbeiten und somit mit einer .exe, also einem aufführbaren Programm für die WinDOSe, absolut nichts anfangen können.
Da der Firefox, genau so wie der Thunderbird, sauber zwischen den Programm- und den Nutzerdaten (dem Fx-Userprofil) trennt, macht es eigentlich wenig Sinn, das Programm auf dein NAS zu kopieren. Installieren als Windows-Programm geht ja eh nicht. Aber niemand hindert dich, auf deinen Rechnern den Firefox sauber und ordentlich zu installieren. Bei den meisten Systemen ist dieses Programm ja eh schon installiert. Und dem Firefox ist es prinzipiell völlig egal, wo er sein Userprofil sucht und findet. Die profiles.ini muss nur korrekt auf das Profil verweisen. Im LAN, und das dürfte wohl in den meisten Fällen ein GB-LAN sein, wird auch der Transfer der Profildaten kaum nennenswert (wohl aber spürbar) die Benutzung des Firefox verlangsamen.

Etwas völlig anderes ist es mit dem Remote-Zugriff von extern! Schau dir doch einfach mal die Größe deines Fx-Userprofils an. Ich habe gerade mal bei mir nachgeschaut: mein seit vielen Jahren mitgeschlepptes Profil bringt 68MB mit. Und ich habe hier schon von sehr viel größeren Profilen gelesen. Ich speichere ja auch keine Wiederherstellungen von Tabs usw.
Und wie schnell ist denn so deine Internetverbindung? Ich meine hier speziell deinen Upload und natürlich auch deine Verbindung für den externer Zugriff. Ich wage zu bezweifeln, dass du da, so wie ich ggw. im Urlaub in Dänemark eine symmetrische 100 Mbit/s-Verbindung per FTTH genießen kannst. Sicherlich wird es auch mit einer langsamen Verbindung funktionieren, wenn du wie oben genannt korrekt auf dein Profil verweisen kannst. Aber Freude wirst du keine dabei erleben. Garantiert nicht!

Ich kann nicht verstehen, warum du dich so vehement gegen den Fx-Sync sträubst und dafür eine Bastellösung wählst. Ganz abgesehen davon, dass es z.Bsp. bei den Synology-NAS möglich ist, dort einen Fx-Syncserver aufzusetzen.

Aber wenn du, so wie ich(!), gern bastelst, dann will ich dir als Anregung mal sagen, wie ich das bei meinen vier Thunderbird-Installationen und den beiden Schlau-Fernsprechapparaten (Android) handhabe (beim Fx nutze ich den Sync!):
- Jedes System besitzt ein vollständiges TB-Userprofil (außerdem natürlich die Androiden)
- Alle Mailkonten sind selbstverständlich als IMAP-Konten eingerichtet, damit sind die E-Mails kein Thema mehr.
- Das einzige, was wirklich synchronisiert werden muss, sind die vielen Kalender (ggw. 16!), die Adressbücher und die Datenbank mit den Passwörtern.
Und genau das mache ich in meiner auf einem RaspberryPi (aus reinen Energiegründen nicht auf der Synology!) laufenden OwnCloud. Und da OC die betreffenden Kalender-, Adressbuch- und Passwortdateien immer lokal auf den Geräten vorhält und nur die Änderungen im Hintergrund synchronisiert, merken wir überhaupt nichts davon. Alles läuft genau so schnell wie zu Hause im LAN. Und jeder neue Kalendereintrag usw. ist innerhalb weniger Sekunden auf den gerade laufenden Geräten zu sehen. Dass meine NAS und der RasPi selbstverständlich nicht frei im Netz hängen, sondern nur über ein VPN zu erreichen sind, erwähne ich nur am Rande - das hat nur etwas mit der Sicherheit meiner Daten aber nichts mit der Funktion zu tun.
Prinzipiell kannst du das auch mit deinen Fx-Installationen realisieren, indem du nur einige wenige Daten auf diese Art und Weise aus einem zentralen Datenbestand für alle Installationen bereit stellst.

HTH

MfG WK

Freut mich, dass ich es richtig verstanden habe ich habe sogar gleich an (Flug-) WX gedacht.
Das Problem ist, dass alles was <user> anwenden darf, dieser auch sehen kann. Also egal ob PW-Manager, Startscript mit Passwort, oder irgend eine Datei, aus welcher das PW ausgelesen werden kann, es/sie muss immer mit den Rechten des Users les- oder ausführbar sein. Jetzt kannst du diese "Geheimdatei" sonstwo verstecken und darauf verlinkten, aber damit verwirrst du kaum jemanden.

Vielleicht:
Die Anwendung (wenn sie das mitmacht) dauerhaft in einer VM oder auf einem anderen Rechner von dir gestartet durchlaufen lassen und die Nutzer greifen dann remote (x2go oder vnc usw.) auf den Screen zu.

Mfg WK

Also ich habe das so verstanden:
Jeder kann sich über irgend ein Benutzerkonto an diesem Rechner anmelden und dann die bewusste Webanwendung starten, DEREN PASSWORT er aber nicht kennen soll.

Echte Herausforderung...
PW-Manager fällt aus, denn ohne Master-PW kein Zugang, mit Master-PW kann das PW der Anwendung ausgelesen werden.
Man kann bei verschiedenen Anwendungen den Benutzernamen und das PW mit dem Aufrufstring übergeben. der findige Nutzer kann den natürlich auch sehen.

Mfg WK

Sorry, aber ich habe selten einen größeren Unsinn gelesen.

Der Nutzer, von dem du glaubst ihn erfolgreich ausgesperrt zu haben, lädt sich den portablen Fx herunter oder steckt einen USB-Speicherstick auf dem sich diese Anwendung befindet an diesen Rechner an. Als normaler Nutzer gestartet, hat er sofort seinen eigenen Firefox.
Und wenn er etwas pfiffig ist, kopiert oder verlinkt er sich dein (!) FX-Profil dorthin und hat damit alle deine gespeicherten PW, Links und sonstige Profildaten.

Deshalb: Der einzige sinnvolle Weg ist und bleibt das Anlegen von eingeschränkten Benutzerkonten!

MfG WK

Hallo Bougie,

NEIN, ich kann deine vielen berechtigten Fragen auch nicht alle beantworten. Zumal du wirklich schon sehr viel getan hast!
Und "sicher ist sicher" mag zwar stimmen, aber "allzuviel ist ungesund" auch. Und wenn ein bestimmtes "SIcherheits-"Programm als aggressiv bekannt ist, dann bedeutet das auch, dass hier ab und an mal mit Fehlalarmen zu rechnen ist.

Zitat

Kenne mich mit den Begriffen Host-Datei und Proxy-Einstellungen nicht aus.

Aber dafür liefert die Suchmaschine deines Vertrauens gute Ergebnisse. Zum Beispiel: Hosts -Datei – Wikipedia oder auch Proxy – Wikipedia.
Was du jederzeit tun kannst, ist die in dem Wikipediabeitrag gezeigte hosts-Datei mit der auf deinem Rechner zu vergleichen. Der Pfad dahin ist ja auch beschrieben. Einfach mit einem Editor öffnen. Sieht sie in etwa so aus, wie in dem Beispiel ist alles in Ordnung. Stehen dort aber viele dir völlig unbekannte Einträge drin, KANN das die Auswirkung von Schadcode sein. Ziel: jemand will dich auf bestimmte Seiten umlenken, und ein Schadprogramm hat diverse Einträge dafür verändert.
ACHTUNG: Es kann aber auch sein, dass das mal jemand bewusst gemacht hat, um bestimmte "böse" Seiten gegen localhost (127.0.0.1) zu verlinken. Damit sind diese nicht mehr aufrufbar.

Ähnlich ist das mit dem Proxy. Normalerweise hat ONU keinen Proxy eingetragen. Auch hier KANN ein Schadprogramm Umleitungen programmieren. Das kannst du irgendwo in den Systemeinstellungen überprüfen (ich habe hier keine WinDOSe, kann dir also aus dem Kopf keinen Pfad nennen).

=> Also: Es ist möglich, dass da Schadsoftware was verstellt hat!

Was weiter?
Abgesehen von dem vollig richtigen Einwurf von unserem Boersenfeger, welchen ich bei der Zwischenvorschau gerade entdeckt habe, gibt es für mich nur eine einzige sichere Methode, um einen Rechner auf Schadcode zu untersuchen: Das Booten des Rechners von einer "desinfec´t"-DVD! Bei dem dabei startenden Linux-System werden bei inaktivem (!) Windows vier tagesaktuelle AV-Scanner auf den Rechner angesetzt. Das dauert viele Stunden, hat aber den Vorteil, dass sich der Schadcode nicht vor dem laufenden Windows verstecken oder gar den AV-Scanner deaktivieren kann. Wenn dann alle vier keinen "Befall" gemeldet haben, kannst du sicher sein, alles getan zu haben, was einem privaten Nutzer möglich und zumutbar ist.
Also frage mal einen deiner Kollegen und Freunde, ob er zufällig Leser der c´t ist.

Viel Erfolg!

MfG Peter

OK, das bedeutet also, dass der Firefox dieses "Sicherheitsfeature" lediglich von einer positiven OCSP-Antwort abhängig macht? Na ja ... .

Bei mir war (zur Erinnerung: immer nur "graues Schloss") Security.OCSP.enabled = 0 und das bedeutet: Status = vom Benutzer geändert.
Ich kann mich nur nicht erinnern, diese Einstellung jemals geändert zu haben. Zum einen wüsste ich das, und zum anderen habe ich mir schon vor Jahren angewöhnt, jede Änderung an irgend einer Konfigurationsdatei zu dokumentieren.

Flugs auf "1" geändert, und schon wird das Schloss bei https://mozilla.org grün. Damit der Beweis, dass man das nicht etwa an der Policy festmacht, sondern lediglich am OCSP-Responder.

BTW:
Netter Nebeneffekt: Ich betreibe für meine gar nicht mehr so kleine "Privat-CA" einen eigenen OCSP-Responder. Und dieser ist selbstverständlich auch in allen meinen Zertifikaten eingetragen. Und nun zeigen mir die TLS-Verbindungen zu meinen beiden RasPi und zu meiner Synology-NAS, dass ich hier eigene "EV-Zertifikate" produziere. Schööööön!
Da muss ich doch gleich mal eines der Zertifikate sperren und mal sehen, ob das dann wenigstens richtig im Browser angezeigt wird.

Meinen Dank für die Lösung des "Problems" an den Nachdenklichen!

MfG WK

Hallo,

das Forum hat zwar ggw. andere Probleme, mit denen es sich "mit Freude" befasst ... , aber ich habe versprochen, mir die Zertifikate mal genauer anzusehen und das will ich jetzt abschließen.

Egal mit welchem meiner drei installierten Browser (Firefox, Konqueror und Opera) ich die Seite https://www.mozilla.org aufrufe, es wird wie zu erwarten, immer das gleiche Zertifikat angezeigt und es ist als solches auch herunterzuladen.
Die Zertifikatsseriennummer (08:e4:ee:f2:d2:a0:92:ae:d3:1e:40:b9:95:70:fe:29), die Gültigkeitsdauer, der SHA-1-Hash und der angezeigte MD-5-Hash sind überall gleich und entsprechen den Werten, welche in den Screenshots meiner beiden Vorposter ebenfalls zu sehen sind. Zum SHA-256 komme ich noch.

Ich habe mir auch die Signatur durch den Herausgeber (DigiCert Inc.) angesehen, und deren Herausgeberzertifikat mit einem frisch von denen importierten verglichen => das verwendete Zertifikat von http://www.mozilla.org ist korrekt signiert und somit "sauber". Wenn wir also dem Herausgeber vertrauen, können wir auch dem Z. von mozilla vertrauen.

Zu dem in der Anzeige fehlenden SHA-256-Hash:
Der in der Anzeige zu sehende Hashwert ist jener, der bei der Hashwertprüfung eines im Binärformat (also .der) heruntergeladenen Zertifikates angezeigt werden sollte. Dabei ist es fast uninteressant, ob es sich um einen SHA-1, SHA-256 oder MD5-Hash handelt. Auch wenn MD5 heutzutage als gebrochen gilt und SHA-1 baldmöglich außer Dienst gestellt werden sollte (das empfiehlt das BSI schon mindestens 8 Jahre), so bedeutet das doch lediglich, dass ein "Angreifer" mit viel Zeit und Rechenleistung künstlich eine Datei generieren könnte, welche einen bestimmten, gewünschten Haswert aufweist. Also meinetwegen den eines Zertifikates. Aber diese Datei ist dann lediglich eine größere Ansammlung binären Mülls, welche eben den gewünschten Hashwert hat. Ein verwendungsfähiges Zertifikat ist es garantiert nicht! Intern wurde für die Signatur "unseres" Zertifikates so wie so SHA-256 verwendet.
Die im Zertifikat angezeigten Haswerte sind also lediglich ein Hilfsmittel für "misstrauische" (nein, besser: "sicherheitsbewusste"!) User, welche sich ein Zertifikat mal ganz genau ansehen wollen.

Unabhängig davon kann ich jede mir in die Finger kommende Datei mit der Vielzahl der uns zur Verfügung stehenden "Haswertgeneratoren" (besser: Prüfsummenwerkzeuge) in ihren Haswert zerlegen. Und wie ihr gleich seht, stimmt auch der SHA-256-Hash des mozilla-Zertifikates mit dem im Screenshot von .Hermes angezeigten überein:

peter@sonne:~/Dokumente> sha1sum www.mozilla.der 
6a5ab45927d1165d5d22e47a09d078979f36823d  www.mozilla.der
peter@sonne:~/Dokumente> 
peter@sonne:~/Dokumente> sha256sum www.mozilla.der 
d475eedbffe1eef8191e3e4b88f37311ff6667c502bd9778ec8710e872f91eb9  www.mozilla.der
peter@sonne:~/Dokumente> 
peter@sonne:~/Dokumente> md5sum www.mozilla.der 
8f917e81269067d7d65397a694d05843  www.mozilla.der
peter@sonne:~/Dokumente>

Zurück zur "grünen Adressleiste":
Das was man neuerdings gerne als "EV-Zertifikat" bezeichnet ist genau das, was bei uns als "Zertifikat für die qualifizierte elektronische Signatur" für Personenzertifikate durchgeht. Und eine der Voraussetzungen für ein QES-fähiges (Personen-)Zertifikat ist (§5 SigG) die "Sichere Identitätsprüfung der antragstellenden Person". Und deshalb muss der Antragsteller für ein Serverzertifikat bei uns mit einem notariel bestätigten Handesregisterauszug nachweisen, dass seine Firma diesen Server betreibt und er selbst bestellberechtigt ist. Das bestätigt dann der Herausgeber in dem von ihm signierten Zertifikat, Servername und Eigentümer. Eigentlich sollte das ja auch die Hauptaufgabe eines seriösen TrustCenters sein!
Leider überfluten "Billigheimer" und "Kostnix-Zertifikate" den Markt und leider werden zunehmend auch derartige Herausgeber mit ihren Herausgeberzertifikaten in die Browser usw. bereits vom Hersteller aus installiert. Das bedeutet, kein (Normal-)Nutzer kann mehr sicher davon ausgehen, dass der eingetragene Eigentümer des Servers authentisch ist.
In den kryptischen Zahlenkolonnen unter "Erweitert" im Zertifikat verbergen sich die zwar öffentlich dokumentierten aber nur Fachleuten bekannten Richtlinien und Zertifikatsklassen (Policy). Und ich vermute mal, dass diese Einträge der Firefox auswertet und damit die Kennzeichnung in der Adresszeile gestaltet. Ich wüsste sonst nicht, wo dieses in einem Zertifikat sonst noch untergebracht werden kann.
Und ich weiß auch nicht, warum mein eigener Firefox ein so genanntes "EV-Zertifikat" nicht erkennt und immer nur ein graues Schloss anzeigt - und der Firefox von .Hermes dieses drauf hat. Aber ich muss ja auch nicht alles wissen

MfG WK

.Hermes:
Lass dir bitte mal das Zertifikat anzeigen und poste bitte die Ansicht hier. Will nur mal vergleichen.
BTW: Bei mir ist die Anzeige auch blau/schwarz und ohne Anzeige des Seitenbetreibers. Dem will ich mal mit dem Vergleich auf den Grund gehen.

Hallo allerseits ...

ich nutze hier die v.31.0 unter Linux (openSUSE 13.1) und ich kann mich nicht erinnern, hier jemals eine grüne Adessleiste gehabt zu haben. Ich habe allerdings damit auch keinelei Problem. Ich sorge schon dafür, dass unsichere Kandidaten unter den Herausgebern rechtzeitig aus dem Zertifikatsstore rausfliegen. (Ich guttenborge dazu dienstliches Wissen und wende es privat an. Tage oder Wochen später zieht dann ein Update zumindest teilweise nach.)

[Vermutung!]
Könnte es evtl. sein, dass du auf einem der anderen synchronisierten Geräte irgend ein Add-on oder Thema oder eine dir nicht bewusste Einstellung hast, welche sich dann per Sync auf dem bewussten Client auswirkt?
[/Vermutung]
edit: Ich sehe gerade, dass etwas derartiges/ähnliches Börsenfeger auch im Beitrag #4 vermutet.

MfG WK

Technisch gesehen ist es ein- und dasselbe, ob du die "Lokalen Ordner" oder ein "kastriertes POP3-Konto" benutzt. In beiden Fällen werden die E-Mails in mbox-Dateien gespeichert. Bei den "Lokalen Ordnern" fehlt lediglich die Verwaltung der Server- usw. Daten.
Da hast du beim Versuch, die "Lokalen Ordner" zu nutzen wohl irgend etwas falsch gemacht. Aber wichtig ist ja, dass du eine funktionierende Lösung gefunden hast.

Meine übliche Frage zum Schluss: Machst du jetzt eine regelmäßige Sicherung deines TB-Userprofils?
Schau dir auch mal dazu den folgenden Beitrag aus dem TB-Forum an: Re: [imap+lokal] Suche ideales System für Archivierung

So, und jetzt schnell weg ...

MfG WK

Hallo SueS,

und willkommen im Forum!

Zitat von SueS

Mein Admin hat meinen imap-User auf dem Mailserver gelöscht, d.h. dort sind alle Daten weg (keine Serversicherung).

Mal unabhängig von deinem Problem: Dieser "Admin", der keine Sicherung macht, gehört geteert, gefiedert und aus dem Job gejagt - wenn das o.g. wirklich zutrifft.

Da bis soeben von deinem Problem im TB-Forum noch nichts zu sehen ist, erlaube ich mir mal, hier das Risiko einzugehen, für diesen [OT]-Beitrag von den hiesigen "Powerusern" Dresche zu beziehen und dir gleich hier zu helfen.

Der Thunderbird bietet das (sonst bei IMAP-Clients unübliche!) Feature, in einem dynamischen lokalen Cache ("Nachrichten dieses Kontos auf diesem Rechner bereithalten") alle auf dem IMAP-Server befindlichen E-Mails noch einmal temporär und dynamisch in einer mbox-Datei auf dem Client zu speichern. Temporär und dynamisch bedeutet, dass dies keine lokale Sicherung ist, sondern immer mit dem Server synchronisiert wird! Also was auf dem bestehenden IMAP-Konto gelöscht wird, wird auch in diesem Cache gelöscht! Dieses Feature ist eine, per default aktive Option. Alles weitere geht natürlich nur, wenn diese Option weiterhin aktiv war.

Deshalb: Rechner vom Netz trennen und nicht mehr mit dem Server verbinden!

Lösung für dein Problem:

• Unsere Anleitung lesen und verstehen, Begriffe wie "mbox" und "Profil" müssen bekannt sein! => 12 Profile
• Dann machst du erst einmal eine Sicherheitskopie deines vollständigen (!) TB-Userprofils, denn man weiß ja nie ... . (Verantwortungsbewuste User machen das regelmäßig oder gar täglich!)
• Du beendest den TB und gehst mit dem Dateimanager in dein TB-Userprofil > \ImapMail\<das bewusste Konto>
  Dort suchst du die endungslosen mbox-Dateien ("INBOX" oder auch die mit dem Namen deiner Unterordner) und kopierst diese nach .../Mail/Local Folders. Pass auf, dass du dort keine evtl. vorhandene gleichnamige Dateien überschreibst (sonst eine davon vorher umbenennen). Die Indexdateien (.msf) kopierst du nicht. Nimm alles mit, was du an mbox-Dateien in deinem (ehemaligen) IMAP-Konto findest. Löschen und sortieren kannst du immer noch.
• Beim nächsten Start des TB werden in den "Lokalen Ordnern die kopierten mbox-Dateien als "Mailordner" angezeigt, indiziert und in diesen alle noch vorhandenen E-Mails. Diese kannst du einfach dort liegen lassen, oder du kannst dir auch dort oder auch in einem anderen Mailkonto eine Ordnerhirarchie aufbauen und die Mails nach dorthin kopieren/verschieben.
• Sollten Mails nicht mehr angezeigt werden, hast du die Chance - falls du nicht vorher die Funktion "Komprimieren" genutzt hast - diese bislang nur als gelöscht markierten Mails mit dem Add-on "Recover deleted Mails" wieder herzustellen.

Ich wünsche dir viel Erfolg!

MfG WK

Hallo BS2000,

[OT], denn das gehört eigentlich nicht zu diesem Thread!
w
Wieso irgendwann? (Ja, es gibt Bürger, die noch den "alten" PA haben)
Auf jedem nPA ist bereits ein private key und das dazugehörige Zertifikat enthalten. Dieses Zertifikat ist von seinen Möglichkeiten so beschränkt (bewusst beschränkt worden!), dass es ein reines Authentifizierungs-Zertifikat ist. Das bedeutet, es könnte, wenn alle mitspielen würden, sofort zur Authentisierung seines Besitzers bei der sicheren Anmeldung an diversen IT-Systemen, Foren, bei Banken, Behörden usw. verwendet werden. Der private key welcher zur Authentisierung genutzt wird ist mit einem nur dem Inhaber bekannten Passwort (PIN) gesichert, welches in Verbindung mit dem Mikroprozessor des RFID-Chips nach wenigen (3 ?) Fehlversuchen zur Sperrung dieses Schlüssels führt.
IMHO ist das die ggw. sicherste für die Breitenanwendung geeignete Methode zur Authentisierung. Und von der Sicherheit her stellt diese Anmeldung jede Benutzung von Benutzername/Passwort locker in den Schatten.
Nur leider ist dieses Thema noch nicht in den Köpfen der Nutzer angekommen. Und leider sind die bürokratischen Hürden für die Nutzung noch sehr hoch und leider geistern in den Köpfen noch viele von Unwissenden verbreitete Märchen hinsichtlich der "Unsicherheit" des Verfahrens herum. Und wer will schon Geld für einen Kartenleser ausgeben ... .
[/OT]

Zurück zum Thema!
Mit dem o.g. Zertifikat (*) auf dem nPA authensisiert sich der Nutzer mit seiner eigenen "elektronischen Identität" gegenüber dem Server. Macht also nur dort Sinn, wo eine derartige Auth. gewünscht bzw. erforderlich ist.
Mit dem Zertifikat eines Servers ist es genau umgekehrt.
Der Server zeigt dem Client bei der Verbindungsaufnahme sein von einem vertrauenswürdigen TrustCenter herausgegebenes Zertifikat vor. Damit beweist der Server, dass es sich um exakt den vom Nutzer bewusst angesteuerten Server handelt. Und als "Nebenprodukt" wird die Verbindung auch gleich mit verschlüsselt.
Drängelt sich ein Angreifer mit Hilfe eines "Man-in-the-Middle-Angriffes" in die Verbindung rein, erkennt dies der Client und warnt den Nutzer (so lange es der Angreifer nicht geschafft hat, sich ein gültiges, also von dem ausstellenden und im Client bekannten TrustCenter signiertes, Zertifikat zu beschaffen).

Um ein derartiges Zertifikat vom Client als gültig anzuerkennen, ist es erforderlich, dass diesem für die Gültigkeitsprüfung auch die Herausgeberzertifikate des ausstellenden TrustCenters zur Verfügung stehen. Wir nennen dieses gültige Herausgeberzertifikat auch gern den "Vertrauensanker".
Vertrauen heißt hier, dass wir davon ausgehen können, dass dieses TrustCenter einem Antragsteller nur dann ein auf seinen persönlichen Namen (bei Nutzerzeritifikaten, wie z.Bsp. dem auf dem nPA) oder Servernamen ausstellen, wenn dieser durch Vorlage bestimmter amtlicher Dokumente seine Identität beweist. Bei Servern muss da z.Bsp. ein notariel beglaubigter Handelsregisterauszug gebracht werden, aus dem hervorgeht, dass diese Firma den Server <example.com> betreibt und der Antragsteller von dieser Firma zur Antragstellung befugt ist. Es bedeutet aber auch, dass dieses TrustCenter bestimmten technischen usw. Ansprüchen genügt.
Ob ein TrustCenter diese hohen Anforderungen auch durchsetzt, auf welcher Technik die Zertifikate hergestellt werden, welche personellen, baulichen und verfahrenstechnischen Vorschriften angewandt, welche Prüfungen wann und durch wen durchgeführt werden, uvam. steht in der "Zertifizierungsrichtline" (der "Policy") eines jeden TrustCenters öffentlich beschrieben.
Das kann und will natürlich kein Nutzer lesen und schon gar nicht bewerten! Deshalb übernehmen es die Herausgeber der Browser, Mailclients oder Betriebssysteme "nach bestem Wissen und Gewissen und hoher Sachkunde" (sollte man zumindest annehmen, es gibt leider auch Gegenbeispiele!) diese Überprüfung vorzunehmen und nur den Kriterien entsprechende TrustCenter in ihren Produkten vorzuinstallieren. => Das sind die vielen Einträge, welche bereits im Firefox, Thunderbird oder direkt auf der WinDOSe zu sehen sind.
Und damit werden die Serverzertifikate, aber auch S/MIME-Zertifikate für die Mailverschlüsselung die von diesen TC herausgegeben wurden, auch automatisch als gültig erkannt. (Wenn sie noch innerhalb des Gültigkeitszeitraumes sind, wenn der in ihnen eingetragene "common name" die E-Mailadresse und andere Angaben "passen" und die Signatur valide ist.)

Und was sind nun die Zertifikate, für die wir eine Ausnahmegenehmigung erteilen sollen?
Das sind alle Zertifikate, bei denen "etwas nicht stimmt"!
Kein Herausgeberzertifikat im Client/BS vorhanden, abgelaufene oder gesperrte Herausgeberzertifikate, nicht stimmende Servernamen, üble Tricks der Hersteller von AV-Scannen, die mit Hilfe eines MitM-Angriffs die verschlüsselte Verbindung überwachen möchten usw. Damit kann also der Nutzer alles, was ein X.509-Zertifikat an Sicherheit bringt/bringen soll, aushebeln!

Ich bezeichne diese Ausnahmegenehmigung als die schlechteste Krückenlösung die es gibt! Zumindest sollte diese nur nach sehr gründlichem Nachdenken erteilt werden!

Bei einem bekannten Herausgeber von Zertifikaten kann der User selber etwas nach einem Herausgeberzertifikat suchen. Bei einem Router- oder Drucker- usw. Hersteller findet man fast immer dessen Herausgeberzertifkat - und man kann dieses auch nach entsprechendem Nachdenken bewusst als solches importieren und ihm das Vertrauen aussprechen.
Gleiches trifft zu bei einem von uns selbst hergestellten Zertifikat. Ist es eine Eigenproduktion habe ich auch mein eigenes Herausgeberzertifikat und es spricht absolut nichts dageben, dieses in den Browser usw. zu importieren. Wem sollten wir vertrauen, wenn nicht uns selber?
Ich stelle z.Bsp. mit meiner "Privat-CA" jedes Jahr mehrere Hundert Zertifikate für Familie, Freunde ... und diverse Forennutzer (auch hier ...) her. Und diese Nutzer (die immer wieder nachfragen ...) haben alle mein Herausgeberzertifikat importiert. Vor allem natürlich im Thunderbird. Aber auch so mancher private Webserver, manche ownCloud auf dem RasPi usw. läuft damit.

Fazit: fast immer kann man diese "Ausnahmegenehmigung" vermeiden, indem man bewusst (!) einem nicht gelisteten TrustCenter nach genügend eigenem Nachdenken das Vertrauen ausspricht.

(*) Ich vereinfache hier mal, indem ich nur "Zertifikat" schreibe, und bewusst keine Unterscheidung zw. private key und Zertifikat herausstelle. Zertifikat ist immer öffentlich! Ich versuche überhaupt so verständlich und mit Vereinfachungen zu schreiben, wie ich es noch verantworten kann. Ich will auch bewusst nicht darauf eingehen, dass verbrecherische (und auch staatliche ...) Organisationen gerne mal hier einiges aushebeln indem sie einen Einbruch machen oder TrustCenter zur Kooperation zwingen.

MfG WK

Hallo Fritz,

bei Linux ist alles ein klein wenig anders ... .
Die zu installierenden Programme werden alle in den so genannten "Repositories" (=> "Programmsammlungen") bereitgestellt. Da gibt es zum einen die offiziellen, von openSUSE bereitgestellten Repos mit den stabilen und getesteten Versionen. Diese kannst du bedenkenlos ins System einbinden, und von dort die gewünschten Programme und Betriebssystem-Bestandteile installieren bzw. aktualisieren. Dann hast du ein stabiles und problemlos laufendes System.

Dann gibt es noch eine Reihe als "Community-Repos" bezeichnete Repositories. (Zum Bsp.: http://download.opensuse.org/repositories/m…/openSUSE_13.1/ ) Auch diese kannst du (meistens) als stabil betrachten, und von dort kannst du aber auch neuere Versionen installieren, die es noch nicht in den offiziellen stabilen Zweig gebracht haben. Sie heißen beim Firefox ggw. alle 29.0.1 - gefolgt mit sich fast täglich geänderten weiterfolgenden Versionsnummern. Bei wichtigen Programmen kommen fast täglich neue Versionen! Aber alles zum Bsp. unter Firefox 29.0.1 .
=> Das bedeutet, dass du im stabilen Zweig ggw. "nur" diese Version findest.

Und dann gibt es noch die "unstable"-Zweige. Hier tummeln sich Entwicklerversionen aller Art. Vieles auch schon compiliert und zum .rpm paketiert. Und natürlich kannst du dir auch die offiziellen Quellcode-Pakete herunterladen und selber compilieren.

Du musst dich jetzt entscheiden, ob du ein stabil laufendes System haben möchtest - oder ob du durch die Einbindung von unstable-Repos bestimmte Risiken eingehen möchtest.
Was relativ unproblematisch ist, ist aus den Quellen aktuelle von Mozilla freigegebene (aber eben nicht von openSUSE getestete) Versionen selbst zu kompilieren. Wenn du darauf achtest, dass diese Programme dann in gesonderte Verzeichnisse kopiert werden, kannst du diese unabhängig von den offiziellen Programmen aus den Repos mit deren vollständigem Pfad aufrufen und nutzen.

HTH!

MfG WK

edit: Gegenwärtig kam dein "Nachschlag".
Was hast du denn jetzt für eine Version? Ich habe soeben aktualisiert, bei mir ist es immer noch die Version. 29.0.1-24.1