Certificate Order Error

Was heißt "nicht mehr funktioniert": Die gesamte Installation läuft nicht mehr? Oder (wie ich vermute) der Zugriff von außen via ActiveSync nicht?

Und da Sitecare vorhanden ist, nutzt ihr vermutlich die automatische Zertifikats-Erneuerung via Let's Encrypt? Ist magma00.dyndns.org der Host, über den ihr auf euren David geht? Wenn ja, bin ich erstaunt - ich hatte im Hinterkopf, dass dyndns.org-Adressen von Let's Encrypt nicht für die Ausstellung von Zertifikaten akzeptiert werden. Wir haben dafür immer eine Kunden-Subdomain verwendet und diese "umgebogen" oder gleich (z. B. bei Strato) als dynamischen Host eingerichtet.

Also, der generelle Zugriff auf die Webbox von extern klappt, nur am Zertifikat scheitert's? Gibt's unter System -> David -> Ereignisse ggf. noch weitere Meldungen?

Und wie lange ist der dyndns-Eintrag schon aktuell, wenn ihr das Zertifikat anfordert? Ggf. dauert es ein bisschen, bis sich das im DNS durchgesprochen hat. Darauf deutet zumindest dieser Link hin.

Wenn Euer Server über die DynDNS Adresse problemlos erreichbar ist deutet Connection reset by peer auf ein Firewall Problem hin.

Der Server von Let's encrypt kann die Challenge Response nicht von Eurem David abholen.

Das könnte nun Eure eigene Firewall sein, oder auch ein Problem mit Eurer Internetanbindung sein, das dort z.B. Geo location Eingrenzungen vorgenommen wurden welche verhindern das der gerade genutzte Let's encrypt Server, bzw. aus seinem gerede genutzten Adressbereich auf Euren Anschluss zugreifen darf.

Wenn es sich nicht um einen kapitalen Bug in David oder ein temporäres Problem bei LE handelt, denke ich ähnlich wie riawie. Konkret scheint ja das Zertifikat korrekt beantragt zu werden. Im nächsten Schritt möchte LE die generierte Datei http://magma00.dyndns.org/.well-known/ac…ew06JIUcvMZk84: herunterladen, die im Zuge der Erstellung von David dort hinterlegt wurde. Diese Datei müsste von extern über http (Port 80) auch z. B. in einem Browser auslesbar sein, wenn ich das richtig sehe. Sofern die Meldung also nochmals kommt, probier's mit der dann gültigen URL einfach mal aus. Im Idealfall natürlich mit einem Gerät von außerhalb eures Unternehmensnetzwerks, also z. B. per Mobilgerät via LTE.

Mein Tipp wäre aber ebenfalls Firewall, Virenscanner o. ä.

Leider weiß ich aus dem Stegreif nicht, wo David die obige "Verifikationsdatei" auf Dateisyste-Ebene ablegt. Sonst könnte man da ja auch mal schauen. Der Virenscanner auf dem Server hat nicht zugeschlagen?

Zitat von nordtech

Sofern die Meldung also nochmals kommt, probier's mit der dann gültigen URL einfach mal aus.

Das kannste knicken.

Diese Datei wird vom David Server nur für einen sehr kurzen Zeitraum zum Abruf zur Verfügung gestellt und anschließend sofort wieder entfernt. Das ist wichtig, weil dieser Challenge Response Prozess eine gewisse Anfälligkeit des ganzen Zertifizierungssystems darstellt.

Sobald man die Fehlermeldung bekommt ist die Datei daher auch schon längst nicht mehr auf dem Server verfügbar. Oder anders ausgedrückt: Das man diese Datei selbst nicht abrufen kann bedeutet nicht das es ein Problem auf dem eigenen David Server gibt.

Auch der gesamte Pfad zu dieser Datei wird nur kurz dynamisch für den Prozess erstellt und anschließend direkt wieder weggeräumt.

Zitat von nordtech

Leider weiß ich aus dem Stegreif nicht, wo David die obige "Verifikationsdatei" auf Dateisyste-Ebene ablegt. Sonst könnte man da ja auch mal schauen. Der Virenscanner auf dem Server hat nicht zugeschlagen?

Die Datei landet tatsächlich kurze Zeit auf der Platte um für die Webbox lesbar zu sein.
Das der Inhalt dieser Datei den Virenscanner triggert ist allerdings sehr unwahrscheinlich, denn dafür dauert der Prozess vom anlegen der Datei, bis der tatsächliche Abruf kommt dann doch zu lange, so das der Virenscanner bei der winzigen Datei längst wieder sein Interesse verloren hätte, egal wie übereifrig der sein mag.

Die Fehlermeldung bei nicht auffindbarer Datei würde übrigens auch etwas anders aussehen und nicht auf reset by peer lauten.

Zitat von Roland.K

Da Port 80 für die Zertifikate verantwortlich ist, muss es dann wohl an dem liegen.

Ja, für Challenge response wird einzig Port 80 benötigt, was auch nicht änderbar ist.

Am besten erlaubst Du für kurze Zeit mal das Port 80 auch für die Webbox genutzt werden darf und nicht nur für Let's Encrypt. Dann kannst Du selbst von außen testen ob Du auf Eure Webbox zugreifen kannst. Wenn das klappt muss das Problem entweder in einer Geographischen Zugriffsbeschränkung, in Eurer oder der Firewall Eures Providers liegen.

Das:

Zitat von Roland.K

Ich hab das Zertifikat schon gelöscht, aber auch das hilft nicht.

