Certificate Order Error

  • Hallo zusammen,


    ich habe auf einem Windows 2016-Server (aktuelle Patches) ein David mit Sitecare am laufen, was seit ein paar Tagen ohne jegliche Änderungen an Firewall/Server nicht mehr funktioniert. Port 80/443 sind funktionell in beide Richtungen und der Test bestätigt das auch. Ich kann von außen über http/https zugreifen. Wenn man das Zertifikat neu anfordert erscheint folgende Meldung:



    Aktueller Status: Der Download des Zertifikats ist fehlgeschlagen (During secondary validation: 217.92.63.2: Fetching http://magma00.dyndns.org/.wel…-_FlyQPj6Few06JIUcvMZk84: Connection reset by peer, Failed to complete challenge)


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


    Hat wer eine Idee?


    Grüße

    Roland

  • 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.

  • Hallo,


    das Zertifikat kann nicht erneuert werden. Alles andere funktioniert problemlos, nur eben das Zertifikat nicht mehr. Bei der Beantragung (siehe Anlage). In den Protokollen kann ich nichts finden was Info gibt. Gibt es dazu ein spezielles Protokoll?


    Kann es am dyndns.org liegen? Das hat tatsächlich seit Jahren problemlos funktioniert.


    Grüße Roland

  • 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/.wel…-_FlyQPj6Few06JIUcvMZk84: 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?

  • Ich hab mal die offenen Ports mit dem Portscanner am Server "im Lan" geprüft. Port 80 ist offen, aber Port 443 nicht. Mit netstat zeigt er mir jedoch Port 443 als offen an. Das liegt wohl am fehlenden Zertifikat? In der Firewall ist für Port 443 seit Jahren drin.


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

    Edited once, last by Roland.K ().

  • 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.


    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.

  • 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:

    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.

  • Ich 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?

  • 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... ;)


    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).

  • 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.

  • Hallo, das Problem ist eben, dass der Port 80 in beide Richtungen funktioniert und David das im Verbindungstest anzeigt. An der Firewall und am Server ist seit Monaten nichts mehr verändert worden. Wie aus dem Nichts geht das plötzlich nicht mehr. Es ist echt zum Haare raufen ....

  • 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.

  • Hallo,


    erstmal vielen Dank für die Informationen!


    Es gibt eine feste IP-Adresse von der Telekom-Business-Leitung. Die dyndns-Adresse stammt schon aus der zeit, als es diese nicht gab. Ich habe eben mal mit "Certify the Web" auf einem anderen Rechner im Netz versucht ein Zertifikat bei Letencrypt zu beantragen, aber da kommt tatsächlich die gleiche Fehlermeldung. Auch mit einer anderen Domain geht das nicht.


    Plan a:

    Hat wer Ahnung ob ich das in David gelöschte Zertifikat aus der Datensicherung wiederherstellen kann? Ist das eine Datei im Filesystem des David? Ich hätte dann noch ein paar Tage zur Fehlersuche.


    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?


    Grüße

    Roland

  • 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.

  • 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.

  • Hallo,


    der David-Server ist nicht die Ursache. Ich kann auch auf keinem anderen Rechner Letsencrypt-Zertifikate ausstellen. Es ist ein großer Mikrotik-Router. Eventuell müsste da mal ein Update gemacht werden ..... Werde das mal prüfen.


    Grüße

    Roland

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!