OK, ich denke nicht, dass es an unserer Konfiguration liegt, bei einem Kunden ist das Problem soeben identisch aufgetreten. Die letzte automatische Aktualisierung funktionierte noch reibungslos.
Also: Fehler bei Let's Encrpyt? Oder Bug in Rollout 414?
Moin,
bei uns wäre heute die Erneuerung des Webbox-Zertifikats via Let's Encrypt dran. Es kommt aber nur:
(AC) Certificate Order Error
Code: 1008
Error: Order certificate request failed
StatusCode: 500
Description: Failed to complete challenge
Reason: Request failed
An der Konfiguration hat sich nichts geändert, Port 80 ist offen, Webbox läuft. Porttest OK. Ich kann unsere öffentliche Adresse problemlos ansprechen, sowohl über den Hostnamen als auch über die IP.
Problem bei LE? Oder was kann das sonst sein? Hat jemand von euch schon ein neues Zertifikat angefordert bzw. erhalten, seit Rollout 414 draußen ist?
Moin,
zu a) hat mir Tobit vor Kurzem geantwortet, dass das nicht möglich sei. Ich würde mir ebenfalls eine entsprechende Option oder einen Reg-Key wünschen, mit dem die Meldung unterdrückt wird. Aber der neue Client soll wohl "gepusht" werden.
Für den Einsatz des (durchaus sehr guten) in David eingebauten SPAM-Schutzes, bei Tobit MIS genannt, wird afaik eine aktuelle Version benötigt, also david.3 - mit der alten fx.12 kommt man an der Stelle nicht weit.
Es gibt allerdings einige Drittanbieter-Lösungen, die an die Plattform keine so strengen Anforderungen stellen. Spontan fällt mir DvSPAM von SyntaX ein. Oder ihr arbeitet mit einem SPAM-verdauenden Proxy, einer Firewall, oder, oder... Möglichkeiten gibt es da viele.
sicher das es keine signierten Nachrichten sind?
Da wäre das ändern nämlich verboten und sollte auch unmöglich sein...
Leuchtet ein, aber das kann ich ausschließen. Es sind bei mir alle Nachrichten betroffen, sogar die Script-generierten plain-text-Meldungen der Datensicherung...
Mail markieren, rechte Maustaste, Eigenschaften, Betreff ändern
Ulkig: Das funktioniert in der Tat einwandfrei. Danke, ist ein guter Workaround.
ich mach das zwar meist in der Eintragsliste mittels F2
Das klappt ebenfalls. Komplett öffnen + ändern + speichern hingegen nicht.
Ulkig 2: Stelle gerade fest, im Modern Client tritt das Problem nicht auf... Da der Classic Client nicht mehr weiter entwickelt wird, bringt eine Nachfrage bei Tobit vermutlich nix.
Naja. Mit der Lösung/den Lösungen kann ich leben, es geht in 99% der Fälle eh nur um den Betreff.
Danke euch!
Moin zusammen,
ich sehe vermutlich gerade mal wieder den Wald vor lauter Bäumen nicht. Bis vor einiger Zeit habe ich gerne Einträge in meinem persönlichen Eingangsarchiv angepasst. Da kommt zum Beispiel eine Mail von der Fritzbox mit dem Betreff "Nachricht von 12345 98765" - wenn das etwas ist, auf das ich später antworten wollte, habe ich die Nachricht geöffnet, den Betreff geändert (z. B. hinten dran gehängt: "Herr Müller Rückruf am Donnerstag") und die Sache mit Strg+S gespeichert.
Seit neustem funktioniert das nicht mehr. Statt dass der Eintrag direkt gespeichert wird, erscheint eine Abfrage, wo ich speichern will, und dort legt David dann eine Kopie des Eintrags ab. Was blöd ist, da damit auch die zeitliche Sortierung nicht mehr stimmt.
Mache ich irgendwas falsch? So ganz zeitlich einordnen kann ich es leider nicht, denke aber, dass es so vor ungefähr 6 Monaten noch problemlos funktioniert hat. Ich benutze nach wie vor den Classic Client (aktuelles Rollout). Hat jemand ne Idee?
Der SQL-Server ist bei David eher "Beiwerk", da sind bzgl. Usern, Konfiguration etc. keine relevanten Sachen gespeichert. Wenn du noch keine Chats hast, die erhalten bleiben müssen, kannst du die Datenbanken im SSMS einfach weglöschen und dann den Service Layer neu starten - auf diesem Wege werden die DBs automatisch neu erzeugt (Disclaimer: AFAIR. Wenn du unsicher bist, mach vorher eine Sicherheitskopie der Datenbanken).
Dazu muss natürlich trotzdem die prinzipielle Kommunikation mit dem SQL vom Service Layer her möglich sein. Was mir spontan dazu einfällt:
14.0.x ist SQL-Server 2017, ja. Das aktuelle kumul. Update müsste dieses sein: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5016884 (über Windows Updates sollte ebenfalls klappen, ggf. die Option "weitere MS-Software über Windows Updates aktualisieren" aktiv schalten).
So sollte das ungefähr aussehen:
Wurde der SQL-Server im Rahmen des David-Setups automatisch eingerichtet, oder hast du das manuell gemacht? Verpass dem mal die aktuellen Patches (wenn Standard Tobit-Installation: Auf Sprache "Englisch" achten), lade dir das MS SQL Server Management Studio herunter und schau, ob eine Verbindung möglich ist und in der Instanz DAVID bereits Datenbanken existieren.
Generell kannst du dort auch die DB zurücksetzen, allerdings sieht mir das oben eher so aus, als ob gar keine Kommunikation mit dem SQL möglich wäre. Grätscht evtl. die Firewall dazwischen? Klappt die Anmeldung via SSMS?
Schau mal in den Diensten, ob der SQL-Server (Instanz DAVID) korrekt installiert ist und läuft. Falls ja: Sagen im David-Client die Einträge unter System -> David -> Ereignisse irgendwas?
Die allermeisten Einstellungen (zumindest serverseitig) bleiben erhalten, wenn man entweder den Servernamen beibehält und stumpf das gesamte David-Verzeichnis überkopiert ODER den offiziellen Weg mit den Tobit Migration Servicves wählt. Letzteres kann bei sehr umfangreichen Archiven ein bisschen an der Geduld nagen.
Wenn du manuell alles mit Strongbox-Archiven umziehst, gehen die Einstellungen verloren, und bei einer Neuinstallation erhalten die Benutzer neue User-IDs. Woher soll das System auch wissen, wie es vorher war?
Das Zertifikat von globessl.com ist da, aber beim importieren verlangt er auch ein Passwort
Nee, das Zertifikat importierst du nicht auf die Smartphones, daraus baust du dir eines für die Webbox. Die weist sich damit dann "offiziell" als korrekte Gegenstelle aus, und der Weg mit dem manuellen Import entfällt.
Bastle dir eine neue Textdatei. In die kopierst du einfach untereinander die Inhalte der folgenden Dateien rein, die du von GlobeSSL erhalten hast:
1) Eigenes Zertifikat (kundenname.crt) (online bei globessl.com: CRT code)
2) Intermediate 1 (GlobeSSLDVCA.crt) (online bei globessl.com: CA code, erste Hälfte)
3) Intermediate 2 (USERTrustRSAAAACA.crt) (online bei globessl.com: CA code, zweite Hälfte)
4) Private Key (den du bei der Erstellung des Cert-Requests gespeichert hast).
Die Intermediates sind nicht zwingend nötig, sorgen aber für ein besseres Grading.
Diese Textdatei speichern als "WBCERT.PEM" (nicht "WEBBOX.PEM" !) im Verzeichnis \DAVID\APPS\WEBBOX\CODE, in der Konfiguration der Webbox Haken setzen bei "Zertifizierungspfad übertragen", in der Zuweisung der Zertifikate im David Admin ggf. die Pfade anpassen, dann Webbox neu starten.
Läuft die Webbox wieder, kannst du z. B. unter https://www.ssllabs.com/ssltest/ mal eure Domain eingeben und schauen, ob da alles schön grün ist. Mit obigen Einstellungen (Intermediates + Zert.-Pfad) sollte mindestens ein "A" herauskommen.
Nach dem Bestätigen kommt trotzdem wieder der Fehler:
Hast du das Zertifikat zusätzlich, wie von riawie in Beitrag 25 beschrieben, in den Zertifikatsspeicher des Smartphones importiert?
Welches muss ich denn wohl da bestellen?
In der Auswahl wäre das einfache Sectigo PositiveSSL vermutlich ausreichend. Du brauchst ja nur ein ganz einfaches für "Domain Validation".
Wie kann ich das denn bearbeiten
Bau dir einfach schnell ein neues.
Mach eine Sicherheitskopie eures jetzigen Zertifikats, vermutlich \David\Apps\Webbox\Code\wbcert.pem
Dann \David\Util\Windows\TLSCERT\tlscert.exe aufrufen und im Tool folgende Werte hinterlegen:
Certificate Type = Self Signed
Key Length = 2048
Country Name = DE
State or Province = Bundesland
Locality Name = Stadt
Organization Name = Firmenname
Organizational Unit = n/a
Common Name = EXAKTE (Sub)Domain David
Contact e-Mail = Mailadresse
Optionale Attribute: Leer lassen, Valid Days kannst du dir aussuchen (z.B. 366)
Wichtig ist dort halt, dass "Common Name" exakt der Adresse entspricht, über die du per Smartphone drauf zugreifst. Also z. B. eure dyndns-Adresse, ohne http(s)-Präfix. meindavidserver.dyndns.org etwa.
Die über das Tool erstellte Datei speicherst du als WBCERT.PEM in \David\Apps\Webbox\Code ab und startest dann die Webbox neu.
Schön finde ich das trotzdem nicht, auch wenn's funktioniert. Der Kostenaufwand für ein offiziell beglaubigtes Zertifikat ist ja nun wirklich minimal. Aber gut.
Ich will ja eigentlich kein Zertifikat für eine Webseite
Doch doch, in diesem Fall schon. Du willst ja damit keine E-Mails signieren/verschlüsseln, sondern ankommenden Clients nur bestätigen, dass sie den korrekten Host zu fassen haben. Gut, ist in diesem Fall nicht wirklich eine "Webseite", aber eben ein Dienst-Host.
Du brauchst: 1) Einen Hostnamen, der auf eure Adresse zeigt, da Zertifikate nicht für IP-Adressen ausgestellt werden können (nützt dir bei dynamischen Adressen eh nix). Wie gesagt, ich meine im Hinterkopf zu haben, dass Let's Encrypt keine Zertifikate für dyndns.org-Adressen ausstellt, bin da aber nicht ganz sicher. Falls doch, kommt der Tipp von ComputerManni ins Spiel, evtl. ist es schlau, sich bei Strato ein Billigpaket mit dyn. Host nur für diesen Zweck anzuschaffen.
2. musst du dann für diesen Host ein Zertifikat anfordern. Für LE geht das nur "zu Fuß" über die oben verlinkten Methoden. Ich hab' das seinerzeit offen gestanden als zu kompliziert empfunden und mir statt dessen ein einfaches Zertifikat bei GlobeSSL geholt ("Globe Standard SSL"). Einfache Domain Validation (DV), mehr brauchst du an der Stelle nicht. Andrere Anbieter gehen natürlich ebenso, GlobeSSL ist relativ billig. Für den Bezug erstellst du auf dem David-Server ein certificate request, z. B. mit der TLSCERT.EXE im Util-Verzeichnis. Mit dem ausgestellten Zertifikat musst du dir anschließend eine .pem-Datei bauen und diese der Webbox "unterjubeln".
Anschließend sieht es im Browser dann im Idealfall so aus, wenn du die Webbox-Adresse von extern aufrufst:
OK, im Screenshot steht neben der URL ein Ausrufezeichen, und es handelt sich um einen dyndns.org-Host (klappt LE damit überhaupt? Ich meine mich zu erinnern, dass wir bei allen Kunden auf andere Anbieter umgeschwenkt sind oder ein Konstrukt mit CNAME-Weiterleitung gebaut haben, weil die Ausstellung direkt auf xyz.dyndsn.org nicht funktionierte).
Ich gehe weiterhin davon aus, dass das Zertifikat Schuld ist.
Auf dem A40 funktioniert er weiterhin
Ich glaube nicht, dass wir hier weiter kommen, solange du uns nicht verrätst, welches bzw. welche Art von Zertifikat die Webbox nach außen weitergibt. Bitte:
Im Browser david aufrufen und schauen was das Zertifikat sagt.
Ports passen soweit, eingehend muss für ActiveSync nur 443 ankommen. Ich tippe auch zu 90% auf ein Zertifikats-Problem. Vielleicht ist ein Gerät da toleranter als das andere - früher[tm] war es gängig, dass auch selbstsignierte Zertifikate geschluckt wurden, seit einigen Jahren allerdings wollen die meisten Systeme ein offizielles.
Was bekommst du denn im Browser angezeigt, wenn die den Webaccess öffnest und mal in der URL-Zeile auf das Schloss klickst?
Zertifikat kostenlos wird schwierig, ginge wohl über Let's Encrypt, habe ich aber auf manuellem Wege nicht mehr ausprobiert, seit die Funktion in David eingebaut ist (für Installationen mit aktivem Sitecare).
Bei Kunden ohne Sitecare nehme ich i. d. R. ein günstiges Zertifikat z. B. von GlobeSSL. Das liegt bei knapp 10 Euro brutto für ein Jahr und ist damit auch für kleine Installationen verschmerzbar.
Ja, beim Weiterleiten scheinen Anmeldung und Verschlüsselung verloren zu gehen, egal, was im Postman für den Smarthost konfiguriert wird. "Gut", dass es auch bei anderen auftritt, dann hoffe ich mal auf einen zeitnahen Hotfix.
Nein, das läuft über eine Weiterleitung im Postman. Der Auftrag erscheint im "In Transit" als "Rundsendung" (obwohl nur an einen Empfänger gerichtet - weiß nicht, ob das vorher auch schon so war), und wird kurz darauf vom Provider mit obiger Meldung abgelehnt.
Sendemethoden etc. sind nicht definiert, die Mail muss mit den Standard-Postman-Einstellungen auf den Weg gehen.
Wie gesagt - bringe ich aus dem David-Client eine Mail mit identischem Absender und Empfänger auf den Weg, läuft's. Schon sehr merkwürdig.
Gestern, vor Rollout 411, funktionierte das noch einwandfrei. 
Nun habe ich schon wieder etwas Angst, was bei den Kunden passiert, wenn sich dort am WE David aktualisiert...
