Beiträge von Sumeragi

    Das komische ist halt, dass auf diesen Ports ja gar keine Zertis involviert sind und es bricht bei ihm trotzdem ab.

    Das ist so nicht richtig. Auf Port 25 und 587 ist starttls verfügbar. Bei #14 sieht man am zweiten Befehl, dass das Zertifikate mit openssl s_client und -starttls smtp auf Port 587 abgefragt werden kann. Starttls kann auf Port 25 von anderen Servern verwendet um Mails verschlüsselt einzuliefern.


    Die Verbindung auf Port 25 hatte nicht geklappt und brach direkt ab. Wie wir nun wissen war dies aber kein Zertifikatsproblem. Hier war die Ausgabe von mxtoolbox leider irreführend. Man hätte schauen können, ob der Dienst überhaupt korrekt läuft:

    Bash
    svstat /service/qmail-smtpd/

    Wenn der Dienste immer nur für wenige Sekunden läuft ist etwas faul. Dann kann man mit

    Code
    svc -d /service/qmail-smtpd/
    /service/qmail-smtpd/run

    den Dienst stoppen und direkt auf der Shell starten. Dies kann man auch machen wenn der Dienst normal läuft und man Meldungen direkt auf der Shell bekommen möchte. Wahrscheinlich hätte man da Fehler gesehen. Spätestens aber mit einem erneuten Test mit telnet.


    Bei mir läuft der Dienst übrigens problemlos mit einem softlimit von 125MB. Eine pauschale Empfehlung das Limit zu erhöhen ist in sofern als kritisch zu betrachten, da man keinerlei Informationen zum System hat. Das softlimit soll verhindern, dass zu viele Ressourcen verwendet werden. Ein zu hohes Limit bei zu geringen (freien) Ressourcen kann daher genauso zu Problemen führen wie ein zu geringes Limit. Ich würde daher die 256MB nur setzen, wenn dies auch notwendig ist.

    die erste hat 125000000 und die zweite 128000000

    aber beide auf den 128000000 angepasst

    qmail-smtpSd ist Port 465. Dies wurde hier gar nicht getestet.


    Es wurden auch keine Log Einträge bzgl. Speicherlimits gepostet. Auf Verdacht Werte erhöhen würde ich daher nicht.

    Es ist gar nicht genau klar was gemacht wurde und wo genau jetzt das Problem besteht. Fehlt nur das TLS Zertifikat bei dem Dienst? Wird dies ausgegeben?

    Also erst einmal sollte geklärt werden wo es jetzt genau Probleme gibt, denn...


    - in Titel steht dovecot

    - getestet wurde auf Port 25, 587 - dies ist qmail und nicht dovecot


    Laut der lsof Ausgabe laufen die Dienste auf Port 25 und 587.


    Ich würde einmal prüfen, ob ein TLS Zertifikat ausgegeben wird:

    Bash
    $ echo "" | openssl s_client -servername <server> -starttls smtp -connect <server>:25 | openssl x509 -noout -dates
    $ echo "" | openssl s_client -servername <server> -starttls smtp -connect <server>:587 | openssl x509 -noout -dates

    Offenbar sind telnet und nmap nicht installiert. Die Ausgabe hilft somit nicht...


    Anhand der curl Ausgabe sieht man aber, dass ein Apache mit einem 403 Forbidden Fehler antwortet. Eigentlich sollte dort die Standard Apache Seite "It work's" kommen...

    Es wurde bisher viel getestet, aber scheinbar noch nicht in den Logs geschaut. Ich würde dort einmal schauen. Insbesondere zu dem curl Aufruf sollte es einen Eintrag geben.

    tbc233:

    Ich hatte

    Das hat soweit geklappt.

    so verstanden, dass die Einrichtung eines Zertifikats geklappt habe. Wenn dies nicht geklappt hat, muss man natürlich weiter vorne anfangen und prüfen.


    Die interessante Frage wäre also nun welche Ausgabe man bei Ausführung von letsencrypt erhalten hat.

    Ich denke da ist letsencrypt nicht installiert oder?

    Ja, das wird es sein. Es wird nicht automatisch ein Sicherheitszertifikat eingerichtet. Mit

    Bash
    /opt/pdadmin/bin/letsencrypt s2.domain.tld

    wird ein Zertifikat für den Hostnamen eingerichtet. Wenn das Zertifikat auch für die übrigen Dienste eingerichtet werden soll, kann man

    Bash
    /opt/pdadmin/bin/update_host_certificate.sh

    ausführen.

    Ein weiteres Problem, wo ich denke das hängt zusammen: Jede Nacht bekomme ich eine E-Mail mit dem Inhalt:



    Code
    /usr/local/pd-admin2/share/mkdhparams: 41: /usr/local/pd-admin2/share/mkdhparams: /usr/local/bin/certtool: not found

    Dies hatten wir bereits im Forum mehrfach thematisiert (siehe hier). Der Cronjob dazu kann entfernt werden.

    Nein, dies ist nicht möglich. Ein externer Nutzer kann keinen Einfluss auf die Filterung/Sortierung von Mails auf dem Server nehmen.

    Dies geht nur mittels Filter. Man kann dazu Sieve Filter einrichten. Es sollte bei aktuellen Installationen bereits eine Regel aktiv sein:

    Code
    $ cat /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/sieve-global.conf
    require "fileinto";
    if header :contains "X-Spam-Flag" "YES" {
    fileinto "Auto-SPAM";
    }

    Die Regel gilt für alle Nutzer.

    Ab Reihe 4 steht openssl 1.1.1 zur Verfügung. Somit also auch TLS 1.3. Ich habe daher

    Code
    TLSProtocol TLSv1.2 TLSv1.3

    bei mir drin stehen. Auch kann man in dem Zuge über die verwendeten Ciphers nachdenken. Bei mir kommen

    Code
    TLSCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA38

    zum Einsatz. Ist aber natürlich auch abhängig davon wie sehr man "abwärtskompatibel" sein möchte.


    Nachtrag:

    Ich habe mich dabei an die Empfehlung von https://ssl-config.mozilla.org…&ocsp=false&guideline=5.6 gehalten.

    Das Problem bei der Validierung war der fehlende Alias bei dem Port 80 vhost.


    Der RedirectMatch sollte bestehen bleiben. Ohne findet keine Weiterleitung auf HTTPS statt. Bei einem einfachen Redirect werden auch die Validierungsanfragen weitergeleitet. Nur folgt let's encrypt der Weiterleitung nicht. Daher der RedirectMatch.

    Domain: admin20.xxxxxxxx.de

    Type: unauthorized

    Detail: Invalid response from http://admin20.xxxxxxxx.de/.we…me-challenge/HPKYtxxxxxxx [2x3.1x2.1x8.1x1]:

    "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p

    Es ist ein 404 Fehler. Vermutlich fehlt im httpd Template der Eintrag

    Code
    Alias /.well-known/acme-challenge/ /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/

    im vhost für pd-admin.

    Ohne die Fehlermeldung wird es für Außenstehende ohne Glaskugel schwer etwas dazu zu sagen ;)


    Kommt ein 404 Fehler? Dann würde ich einmal prüfen, ob der Pfad passt. Eventuell fehlt im Template auch im vhost der Alias für .well-known/acme-challenge/ - dann wird nämlich /usr/local/pd-admin2/htdocs versucht aufzurufen.

    Ich verstehe nicht so ganz was genau das Problem oder die Frage sein soll.


    AP24: creating run-v2, symlinking to run

    Offenbar wird/wurde bei dem Update /service/apache24/run-v2 angelegt und ein Symlink erstellt.

    Alle Dienste scheinen aber regulär gestartet zu sein.


    Nachtrag:
    im Verzeichnis /usr/local/pd-admin2/httpd-2.4/bin ist auf der maschine cur die apachectl drin, während auf anderen jede menge andere Dateien sind von ab bis suexec

    Bei mir sind mehrere Binaries enthalten. Schaut man sich das Update Skript an, wird dort nichts mit dem Apache bin-Verzeichnis gemacht. Das kann also nicht von einem PDA Update kommen. Das Skript selbst startet auch nur qmail-smtpd und den Apache neu. Andere Dienste werden nicht angerührt.