Beiträge von Sumeragi

Zitat

Original von Eisenherz
PATH=$PATH:$HOME/bin
export PATH

Die binaries wurden nicht gefunden. Da sie in /sbin liegen, fehlt der Pfad in der PATH Variable.

Vielleicht auch Mal folgende Lösung prüfen:

https://unix.stackexchange.com…emon-in-the-path-variable

Wie sieht denn die .bashrc jetzt aus?

Zitat

Original von Twilo
wäre es möglich, dass das Script /opt/pdadmin/bin/letsencrypt nach dem es fertig ist, eine Statusmeldung ausgibt?
Wünschenswert wäre eine Auflistung der Domains, bei denen es zum Fehler kam
evtl. noch eine Auflistung der Domains, die erfolgreich eingerichtet wurden

Wenn ich das richtig verstehe, startet letsencrypt lediglich den certbot mit den Daten aus der vadmin DB und richtet anschliesend die SSL Zertifikate in pd-admin ein.

Ich halte es für sehr aufwändig die binary so anzupassen, dass die certbot Ausgabe wie gewünscht "ge-parsed" wird. Zumal alle Infos/Fehler im Log und am Ende der Ausführung zu finden sind.

Man kann den Cronjob zur Erneuerung aber mit

/opt/pdadmin/bin/certbot-auto -q renew

ausführen. -q reduziert die Ausgabe und es werden nur Fehler ausgegeben. Wenn man dies auch für die letsencrypt binary haben möchte, müsste man wohl mit einem wrapper Skript für den certbot arbeiten.

Zitat

Original von Twilo
Das Skript kommt mit Domains, bei denen eine Weiterleitung eingerichtet ist, nicht zurecht.
www.example.com -> www.example.org
http://www.example.com/.well-known/acme-challenge/[…] wird http://www.example.org.well-known/acme-challenge/[…]
Wie kann der Fehler verhindert werden?

Der Fehler mit der Weiterleitung kommt vermutlich daher, dass in pd-admin bei der Weiterleitung am Ende der Slash / fehlt. Es muss in pd-admin bei der Weiterleitung

http://www.example.org/

stehen. Und nicht

http://www.example.org

Zitat

Original von Eisenherz
In der Datei gibst Du das ein. Die Datei sollte auch im Ordner /root liegen.

Einmal im Detail:

Als Rolf einloggen und

vi ~/.bashrc

Dort dann die beiden Zeilen

PATH=/sbin:$PATH
export PATH

einfügen.

Zitat

Original von Stefan3411
Die beiden Zeilen mit dem Path gebe ich nacheinander ein oder?

Ganau. Kann einfach per copy-paste eingefügt werden.

Und sind die Binaries auch ausführbar?

$ ls -ahl /sbin/ldconfig
$ ls -ahl /sbin/start-stop-daemon

Vielleicht einmal folgenden Eintrag in der .bashrc testen:

PATH=/sbin:$PATH
export PATH

Nach Änderung einmal neu einloggen und den certbot ausführen.

Was kommt denn bei

whereis ldconfig
whereis start-stop-daemon

raus? Wenn die binaries installiert sind fehlt der Pfad in der PATH Variable.

echo $PATH

Zitat

Original von webby
Meine Vermutung war/ist das letsencrypt hier die abzufragende Datei nicht anlegt (kann?) und es deshalb zur Meldung kommt... falls "timout" hier tatsächlich "timout" heisst, weil der Server an sich nicht antwortet, muss das Problem wohl an anderer stelle sein...

Wird eine Datei nicht gefunden, meldet der certbot dies auch mit einem 404 Fehler. Bei aktivem Verzeichnisschutz gäbe es zum Beispiel einen 401 Fehler. Da liefert der Dienst schon ziemlich präzises Feedback.

Wenn das Problem nur bei dieser Domain Auftritt und nur dort reproduzierbar ist, dürfte es jedenfalls kein allgemeines Problem sein. Vielleicht findet sich ja noch die Lösung u dem Problem.

Zitat

Original von Stefan3411
Danke Sumersgi, kannst du einem Laien auch erklären wie man das macht?

Wie Eisenherz bereits erklärt hatte, kann man die PATH Variable in der .bash_profile anpassen.

