• - Welche Version von pd-admin wird eingesetzt?
    Aktuellste


    - Welche Version der Serverumgebung wird eingesetzt?
    Aktuellste


    - Welche Fehlermeldung erhalten Sie?
    Browserseitig: "An error occurred during a connection to www.domain.tld. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)"


    - Wie sind die problematischen Dienste konfiguriert?
    Eigentlich standard, nach einem Rollback habe ich aber - ganz ehrlich - völlig den Überblick verloren., zumal mir aus gesundheitl. Gründen im Moment auch die Konzentration fehlt. ;(


    - Welche Logfile-Einträge (zB. Webserver- oder Mail-Logfile) gibt es?
    Ich habe leider nichts schlüssiges gefunden, was darauf hinweist. 'chrischnian', ehem. Mod von hier, konnte mir leider nicht helfen, da er "zu lange raus" ist und sich mit der Materie, insbesondere PD-Admin, über Jahre hinweg nicht mehr beschäftigt hat.


    Ich habe mal einen DEBUG für die betreffende Domain durchlaufen lassen und dabei kam heraus:



    Leider sagt mir das überhaupt nichts.



    Ich hatte eigentlich vor, nur einen eigenen Server aufzusetzen, wo die ganzen ehrenamtlichen Projekte weiterlaufen können und nicht den Einschränkungen eines WebSpaces unterliegen. Das Ergebnis ist nun nach vollzogenen Umzügen, dass u.a. eine Domain, die vorher auf HTTP und SSL lief, bei Aufruf mit der SSL-Adresse einen Error im Browser ausgibt und damit den Eindruck erweckt, dass das Projekt eingestellt sei (was inkorrekt ist, aber User sind bekanntlich zu faul zum Lesen und mutmaßen lieber). ;(
    Es scheint aber ein globales Problem zu sein und nicht nur auf eine einzige Domain bezogen. Mittels .htaccess kann ich leider auch nicht das Problem umgehen und auf HTTP umleiten, da der Fehler wohl vorrangig bedient wird.


    Um Hilfe, am liebsten seitens eines Moderators tatkräftig direkt selbst Hand anlegend (ist wohl einfacher als Befehle hin und her zu schreiben und auf Antwort zu warten, ob's nun läuft), wäre ich sehr verbunden, damit zunächst erst wieder die Funktionalität und Erreichbarkeit gewährleistet ist (ist schließlich Wochenende, da ist es umso gravierender, wenn die "Zocker" nicht auf ihre Kosten kommen).

  • Ich bin ein kleines Stück weiter gekommen:

    Code
    1. /usr/local/pd-admin2/bin/openssl s_client -connect localhost:4433


    Natürlich wird der zurückgewiesen, aber das sind ist bei mir der vorgegebene DEFAULT-Wert auf Port 4433. Gehe ich Recht der Annahme, dass der nicht auf 443 sein müsste?
    Nun ist die Frage, wie ich den Default-Wert korrigere.

  • Falls der HTTPS Port nicht korrekt ist, solltest du mal im Template nachsehen:


    Code
    1. /usr/local/pd-admin2/conf/httpd.conf


    Eventuell solltest du auch mal über netstat nachsehen was da auf Port 4433 läuft. Ich würde einen Fehler seitens pd-admin ausschließen.

  • Ich habe nun den kompletten Server NEU aufgesetzt.
    Formatierung und ein frisches "Debian 7.0 Wheezy Minimalsystem (64 Bit)" von Hause aus, dann


    Code
    1. patch make g++ gcc psmisc rrdtool libc6-dev-i386 lib32stdc++6 lib32ncurses5 lib32z1 imagemagick rrdtool

    drüber gejagt und die Installation gestartet.
    Alles ist gut gelaufen, siehe den Rest der noch sichtbaren Auszüge aus SSH - anonymisiert - anbei.


    Abschließend wurde der Master-Reseller eingetragen, httpd ausgeführt. Dann die Administrativa von PD-Admin aufgerufen, wo ich das 1. "Angebot" erstellt und die 1. Domain (neuer "Kunde") hinzugefügt habe. Nach Aufruf der Domain im Browser mit https, und das, obwohl ich kein Zertifikat o.dgl. erstellt habe, ist ERNEUT ist der selbe Fehler da:


    Zitat

    Fehler: Gesicherte Verbindung fehlgeschlagen
    Ein Fehler ist während einer Verbindung mit www.*domain*.de aufgetreten. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat. (Fehlercode: ssl_error_rx_record_too_long)


    Es scheint mir so, wie als wenn das ein Fehler seitens pdadmin ist, indem ein ungültiges oder fehlerhaftes Zertifikat installiert wird oder ein bestehendes Zertifikat sich auf andere Domains, die mit SSL aufgerufen werden, auswirkt/überträgt.



    Nun habe ich im Apache-Log geschaut und dort ist u.a. zu finden:


    Code
    1. [Sat Jan 10 10:41:05 2015] [notice] Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1j configured -- resuming normal operations
    2. [Sat Jan 10 10:41:09 2015] [notice] caught SIGTERM, shutting down
    3. [Sat Jan 10 10:41:12 2015] [notice] Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1j configured -- resuming normal operations


    Hat jemand eine Idee?



    /Edit: OS genauer definiert.



    Nachtrag:
    Da ich immer noch die Serverauslastungsstatistik in der PD-Admin-Administrativa sehe, obwohl ich sie gar nicht installiert habe, liegt der Verdacht nahe, dass die Serverneuinitialisierung nicht vernünftig über die Bühne ging. Ich werde daher wiederholt von vorne beginnen.

  • Aktuell mag ich überhaupt kein SSL. Ich ging eigentlich nur nach Anleitung auf der PDA-Homepage vor, die das install-all.sh vorgegeben haben.
    Mir stellt sich aber vorab noch die Frage, ob ich lieber die crypt- oder md5-Version nutzen sollte? Was eignet sich besser bei mir?

  • Um das abzukürzen - "Fehlercode: ssl_error_rx_record_too_long" ist die typische Fehlermeldung, wenn du mit https auf den Server los gehst, aber schlicht und einfach noch kein Zertifikat installiert ist. Das ist KEIN Fehler in diesem Sinne. Ich bin mir nicht ganz sicher, was Du erwartest, wenn Du Domains mit https aufrufst, wo Du doch selbst einräumst, dass Du noch kein Zertifikat hinterlegt hast.


    Benutze Deinen Server vorerst ohne https, richte alles ein wie Du es brauchst und dann entscheide, für welche Domains Du ein SSL Zertifikat kaufen möchtest.

  • Nachtrag: Wenn es Dich nur grundsätzlich stört, dass diese Reaktion bei Aufurf mittels https kommt, dann sollte es genügen wenn Du in der /usr/local/pd-admin2/conf/httpd.conf-template die Zeile "Listen 443" auskommentierst. Wenn Du dann tatsächlich mal SSL einsetzen willst, musst Du sie wieder aktivieren.

  • Und da ist der Knackpunkt, mein Bester. Ich hatte in der .htaccess festgelegt, dass von HTTPS auf HTTP umgeleitet werden soll, eben da kein Zertifikat existiert. Dies wird aber übergangen und statt dessen die Fehlermeldung ausgegeben.
    Wie kriege ich es schlussendlich hin, dass die Umleitung auch tatsächlich funktioniert?


    Die WebSite wurde ein ganzes Jahr mit SSL betrieben und entsprechend viele Links gibt es zu der Downloadplattform (Zielseite) im Web. Ich kann schlecht sagen, dass sie alle die Links ändern sollen, ich muss da eine technische Lösung (Umleitung) finden.
    Mein Ziel ist es, die Seitenaufrufe über die HTTPS-Links derart umzulenken, dass sie "lediglich" 1:1 auf HTTP umgelenkt werden und der Error dafür verschwindet.


    Edit: Ich denke, da haben wir uns überschnitten. Ich werde es testen. :)

  • Zitat

    Und da ist der Knackpunkt, mein Bester. Ich hatte in der .htaccess festgelegt, dass von HTTPS auf HTTP umgeleitet werden soll, eben da kein Zertifikat existiert. Dies wird aber übergangen und statt dessen die Fehlermeldung ausgegeben. Wie kriege ich es schlussendlich hin, dass die Umleitung auch tatsächlich funktioniert?


    Nenn mich bitte nicht "Mein Bester".


    Du kannst nicht von https auf http umleiten, wenn Du kein Zertifikat hast, weil dann keine https Kommunikation zustande kommt.


    Wenn Du willst, dass bestehende Links mit https wieder funktionieren, musst Du ein Zertifikat besorgen.

  • Zitat

    Edit: Ich denke, da haben wir uns überschnitten. Ich werde es testen.


    Mein Tipp deaktiviert https komplett. Du erreichst auch damit Dein Ziel nicht. Das erreichst Du nur in dem Du ein Zertifikat besorgst und einspielst.

  • Dies bedeutet also, dass die einzige - kostengünstige - Möglichkeit das Erstellen eines eigenen Zeritifikats ist. Das wird zwar von den Browsern zunächst auf Ablehnung stoßen, aber immerhin kann dann die Umleitung greifen.
    Ich frage mich, wieso man nicht einfach eine Portumleitung einrichten kann á la 'Eingehender Verbindungen von Port 443 umgeleiten auf Port 80', womit eine Zertifikatsprüfung übergangen würde. Das würde hier einiges an Aufwand und Ärger ersparen.

  • Du verstehst das Problem falsch.


    Anders gesagt: Niemand hindert Dich daran, den Port 443 auf den Port 80 umzuleiten. Allerdings wirst Du damit ziemlich exakt das gleiche Ergebnis haben wie jetzt.


    Dein Problem sind ja nicht die Ports, sondern dass der Browser im Falle eines https Aufrufs gerne eine Verschlüsselung aushandeln möchte. Der Server kann aber damit mangels Zertifikat nicht dienen und so kommt es zum Abbruch der Verbindung.

  • Zitat

    Original von WebTeufel
    ehrlich gesagt... verstehe das ganze vorhaben überhaupt nicht :)


    warum soll man versuchen https aufrufen wollen wenn gar kein ssl benötigt oder benutzt werden soll


    Das kommt davon, wenn man nicht alles liest. Dies wurde bereits im Engangsposting erklärt:


    Zitat

    Original von Daedalus
    Ich hatte eigentlich vor, nur einen eigenen Server aufzusetzen, wo die ganzen ehrenamtlichen Projekte weiterlaufen können und nicht den Einschränkungen eines WebSpaces unterliegen. Das Ergebnis ist nun nach vollzogenen Umzügen, dass u.a. eine Domain, die vorher auf HTTP und SSL lief, bei Aufruf mit der SSL-Adresse einen Error im Browser ausgibt und damit den Eindruck erweckt, dass das Projekt eingestellt sei (was inkorrekt ist, aber User sind bekanntlich zu faul zum Lesen und mutmaßen lieber). (...)


    Weiterhin schrieb ich:


    Zitat

    Original von Daedalus
    (...) Die WebSite wurde ein ganzes Jahr mit SSL betrieben und entsprechend viele Links gibt es zu der Downloadplattform (Zielseite) im Web. Ich kann schlecht sagen, dass sie alle die Links ändern sollen, ich muss da eine technische Lösung (Umleitung) finden.
    Mein Ziel ist es, die Seitenaufrufe über die HTTPS-Links derart umzulenken, dass sie "lediglich" 1:1 auf HTTP umgelenkt werden und der Error dafür verschwindet.
    (...)


    Im WebSpace-Paket war ein Zertifikat enthalten, das hat der Server nicht.




    Zurück zum Thema, tbc233 .
    Nach kostenlosen Zertifikaten hatte ich mich bereits mal umgeschaut, nachdem ich die Problematik mit der manuellen Browserfreigabe bei selbst erstellten Zertifikaten erkannt hatte. StartSSL hatte ich dabei schon in's Auge gefasst, aber mangels Zeit - und des überaus schlechten Gesundheitszustands - kam ich bisweilen nicht dazu.
    Gestern habe ich zumindest die Registrierung vorgenommen und mich dann mit deren auth.-Seite herumgeschlagen, die mein Browser trotz jeder Menge Eigeninitiative und Recherche deren FAQs nicht fressen wollte. Scheinbar erübrigt sich die Problematik aber, da zuerst ein Key per Mail abgewartet werden muss (die schalten wohl manuell frei), womit die Browserintegration des Schlüssels für das Zertifikats erfolgt und damit dann die auth.-Seite nutzbar ist bzw. wird (oder wie auch immer das abläuft).
    Gestern Abend bzw. schon in den frühen Nachtstunden kam dann die Mail, dass der Account freigeschaltet sei mit einem speziellen Link, aaaber ... ja, aber ... nun führen sie Wartungen durch und deswegen ist deren Panel nicht nutzbar. - Tja, shit happens. :D


    Ich melde mich später, wenn es mit StartSSL an den Start geht. Mal schauen, wie es mit deren Zertifikat läuft. Beim WebSpace-Paket wurde alles selbst eingerichtet, wird die erste Zertifikatsinstallation meines Lebens.