Beiträge von Nanuk
-
-
Import derselben ICS-Datei in einen (neuen) lokalen Kalender funktioniert einwandfrei.
-
Bei mir sind es CalDAV-Kalender. Die Art sollte aber keine Rolle spielen, weil der SYNC ja erst nach dem Import stattfindet, egal mit welcher Methode.
Gruß
Nanuk
-
-
Sorry, ich hab denselben Fehler wenn ich ics-Dateien importiere. Egal ob ich den Veranstaltungskalender meines Vereins oder die Müllabfuhrtermine unseres Landkreises importieren will.
Wenn ich die Termine einzeln übernehme, kommt gar keine Meldung, obwohl kein Eintrag erfolgt. Nur wenn ich alle zusammen importiere, kommt die Fehlermeldung "Beim Importieren trat ein Fehler auf".
- Thunderbird-Version (78.5.1
- Lightning-Version: interner Kalender
- Betriebssystem + Version: Win10 64bit
- Google-Kalender mit "Provider for Google-Calendar" (ja/nein): nein
- Google- oder sonstiger Kalender mit WebDAV / CalDAV (ja/nein/was genau): Mehrere CalDAV-Kalender + ICS-Kalender
- Eingesetzte Antivirensoftware: Avira
- Firewall (Betriebssystem-intern/Externe Software): --
Gruß
Nanuk
- Thunderbird-Version (78.5.1
-
Das ist ja seltsam. Bei mir funktioniert die Auto-Vervollständigung auch nur, wenn ich im abgesicherten Modus starte und damit das Add-On CardBook deaktivert ist. Allerdings ist in meinen CardBook-Einstellungen kein Haken vor "Einzige Quelle".
Jetzt hab ich mal den Haken gesetzt - und siehe da: Auto-Vervollständigen flutscht wieder wie früher.
Bei mir geht es also genau umgekeht, als virginian empfohlen hat.
Gruß
Nanuk
-
Die Macher der VV wollen partout nicht einsehen, dass nur ein von vorn herein in den gängigen Browsern und MUA installiertes Herausgeberzertifikat ("Builtin Object Token") eines etablierten TrustCenters gewährleistet, dass eben alle Empfänger ein derartiges Absenderzertifikat anerkennen.
Hallo Peter,
da hast Du sicher recht, aber mann muss auch sehen wie schwierig, langwierig und teuer es ist, vor dem Industriekonsortium „CA/Browser Forum“ Anerkennung zu finden. Da aber die Deutsche Telekom bei dem ganzen Projekt Pate stand, hätte ich mit durchaus vorstellen können, dass die Telekom/Telesec das Rootzertifikat von Fraunhofer SIT signiert. Möglicherweise verbietet das jedoch die Policy - ich hab nicht nachgeschaut.Ich kann aber nicht verstehen, wieso ich diese exakt nach SigG §5 durchgeführte Personenidentifizierung nur für die eine, bei der Registrierung angegebene, E-Mailadresse benutzen kann.
Das scheint mir lediglich eine Frage des Prozesses zu sein. Da die Identitätsprüfung mit dem nPA oder mit dem Telekom-Account ja ruck-zuck erledigt ist, haben sie diesen Umstand vermutlich in Kauf genommen. Ich hab mir jedenfalls für verschiedene Mailadressen die Zertifikate in wenigen Minuten besorgt.
BTW: Der Eintrag in den Verzeichnisdienst ist eine mögliche Option und keine Pflicht! (Ich habe diese Option dankend abgelehnt.)
Richtig, es ist aber auch kein Risiko einen ÖFFENTLICHEN Schlüssel öffentlich zu machen. Und der Verzeichnisdienst bzw. die vielen Verzeichnisdienste sind m.E. eines der Hauptgründe, weshalb die meisten Benutzer diese komplexe Technik meiden. Anbieter wie Global TrustPoint sind leider zu wenig bekannt.
Gruß
Nanuk -
Wenn man wirklich die Massen an die Verschlüsselung bringen will, dann funktionieren meiner Meinung nach nur Ansätze, bei denen der Anwender sich um nahezu nichts kümmern muss.
Wenn man dem Anwender die teilweise komplexen Schritte abnimmt, dann muss der aber demjenigen absolut vertrauen, der ihm das abnimmt!
Ein gutes Beispiel dafür ist die Volksverschlüsselung. Sie nimmt dem Anwender
- das Erstellen der Schlüsselpaare ab,
- die Beantragung und Ausstellung eines bzw. mehrerer Zertifikate darüber,
- die Installation der Zertifikate in den verschiedenen Zertifikatsspeichern,
- die Bereitstellung des öffentlichen Schlüssels in einem jedermann zugänglichen Verzeichnis und
- die Prüfung, ob ein gewählter Mail-Adressat einen Schlüssel besitzt und somit an ihn verschlüsselt kommuniziert werden kann.
Eine ganze Menge! Aber man muss sich auch klar machen, dass alle diese Bequemlichkeiten im Hintergrund durch Prozeduren gesteuert ablaufen und der Anwender auch nicht verfolgen kann (und meist auch nicht verstehen würde) was da gemacht wird. Insofern muss an den Ersteller dieser Prozeduren (hier das Fraunhofer-Institut für Sichere Informationstechnologie) ein hoher Anspruch gerichtet werden.
Gruß
Nanuk -
In jedem Fall wirst du neue Zertifikate von StartCom nicht lange mit Mozilla-basierender Software verwenden können.
Danke für die Warnung.
-
Es ist mir schon etwas peinlich....
Die ganze Geschichte hat eine etwas simple Ursache. Und weil man keine richtigen Fehlermeldungen bekommt, sucht man dann in Ecken, die gar nicht von Belang sind.Ursache der Warnmeldung war, dass bei einem Synology-Systemupdate wieder einmal die Filterregel für Port 8443 in der Firewall weggeschmissen wurde (siehe auch
http://www.synology-forum.de/showthread.htm…V)-verschwunden). Leider meldet CardBook dann nicht "Kann keine Verbindung zum Server bekommen", sondern eben die Geschichte mit dem Zertifikat.Kaum hatte ich die Portfreigabe wieder eingerichtet, lief alles wieder normal.
Was ich daraus gelernt habe? Ich hab die automatische Updatefunktion für DSM jetzt deaktiviert, damit sich das nicht wieder über Nacht ergibt.
Danke an SusiTux.Gruß
Nanuk -
Ich nehme deshalb an, Du hast erst später herausgefunden, dass nur CardBook auf den Port 8443 geht?
So ist es. Anfangs wusste ich nicht, welche Verbindung die Meldung auslöst.
Nach dem, was Philippe mir geschrieben hat, bin ich auch nicht mehr sicher, ob die Synchronisation klappt. CardBook meldet zwar "Kontakt xxx, yyy erfolgreich aktualisiert", meint damit aber wohl den lokalen Cache, nicht den Eintrag auf dem Server.
Ich kann mir ehrlich gesagt nicht vorstellen, dass es am Zertifikat liegt. Ich greife ja auch mit anderen verschlüsselten Verbindungen auf diesen Server zu. Allerdings ist das Zertifikat auch für "subject alternative names" ausgestellt und einer davon wird in diesem Fall benutzt. Dies ist aber schon von Anfang an so und die Meldungen kommen erst seit etwa 3-4 Wochen.
Jedenfalls vielen Dank für Dein Engagement in dieser Sache.
Gruß
Nanuk -
Hat der Admin den so vorgegeben?
Ja - das ist die Vorgabe.
-
Zur Information:
Philippe Vigneau meint dazu:Hi
this windows is shown when CardBook cannot connect to the server (status = 0)... this is something I should change...
PhilippeIch nutze derzeit Version 15.1 von CardBook. Warte jetzt auf das nächste Release.
Gruß
Nanuk -
Wenn das der gültige CardDav-Port ist, dann muss CardBook entsprechend eingestellt werden - nicht umgekehrt.
Wenn Du nicht weißt, woher dieser Port in Deinem Fall stammt, dann frage den Admin.
Ja, das ist der richtige Port, der Sync klappt ja regelmäßig. Ich hab als Intervall 30 Minuten eingestellt. Wenn ich mir das Protokoll ansehe, dann steht dort immer in der 11. und 41. Minute jeder Stunde "Synchronisiere aufgrund des periodischen Syncs ...". Und weil CardBook als einzigste Anwendung diesem Port verwendet (IMAP nimmt 143 und CalDAV geht auf 5006) war meine Vermutung, dass es von dort kommt. Möglicherweise gibt es da Timeout-Parameter für die Prüfungen.
Gruß
Nanuk -
Dann bitte ich dich untertänigst um Entschuldigung, dass ich versucht habe, dir gewisse Zusammenhänge zu erklären.
Wird nicht wieder vorkommen.Hallo Peter,
das ist nicht das Problem. Wir leben hier alle von gegenseitger Unterstützung. Jeder nach bestem Wissen. Ich wollte Dir nur sagen, dass Deine Vernutung, es wird bei jedem https-Kontakt das Zertifikat gespeichert, nicht zutrifft.
Gruß
Nanuk -
Der Port 8443 ist etwas ungewöhnlich. Vermutlich handelt es sich um eine Port Redirection des SSL- / VPN-Ports 443.
Hallo SusiTux,
das ist richtig. Ich habe inzwischen auch festgestellt, dass dieser Port nur für den Sync der Kontakte verwendet wird. Bei IMAP und CalDAV werden andere Ports benutzt.
Vielleicht liegt es an meinem AddOn "CardBook". Ich werd mal mit Philippe Vigneau Kontakt auf nehmen.
Gruß
Nanuk -
Hallo,
So richtig verstehe ich das Problem nicht.
das Problem besteht darin, dass Thunderbird alle 20 Minuten eine Meldung produziert, die wieder gelöscht werden muss. In der Meldung steht, dass es kein Problem gibt, sondern das Zertifikat OK ist (siehe Post 1). Muss das sein? Ist das normal? Muss ich mich damit abfinden - oder lässt sich das verbessern?
Das Zertifikat, das hier erst bemängelt und dann für OK befunden wird, ist von StartCom; die ausstellende CA ist im Thunderbird als Zertifizierungsstelle enthalten.
Kein Mensch muss beim Verbindungsaufbau zu einem Rechner dessen Zertifikat von seiner Webseite herunterladen. Deswegen ist das Zertifikat auch nicht in meinem Zertifikatsspeicher enthalten und kann demzufolge auch nicht gelöscht werden.Ich sehe auch keinen großen Sinn darin, Zertifikatsinhalte zu checken - solange Thunderbind selbst zur Erkenntnis kommt, dass das Zertifikat tauglich ist und keine Ausnahmeregel erforderlich ist.
Gruß
Nanuk -
Hallo SusiTux,
Wozu gehört das Zertifikat denn? Ich würde das Zertifikat einfach mal löschen und neu installieren.
das Zertifikat ist von dem Mailserver, der mein Postfach hat oder vom CalDAV-Server, wo mein Kalender liegt oder vom CardDAV-Server, wo meine Kontakte liegen. Da alle auf dem selben Rechner sind, kann ich nicht erkennen, was gerade abgefragt wird. Ich müsste dazu Kontakt mit dem Admin aufnehmen. Aber sehr überzeugend scheint mit das nicht zu sein.
Wie kann man denn der Entwicklergemeinde raten, die Erkenntnis, dass das Zertifikat OK ist, gleich in die Löschung der Meldung umzusetzen?
Gruß
Nanuk -
Deaktivierten Schutz deaktivieren?
-
Wie siehts denn in Deinem Papierkorb aus?