Ich würde jedoch die .bashrc nehmen. Die .bash_profile wird bei Verwendung einer Login Shell geladen. Also wenn man sich z.B. per SSH einloggt.
Die .bashrc dagegen wird bei "interactive non-login shell" geladen. Wird z.B. ein Prozess per Cronjob gestartet, haben wir so eine "interactive non-login shell". Hier greifen Änderungen in der .bash_profile nicht, da nur die .bashrc geladen wird. ist also bei der Ausführung von certbot und letsencrypt via Cron nicht ganz unwichtig

In der Regel lädt die .bash_profile auch die .bashrc, daher wirken sich Änderungen auch dort aus.

Anhand des Links von Twilo scheint es aber doch ein Problem mit fehlenden Paketen zu sein

Zitat

Original von webby
Ich bin eben zumindest schnell die vadmin DB durchgegangen und konnte keinen Punkt um da so zu beeinflussen... wäre natürlich nett wenn man definieren könnte, was im Dropdown für Versionen angezeigt werden kann...
vielleicht ist ja hier etwas dmit den pdadmin config files möglich?...

Die DB bin ich auch schon durch. Ebenso die pdadmin.conf. Gefunden hatte ich auch nichts. Vielleicht wäre dies also ein Feature Request

Laut der Ausgabe wurden Python + Libs auch installiert. Das Problem wird wohl hier liegen:

dpkg: Warnung: »ldconfig« wurde im PATH nicht gefunden oder ist nicht ausführbar 
dpkg: Warnung: »start-stop-daemon« wurde im PATH nicht gefunden oder ist nicht ausführbar 
dpkg: Fehler: 2 erwartete Programme nicht im PATH gefunden oder nicht ausführbar 
Beachten Sie: PATH von root sollte normalerweise /usr/local/sbin, /usr/sbin und /sbin enthalten 
E: Sub-process /usr/bin/dpkg returned an error code (2)

Die Programme sind vermutlich auch bereits installiert, werden nur in der PATH Variable nicht gefunden. Es müsste also die PATH Variable geprüft und ggf. diese in der .bashrc angepasst werden.

Zitat

