Beiträge von Sumeragi

    Ich vermute, bei Aktivierung der Weiterleitung auf HTTPS wird dies nur für die Subdomain aktiviert. Nicht aber für die Domain ohne www. Müsste man Mal in der httpd.conf schauen.


    Ich habe immer bei meinen Domains folgenden Eintrag in der htaccess stehen:

    Apache Configuration
    RewriteEngine On
    RewriteCond %{SERVER_PORT} !^443$
    RewriteRule (.*) https://www.domain.de/$1 [L,R=301]

    Wenn dies bei Ihnen eingetragen wird, sollte auch domain.de weiterleiten.

    Wie lange läuft die Ausführung des Befehls? Der cronjob wird jede Minute ausgeführt. Vermutlich kommt es durch Mehrfachausführung zu den Fehlern.

    Es sollte der cronjob um flock erweitert und somit die Mehrfachausführung verhindert werden.

    Bitte nichts an den Symlinks unter /etc/letsencrypt/ ändern! Die werden so vom certbot erstellt/verwaltet.


    Da für den Hostnamen noch keine gesicherte Verbindung verfügbar ist vermute ich, dass die Symlinks zwischen /etc/letsencrypt/live/vpscobra.service4it.de und /opt/pdadmin/sslcerts nicht gesetzt sind (wie oben im Thread beschrieben). Können Sie bitte einmal folgende Ausgabe Posten:

    Bash
    ls -al /opt/pdadmin/sslcerts/vpscobra.service4it.de*

    Was passiert denn, wenn Sie den Befehl mit /opt/pdadmin/bin/certbot-auto ausführen?

    Damit war der komplette Befehl gemeint und nicht bloß der certbot alleine:

    Bash
    /opt/pdadmin/bin/certbot-auto certonly --webroot -w /usr/local/pd-admin2/htdocs -d vpscobra.service4it.com


    Zitat von Rudix

    Muss der RedirectMatch nun in der httpd.conf drinne sein oder auskommentiert sein?

    Lässt sich einfach feststellen. Einfach Mal in die httpd.conf rein schauen ;) Derzeit steht die Zeile ja schon im Template drin. Allerdings auch

    Code
    ## REDIRECT_TO_HTTPS ##

    Die Zeile wird bei Ausführung von httpd_vhosts.pl ersetzt. Und ich meine dies wurde gefixt und es wird der "richtige" Redirect gesetzt. Dies sieht man ebenfalls in der httpd.conf.

    Edit: Kurzum, der Redirect muss drin sein. Sonst gibt es Probleme bei der Verlängerung des Let's Encrypt für den Hostnamen.

    ... es wird doch dann mit certbot-auto-o die umbenannte originale Datei verwendet?
    ... geht bei mir mit beiden certbot-auto und certbot-auto-o nicht

    ... ein Aufruf von /opt/pdadmin/bin/certbot-auto-o certonly --webroot -w /opt/pdadmin/etc/ssl-validation/ -d vpscobra.service4it.com

    certbot-auto-o ist der eigentliche certbot. Die Datei certbot-auto ist einfach ein wrapper Skript, welches certbot-auto-o mit dem Argument -q gestartet. Daher funktioniert beides identisch.

    Habe es im anderen Threads gesehen:

    Der letzte Fehler liegt am genannten Rate Limit. Es sind 5 Fehlversuche pro Stunde erlaubt.


    Ich meine der Redirect wurde irgendwann Mal bereits gefixt. Sollte man in der httpd.conf sehen. Da es zu einem 404 Fehler kommt, kann das webroot falsch sein. Klappt es mit /usr/local/pd-admin2/htdocs als webroot ?

    Bei mir wurde bei erstmaliger Ausführung von /opt/pdadmin/bin/letsencrypt die certbot-auto Datei in certbot-auto-o umbenannt und /opt/pdadmin/bin/certbot-auto mit folgendem Inhalt angelegt:

    Code
    cat /opt/pdadmin/bin/certbot-auto
    #!/bin/bash
    exec /opt/pdadmin/bin/certbot-auto-o -q "$@"less /opt/pdadmin/bin/certbot-auto
    #!/bin/bash
    exec /opt/pdadmin/bin/certbot-auto-o -q "$@"

    Die Datei certbot-auto-o fehlt bei Ihnen.

    massive Probleme mit https den administrator-Zugang einzurichten, die SUB-Domains laufen nach einigen Nachinstallationen von dem ganzen Python-Paketen mit letsencrypt ! (aber erst nach langem Fehlersuchen!!!)

    Bei der erstmaligen Ausführung der certbot müssen python Pakete nachinstalliert werden. In Ihrem Beitrag schrieben Sie, dass Sie zunächst den Endkunde sudo-Berechtigungen geben mussten und dann Pakete manuell nachinstalliert haben. Dieses Verhalten ist mir neu und hatte ich bei Tests mit Debian und pd-admin noch nicht.


    Auch wenn es dadurch ein wenig Off-Topic wird... Wie sieht denn die Ausgabe von

    Code
     ls -al /opt/pdadmin/bin/certbot-auto*
    -rwxr-xr-x. 1 root root    57 27. Apr 2018  /opt/pdadmin/bin/certbot-auto
    -rwxr-xr-x. 1 root root 68689  9. Aug 15:59 /opt/pdadmin/bin/certbot-auto-o
    
    ls -al /opt/pdadmin/bin/letsencrypt
    -rwxr-xr-x. 1 root root 1518845 26. Jun 15:15 /opt/pdadmin/bin/letsencrypt

    aus?

    Ich nutze CentOS und habe Debian ein, zwei Mal zum Testen installiert. Hatte mit pd-admin keine Probleme bei den Tests. Mir ist daher etwas schleierhaft, wieso Endkunden in die sudoers Datei eingetragen werden müssen.


    Aber erst einmal zum Problem mit dem Zertifikat für den Hostnamen:

    ... so hier die Fehlermeldung von Firefox beim Aufruf über https://<SERVERNAME>/administrator


    /*schnipp*/

    vpscobra.service4it.com verwendet eine Sicherheitstechnologie namens "HTTP Strict Transport Security (HSTS)", durch welche Firefox nur über gesicherte Verbindungen mit der Website verbinden darf. Daher kann keine Ausnahme für die Website hinzugefügt werden.

    /*schnapp*/

    Prüft man vpscobra.service4it.com, sieht man dass das Zertifikat nicht zur URL passt:

    Offenbar ist http://www.service4it.com auf dem Server als Domain angelegt und hierfür ein Lets Encrypt Zertifikat eingerichtet. HSTS ist dann im Endkundenmenü über Subdomain konfigurierbar. Das Problem hier ist aber nicht HSTS, sondern ein falsches Zertifikat.


    Warum ist das so?


    Für den Hostnamen gibt es offenbar kein SSL-Zertifikat. Nun fragt man den Apache aber explizit auf Port 443 (Aufruf mittels https://...) nach einer gesicherten Verbindung. Da kein vhost mit Servernamen:443 gibt, wird der erste vhost in der Apache Konfiguration mit Port 443 verwendet. Dies ist in diesem Fall http://www.server4it.com . Kann man auch prüfen, in dem man die httpd.conf öffnet und nach ":443" sucht. Der erste Treffer ist dann http://www.service4it.com.

    Muss vielleicht ein letsencrypt-Zertifikat manuell angelegt werden?

    Ganz genau. Die Einrichtung für den Hostnamen muss manuell erfolgen. Über die Weboberfläche oder /opt/pdadmin/bin/letsencrypt geht dies nicht für den Hostnamen.


    1. Zertifikat ausstellen:

    Bash
    /opt/pdadmin/bin/certbot-auto-o certonly --webroot -w /opt/pdadmin/etc/ssl-validation/ -d vpscobra.service4it.com

    2. Symlinks erstellen:

    Bash
    ln -s /etc/letsencrypt/live/vpscobra.service4it.com/privkey.pem /opt/pdadmin/sslcerts/vpscobra.service4it.com-key
    ln -s /etc/letsencrypt/live/vpscobra.service4it.com/cert.pem /opt/pdadmin/sslcerts/vpscobra.service4it.com-cert
    ln -s /etc/letsencrypt/live/vpscobra.service4it.com/fullchain.pem /opt/pdadmin/sslcerts/vpscobra.service4it.com-cacert

    3. Apache Konfig neu schreiben:

    Code
    /opt/pdadmin/bin/httpd_vhosts.pl

    Das sollte es gewesen sein und die Weboberfläche sollte wieder erreichbar sein. Falls es zu Fehlern kommt, bräuchten wir hier die durchgeführten Schritte, sowie den vollständge Fehlermeldung, um bei Problemen helfen zu können.

    Wenn ich das richtig sehe wird der Installer per customer.cgi ausgeführt. Da ich den bisher sonst nirgends gefunden habe, würde ich vermuten, ist dieser Teil der customer.cgi - und diese kompiliert und kann nicht einfach bearbeitet werden.

    Zitat von tbc233

    Sieht verdächtig danach aus als würde der Installer hier die CLI Version prüfen. Hast Du diese schon hochgestellt?

    Wenn die CLI Version nicht angepasst wurde, ist diese 4.4.9 und nicht 5.6.X, da nämlich /usr/local/pd-admin2/bin/php genommen wird.

    Wenn es also keine Anpassungen der CLI gab, kann man dies hier als Fehler ausschließen.

    Zitat von eddy_belu

    [...] nur scheint es der APS-Installer nicht zu bemerken. Er erkennt nur die alte PHP-Version.

    Drupal wird per APS-Installer installiert. AFAIK wird der APS-Installer per PHP 5.6 ausgeführt. Daher wird wohl der Fehler kommen.