Beiträge von nitram70

    Moin zusammen,

    ich hinke mit dem SE Update ein wenig hinterher, installiert ist 3-0.312, aktuell ist 333.

    Betriebssystem ist (leider noch) Debian Wheezy. Auch da muss ich dran aber eins nach dem anderen.


    Mit dem Update möchte ich zunächst auf mysql 5.5 aktualisieren. Der Grund sind ein paar sehr etablierte aber auch sehr alte Webforen, die noch auf WBB 3.1 laufen, die können maximal mit mysql 5.5 und die neuste Version kann nicht mit mysql 5.1


    Wie aktualisiere ich mysql? Ist ./se-update.sh -s 4 richtig?


    Weiss jemand von Problemen mit dem WBB und mysql 5.5?
    Ansonsten laufen auf dem Rechner nur Wordpress Seiten.


    Viele Grüße,

    Martin

    Ich hab das Zertifikat von einer Webseite herunter geladen, per FTP wieder hoch (für das Shellscript) und dann verarbeiten lassen.

    Vermutlich ist da irgendwo was schief gelaufen, meinem FTP Client CyberDuck hab ich evtl. vergessen auf ASCII zu stellen...

    Ich hab das Problem gefunden, der Server hat TLS Verbindungen abgelehnt weil das Zertifikat nicht gefunden wurde und somit hat Gmail sich geweigert, sich zu verbinden.

    Beim Blick in die Datei /var/qmail/control/servercert.pem hat sich gezeigt, dass zwischen dem Cert und dem Cacert ein Umbruch fehlte, so das

    -----END CERTIFICATE----------BEGIN CERTIFICATE-----

    in einer Zeile stand. Das hat qmail-smtpd gereicht, das Zertifikat als ungültig anzusehen.
    Nun gehts wieder, ein Test-Telnet auf Port 25 bestätigt TLS, was es vorher nicht tat, und die erste GMail Mail kam gerade schon rein.


    Was bleibt ist die Frage, warum der Umbruch fehlte. Ich habe es mit dem dc-ssl-install.sh Shellscript nicht reproduziert bekommen, selbst wenn ich in der Zertifikatdatei direkt nach dem Trenner alles lösche.


    Vielen Dank für eure Hilfe, Sumeragi und Michael!


    Viele Grüße,

    Martin

    So ein Zertifikat hab ich, darüber läuft ja alles was unterhalb des servernamens aufzurufen ist, roundcube, phpMyAdmin und natürlich pdadmin.

    Wenn ich das installiere drehen aber alle Kunden-Outlooks ab und ich hänge für den Rest des Tages am Telefon.


    Ich glaube ich muss nochmal in den Mail Logs recherchieren, wann die letzte Gmail Mail rein gekommen ist.
    iptables ist nun erstmal leer, ganz nebenbei steigt direkt mächtig die Serverlast an. Die Sperrliste war aber auch echt lang...

    Es ist tatsächlich so, dass ich in den Logs überhaupt nichts sehe. Allerdings muss ich mit der IPv6 Sache zurückrudern, das war ein anderer Server, da hab ich was durcheinander gebracht. Der betroffene Server hat kein IPv6, der MX Hostname ist ein A Record und verweist auf die Server-IP.

    Allerdings ist der Hostname des Servers (vom Provider vergeben) ein anderer als der eMail-SSL-Hostname, den wir an die Kunden rausgeben,

    Der Server meldet sich mit seinem Hostnamen im SMTP Dialog.
    Auch das lief aber vorher schon viele Monate problemlos.


    Macht es Sinn hier mal ein paar records zu posten oder andere Zusammenhänge darzustellen?

    Danke für deine Antwort,

    Ansonsten muss man sich einmal die Mail genauer anschauen, die von Google abgelehnt wird.

    es ist ja so dass keine Mails von Gmail HEREIN kommen. Dabei haben verschiedene Absender an verschiedene Empfänger auf demselben Server dieselben Probleme. Es ist also kein domainbezogenes Problem

    Mailausgang von dem betroffenen Server AN Gmail klappt problemlos.


    Viele Grüße,

    Martin

    Ein von mir betreuter Server nimmt seit gestern morgen keine Mails von GMail mehr an, zumindest scheint es so, dass es an der Serverkonfiguration liegt.
    In /var/log/mail.log taucht überhaupt nichts der Art auf, es ist so als würde die Mail den Server garnicht erreichen.

    Die Fehlermeldung von Google kommt nach knapp 24 Stunden und lautet:

    Zitat

    The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720


    Was mir dazu einfällt:

    • ich habe letzte Woche das Zertifikat getauscht und Comodo statt Letsencrypt verwendet. Hostname stimmt, installiert habe ich es mit dem Script "dc-ssl-install.sh" von B&K.
    • Ich verwende fail2ban mit IP-Tables, augenscheinlich gibts aber auf der Ban-Liste keine IP von Google. Aber Sicherheitshalber habe ich mal durchgestartet und den Filter dadurch gelöscht, das ergab aber keine Änderungen
    • Ich verwende zusätzlich IPv6 weil damit der Traffic kostenlos ist und ich mit einem Kollege darüber HD Space für Dateisicherungen teile.
    • Der Server wird aktuell von http://www.backscatterer.org/ gelistet, angeblich aber schon seit dem 11.5. Das manuelle Delisting soll 89 Franken kosten, was ich als unseriös empfinde und deswegen nicht mache.

    Mehr Besonderheiten oder Ursachen gibts eigentlich nicht.


    Ich habe keine Idee, was hier falsch läuft.


    Viele Grüße,

    Martin

    mit welchem Zertifikatsanbieter hast du das so automatisiert?

    Das ist der Haken: ich hab das nicht automatisiert sondern mache das manuell. Fürs erzeugen des Schlüssels und des CSR sowie der Links hab ich ein Shellscript gebaut, der Rest geht manuell, Beantragung über die Webseite des Anbieters. Bei 30-40 Kunden und zwei Jahren Laufzeit kann man das machen, geht aber sicherlich besser...


    Viele Grüße,

    Martin

    Ich hab das ganze nun für mich erstmal gelöst, ich bin allerdings auf einen anderen Zertifikatanbieter gewechselt, der Zertifikate für 2 Jahre anbietet, allerdings nicht kostenfrei wie letsencrypt.


    Soviel kann ich nun sagen:

    • Es ist völlig egal wie die Zertifikats-Dateien heissen und wo sie liegen, wichtig ist nur, dass in /opt/pdadmin/sslcerts/ die passenden drei Links pro Domain/Zertifikat vorhanden sind. Diese müssen wir oben beschrieben /opt/pdadmin/sslcerts/www.domain.org-cert / -key / -cacert heissen. Die erzeugung der Schlüssel und die Installation der Links hab ich mit einem kleinen Shellscript erledigt.
    • Dazu reicht es dann, in der Tabelle vadmin.vhosts die in Beitrag #5 von Kai beschriebenen Änderungen vorzunehmen. Ob es dazu einen Schalter im Frontend gibt, hab ich nicht geprüft, ich habs direkt in der DB geändert
    • /opt/pdadmin/bin/http_vhosts.pl ausführen und die Zertifikate werden verwendet
    • das von Herrn Bradler gestellte Script dc-ssl-install.sh installiert die Zertifikate für email und ftp
    • mit dem Entfernen der Crons zur Aktualisierung ist das Thema erledigt.

    Zusammengefasst kann man also jeden beliebigen Anbieter und jeden beliebigen Client nutzen, solange die Zertifikate richtig verlinkt sind. Wenn sich jemand mit letsencrypt in Verbindung mit dem Client acme.sh beschäftigen könnte und das hier veröffentlicht, wäre ich dankbar.


    Viele Grüße,

    Martin

    Hallo,

    aktuelles Problem, certbot-auto will nicht mehr laufen bzw. Updates installieren und ich würde daher ebenfalls gerne auf den Python Kram verzichten. Dazu müsste man zunächst wissen, ob nur der Certbot Python benötigt oder auch das letsencrypt Script.


    Hier gibts eine Liste von ACME kompatiblen Clients als Certbot-Alternativen, ein Providerkollege empfahl mir ebenfalls acme.sh


    Hat da schonmal jemand implementiert?


    Viele Grüße,

    Martin

    Gefunden und installiert. Klappt aber nicht zu 100%, ich habe dasselbe Problem wie oben beschrieben, der Login klappt aber der Dateibrowser baut sich nicht auf. Ich nutze Cyberduck auf dem Mac aber auch ein anderer FTP Client tats nicht.


    Im user.log sieht man "Login successfull" aber mehr passiert nicht.


    Code
    1. PassivePorts 6000 6100

    habe ich wie beschrieben eingefügt, keine Änderung.


    Aktivieren des tls.log brachte folgende Einträge:

    Code
    1. 2018-12-09 09:49:04,460 mod_tls/2.6[7563]: TLS/TLS-C requested, starting TLS handshake
    2. 2018-12-09 09:49:04,608 mod_tls/2.6[7563]: client supports secure renegotiations
    3. 2018-12-09 09:49:04,608 mod_tls/2.6[7563]: TLSv1 connection accepted, using cipher ECDHE-RSA-AES256-SHA (256 bits)
    4. 2018-12-09 08:49:04,681 mod_tls/2.6[7563]: Protection set to Private

    Mehr kann ich leider nicht bieten...