Original von webby
Was übersehen wir? :*(

Zitat

Original von webby
Die Datei die von letsencrypt angelegt werden müsste ist halt nicht da.

Zitat

Original von webby

Code

[root@myserver ~]# cd /opt/pdadmin/bin/
[root@myserver bin]# ./certbot-auto certonly --webroot -w /opt/pdadmin/etc/ssl-validation/ --rsa-key-size 4096 -d myserver.domain.tld

Geht es hierbei um den Server Hostnamen oder um irgendeine Domain auf dem Server? Für den Server Hostnamen nutzt die letsencrypt binary nämlich /usr/local/pd-admin2/htdocs/ als Webroot.

Ich kann natürlich verstehen, dass man bei Problemen nicht gerne die echte Domain, sowie die Konfig der Domain / des Servers posten möchte - dies macht es für Dritte aber auch sehr schwierig alles genauer unter die Lupe zu nehmen. Daher kann man nur raten...

Die Fehlermeldung ist aber ein Timeout. In der Regel steht dies in Zusammenhang mit dem DNS. Daher würde ich hier noch einmal alles prüfen.

Mir ist keine Option bekannt. Im Changelog vom pd-admin sieht man auch immer wieder, dass PHP Versionen hinzugefügt oder entfernt werden. Ich gehe also davon aus, dass dies nicht einfach durch die Nutzer umgesetzt werden kann.

Zitat

Original von tbc233
Ich hatte glaube ich mal einen vergleichbaren Fehler weil die betroffene Domain einen ipv6 (AAAA) Eintrag hatte.
Letsencrypt versuchte daraufhin offenbar die Verifizierungsdatei über ipv6 abzuholen, was aus für dieses Thema nicht relevanten Gründen nicht funktioniert hat.

Kannst Du derlei Gründe ausschließen?

Dies kann man in den Log Files sehen. Einfach Mal nach greppen:

grep -B5 -RE "addressUsed" /var/log/letsencrypt

Zitat

Original von webby

Code

... .. .
IMPORTANT NOTES:
 - The following errors were reported by the server:


   Domain: www.meineseite.tld
   Type:   connection
   Detail: Fetching
   http://www.meineseite.tld/.well-known/acme-challenge/Os7CdQ0qfxr_JitIbyxsRPub0PWygaxtzq3fDDGFUDY:
   Timeout


   Domain: meineseite.tld
   Type:   connection
   Detail: Fetching
   http://meineseite.tld/.well-known/acme-challenge/taUwXVDw-1k4_3qzG0xeJgUsDlKfDifZpv0nzCOm3jw:
   Timeout
... .. .

Alles anzeigen

Also zunächst einmal wäre es gut, wenn für ein Problem ein neuer Thread geöffnet wird. Sonst werden Threads schnell unübersichtlich wenn sich Dinge vermischen. Zumal hier ein Problem vorliegt, der Thread aber eher um die Fragestellung bzgl. Einrichtung von SSL geht.

Die o.g. Ausgabe ist ja nur ein Teil bzw. die Zusammenfassung des Vorgangs. Der komplette Log Eintrag wäre hilfreicher.

Zitat

Original von webby
Jemand eine Idee? :*(

Da es zu einem Timeout kommt sollte geprüft werden, ob der A Record im DNS und die eingestellte IP in pd-admin (Endkunden > Übersicht > Domains > IP) soweit stimmen.

Wenn ja, dann unter /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/ manuell eine Datei anlegen und diese versuchen aufzurufen.

Zitat

Original von Stefan3411
Ich habe das Zertifikat, CA-Zertifikat und Apache/nginx Bundle

Also fehlt der private Schlüssel. Wie komme ich da ran?

Wie wurde denn das Zertifikat erstellt? Wenn der certbot bzw. /opt/pdadmin/bin/letsencrypt verwendet wurde, finden sich alle notwendigen Dateien unter /etc/letsencrypt/live/www.domain.name

Zitat

Original von Eisenherz
Wenn Du es per Let's Encrypt machst, dann

/opt/pdadmin/bin/letsencrypt www.deinewebseite.de

mehr nicht, außer das Let's Encrypt aktiviert sein muss.

Konkret heißt das mit dem Reselleraccount einloggen

1. In der Serverkonfiguration (Einstellungen -> Serverkonfiguration) letsencrypt einschalten
2. Im Angebot den Haken bei letsencrypt setzen

Das reicht auch schon. Es sollte ein Cronjob eingerichtet sein, der einmal täglich automatisch Zertifikate ausstellt. Manuell geht es wie oben genannt.

Zitat

Original von Twilo
Wenn ich nach der IP in der Log suche, scheint eine Verbindung danach zu stande gekommen zu sein.

Kann man sehen mit welchem Account sich dann angemeldet wurde? Unter Umständen ein falsch konfigurierter Mail-Client? Könnte mir vorstellen, dass es in Zusammenhang mit "Serveradresse != Zertifikats CN" steht. Ist aber nur eine Vermutung und müsste man Mal testen.

Zitat

Original von Eisenherz
Wenn auch Maildienste umgestellt werden sollen, dann würde ich den Server komplett sichern, da sonst alle Änderungen des Scripts manuell zurück gestellt werden müssen.

Eine Sicherung ist sicherlich vor jeder Änderung sinnvoll. Es sind aber überschaubare Änderungen, die relativ leicht zurück genommen werden können.

Zitat

Original von Eisenherz
Alles was Du brauchst hast Du aber auch in dem normalen täglichen Backup-Job.

Vorausgesetzt man hat in der pd-admin Konfig das Backup Verzeichnis konfiguriert

Ich bin mir nicht ganz sicher, ob dies überhaupt etwas mit dem Zertifikat zu tun hat. Zur Sicherheit am besten einmal prüfen und auch schauen, ob die Zertifikatskette stimmt:

https://de.ssl-tools.net/mailservers/

Ansonsten würde ich sagen:

dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>

Es wurde ein Loginversuch gestartet, aber es kein Auth stattfand (gab auch kein Nutzernamen)

TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42, session=<XXXXXXXXXXXXXXXX>

Der handshake schlug dann mit 'bad certificate' fehl. Was ich bisher recherchieren konnte, kommt dies von Seiten des Clients.

Ich würde mir dazu einmal die remote IP anschauen:

AbuseIPDB

Ich habe ähnliche Einträge in meinem maillog gefunden. Wenn ich mir die remote IPs dazu anschaue sind dies amerikanische oder chinesische IPs. Zu den IPs gab es entsprechende Abuse Einträge. Und ich kann auch definitiv ausschließen, dass von den IPs ein legitimer Zugriff stammen könnte.