War übrigens ein großer Fehler, denn jetzt hat Dein Server gar kein gültiges Zertifikat mehr zur Verfügung.
Hättest Du das nicht gelöscht wären dir rund 29 Tage geblieben Dein Problem in aller Ruhe zu lösen. Denn bei Let's encrypt sind die Zertifikate stets 90 Tage gültig, werden aber immer schon nach 60 Tagen erneuert um im Fall das diese automatische Erneuerung aus welchen Gründen auch immer mal nicht klappt ausreichend Zeit zur Reaktion und Fehlerbeseitigung zu haben.

Zitat von riawie

Das kannste knicken

Ah, OK, gut zu wissen.

False Positive im Virenscanner könnte man aber trotzdem im Hinterkopf haben, denke ich. Die Kleinheit der Datei lasse ich da nicht gelten, ich habe auch schon Scanner erlebt, die sich an einem 4kb-Intro abgearbeitet haben...

Zitat von Roland.K

Mit netstat zeigt er mir jedoch Port 443 als offen an. Das liegt wohl am fehlenden Zertifikat?

Ja, vermutlich ist der Port offen, aber die Webbox hat sich aufgrund des fehlenden Zertifikats nicht an Port 443 gebunden - das würde im Archiv "Ereignisse" stehen ("bind failed" oder so ähnlich).

Zitat von Roland.K

ch betreue nur noch diesen David-Server. Bei anderen Systemen installiere ich das Zertifikat direkt auf dem Windows-Server. Kann david auch auf lokal auf dem Server installierte Zertifikate zugreifen?

Nein, aber Du kannst natürlich statt der mit SiteCare ohne extra Kosten möglichen Nutzung eines Let's Encrypt Zertifikat schlicht ein anderes Zertifikat über den David Administrator einbinden.

Dazu brauchst Du letztlich nur im David Administrator unter David > System > TLS-Verschlüsselung > TLS-Zertifikate per rechtsklick + Neu ein Zertifikat hinzufügen und dieses dann mit den gewünschten Diensten verknüpfen.
Macht halt aber nur Sinn wenn man da ein länger laufendes Zertifikat einbinden möchte.

Grundsätzlich läuft das mit SiteCare kommende automatische Let's Encrypt aber sehr stabil und zuverlässig, wenn man ihm nicht selbst ein Loch in den Fuß schießt und den externen Zugriff auf Port 80 in irgendeiner Firewall verhindert.

O.K. der Server ist also auf dem Port von deutschen IP Adressen aus zu erreichen und antwortet.

Das ist soweit schon mal gut.

Allerdings sagt das noch nichts darüber aus ob er auch von Amerikanischen oder anderswo auf der Welt gelegenen Adressen aus erreichbar ist.

Das ist zu 99% ein Firewall Problem.
Dieses Problem kann dabei sowohl bei Euch, als auch bei Eurem Internet Provider liegen.

Wenn Ihr selbst an Eurer Firewall in letzter Zeit ( wir reden von 60 Tagen rückwärts seit erstem auftreten des Problems) nichts geändert habt. Und Eure Firewall keine fremd gemanagten IP Blocklisten einbindet sollte Euer Problem also nicht bei Euch selbst liegen.
Dennoch solltet Ihr in jedem Fall die Logs der eigenen Firewall durchsehen.
Das ist normal kein großes Ding, zumal Ihr anhand der David Ereignismeldungen die genaue Uhrzeit kennt und somit genau wissen wo im Log gesucht werden muss (bitte drauf achten das viele Firewall Logs von dedizierten Firewall Appliances die Zeit in UTC angeben und daher im Winter eine Zeitdifferenz von 1 Stunde haben).

Wenn da im Firewall Log nichts auftaucht muss das Problem bereits eine Ebene weiter draußen bestehen.

Da Ihr Euren David Server per DynDNS ansprecht gehe ich mal davon aus das er hinter einem Internet Anschluss ohne feste IP-Adresse hängt.
Manche Provider mögen es nicht das man an solchen Anschlüssen Server betreibt.
Manche blockieren deswegen auch absichtlich Dienste wie Let's Encrypt.

Manchmal ist auch einfach nur beim Provider was kaputt (konfiguriert)

Sprech mit Eurem Internet Provider und frag nach ob es da ein Problem gibt.

Zitat von Roland.K

Plan b:

Ich instaliere ein Rapid-SSL-Zertifikat, was ich bereits auf vielen Servern direkt im Windows gemacht habe. Bei den Mailservern ist das dann als Zertifikat aufgetaucht und konnte einfach aktiviert werden. Greift David tatsächlich nicht auf im System installierte Zertifikate zurück? Gibt es wo eine Anleitung, wie ich solch ein Zertifikat in David einbaue?

Ich habe Dir doch oben erklärt wie Du so ein Zertifikat in den David Server bekommen kannst.
Ist wirklich nicht schwierig, einfach im David Administrator unter David > System > TLS-Verschlüsselung > TLS-Zertifikate per rechtsklick + Neu ein Zertifikat importieren und dieses dann mit den Diensten verknüpfen.

Zitat von Roland.K

Ist das eine Datei im Filesystem des David?

Müsste \\server\david\code\cert\ssl\{euredomain}\certificate_private_chain.pem sein - bzw. alle in diesem Ordner befindlichen Dateien.

Zitat von Roland.K

Gibt es wo eine Anleitung, wie ich solch ein Zertifikat in David einbaue?

s.o.: RE: Certificate Order Error

Wenn das eine Telekom Business DSL Leitung ist könnte die Lösung allerdings auch schlicht in dem von der Telekom bereitgestellten Router und dessen Firewall zu suchen und vielleicht zu finden sein.

Ich gehe jedenfalls bei den aktuell verfügbaren Informationen davon aus das sehr unwahrscheinlich ist, das der David Server selbst Schuld an dem Problem ist.