Apache reagiert nicht auf Port 443

rj45

New Member
Ich habe auf ein frisches Debian 10 Image per "Perfect Server Automated ISPConfig 3 Installation" die Installation durchgeführt.
Nun reagiert der Apache nicht auf Anfragen auf Port 443.
Wie kann ich dieses Problem beheben?

Code:
AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.vhost:7
VirtualHost configuration:
*:8080                 isp.px01.xxxxx.de (/etc/apache2/sites-enabled/000-ispconfig.vhost:9)
*:80                   is a NameVirtualHost
         default server isp.px01.xxxxx.de (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost isp.px01.xxxxx.de (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost xxxxx.de (/etc/apache2/sites-enabled/100-xxxxx.de.vhost:7)
                 alias www.xxxxx.de
         port 80 namevhost xxxx2.de (/etc/apache2/sites-enabled/100-xxxx2.de.vhost:7)
                 alias www.xxxx2.de
         port 80 namevhost xxxx3.de (/etc/apache2/sites-enabled/100-xxxx3.de.vhost:7)
                 alias www.xxxx3.de
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex fcgid-proctbl: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex fcgid-pipe: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: ENABLE_USR_LIB_CGI_BIN
User: name="www-data" id=33
Group: name="www-data" id=33
 
warum sollte der Apache denn auf Port 443 lauschen?
Sind Webseiten mit einem SSL Cert eingerichtet?

Und eine Randfrage - wieso nimmt man ein altes Debian wenn man frisch installiert?
 

rj45

New Member
Hallo Hilfswicht.
Warum der Webserver auf Port 443 lauschen sollte? Um https anfragen auf diesem Port beantworten zu können.
Die Webseiten habe ich mal mit mal ohne den Haken "Let's Encrypt SSL" eingerichtet. Leider wurden keiner meiner https - Anfragen beantwortet (vielleicht weil der Apache nicht nach dem Port 443 lauscht).

Und auch die Randfrage möchte ich dir gern beantworten: Ich habe verschiedene Varianten von Debian und Ubuntu als Basis ausprobiert - jeweils mit der Autoinstallation. Mit mehr oder minder Erfolg oder nicht funktionierender Module. Die aktuelle Variante lief ohne Fehlermeldungen durch, das war es mir schon wert. Ja, es sind die ersten ernsthaften Versuche ein Linuxsystem zu betreiben.
 
dann würde ich mal die FAQ https://forum.howtoforge.de/threads/lets-encrypt-fehler-faq-checkliste.12976/ zu Rate ziehen, warum da etwas schief läuft.... :)

Also die Autoinstaller sind normal eigentlich nach meinem Wissen zuverlässig. Ausnahme bei LinuxContainer u.U.


Ich würde dennoch empfehlen als erstes eine saubere Installation mit einem aktuellen Betriebssystem zu bekommen. Wahrscheinlich lösen sich damit dann auch andere Fehler. Wenn der "Unterbau" nicht in Ordnung ist, kann auch weiteres meist nicht so zuverlässig funktionieren.
Und das EOL von Buster ist ja schon im August.....
 

Till

Administrator
Autoinstaller funtioniert einandfrei auf allen unterstützten OS (Debian 10 und 11 sowie Ubuntu 20.04, teste ihn alle paar tage. wenn er nicht läuft liegt das wie von Hilfswicht bereits erwähnt an unsauberem basis system oder aber an einer Virtualisierung wie lxc, die nicht alle notwendigen Funktionen für den vollständigen betrieb eines Hosting Servers bietet. man kann zwar auf LXC installieren, muss aber genau wissen was man da macht und was nicht geht.
 

volvo1979

New Member
Ich muss hier auch nochmal einhaken.
Neu installierte Debian 11 Server mit ACME der Server selbst bekam sofort ein SSL Zertifikat und ist 8080 ansprechbar alle Domains die ich danach anlege kann ich mit SSL erstellen -> 443 da danach schalte ich let encrypt an -> 443 weg....

Das Letsencrypt wird erfolgreich erstellt es fehlt "nur" am ssl vhost die Anleitung weiter oben hab ich auch angesehen und ich bin hier wohl nicht der einzige mit dem Problem :(

btw in /var/www/clients/client2/web2/ssl liegt auch noch das zuvor erstellte SSL Zert nur der 443 host ist durch den haken bei letsencrypt weg
 

Till

Administrator
Das Letsencrypt wird erfolgreich erstellt es fehlt "nur" am ssl vhost die Anleitung weiter oben hab ich auch angesehen und ich bin hier wohl nicht der einzige mit dem Problem :(

Nein, es wurde nicht erfolgreich erstellt. Du bringst hier websiten mit dem ISPConfig Installer durcheinander, das hat beides überhaupt nichts miteinander zu tun.

Zu Deinem problem, das LE cert der Webseite wird nicht erfolgreich erstellt, denn andernfalls hättest Du einen vhost auf port 443 und ein neues LE cert im ssl verzeichnis der website. Also einfach das FAQ durchgehen, jeden Schritt einen nach dem anderen und prüfen was dort steht, dann weißt Du warum Du LE nicht erfolgreich aktivieren kannst: https://forum.howtoforge.de/threads/lets-encrypt-fehler-faq-checkliste.12976/
 
Zuletzt bearbeitet:

Till

Administrator
Das Letsencrypt wird erfolgreich erstellt es fehlt "nur" am ssl vhost die Anleitung weiter oben hab ich auch angesehen und ich bin hier wohl nicht der einzige mit dem Problem :(

Es gibt in der Tat viele User die nicht wissen was Let's Encrypt ist und wie es funktioniert und welche Voraussetzungen sich daraus ergeben wenn man es nutzen möchte, das ist auch alles nicht einmal ISPConfig spezifisch. Aber da die Macher von Let's encrypt es scheinbar nicht ausreichend kommunizieren bzw. user sich nicht informieren was sie dort nutzen, haben wir dafür das Let's Encrypt Fehler FAQ erstellt, damit Du schritt für Schritt testen kannst und sehen, was Du falsch gemacht hast.
 

volvo1979

New Member
was mich so irritiert ist, dass letsencrypt das zertifikat ausstellt aber ich werde gern den punkt durchgehen was ist wenn es das nicht tut. Ach ja es ist aktiviert (im isp config sind die beide haken an)
1056


mir fehlt nur der 443 Eintrag
 

Till

Administrator
was mich so irritiert ist, dass letsencrypt das zertifikat ausstellt aber ich werde gern den punkt durchgehen was ist wenn es das nicht tut. Ach ja es ist aktiviert (im isp config sind die beide haken an)

Let's encrypt stellt das cert eben nicht aus. Lies nochmal Deinen Post durch, du schreibst dort selbst dass es nicht ausgestellt wird. ich zitiere Dich mal:

btw in /var/www/clients/client2/web2/ssl liegt auch noch das zuvor erstellte SSL Zert nur der 443 host ist durch den haken bei letsencrypt weg

Also FAQ durchgehen, und schon weiß Du wo dein fehler liegt. hat bislang bei jedem LE Fehler zum Erfolg geführt. Einfach machen.
 

volvo1979

New Member
Vielen Dank werde ich nochmal tun...
"[Di 24. Mai 16:56:21 CEST 2022] Your cert is in: /root/.acme.sh/pd-xxxxxxxx/pd-xxxxxx.de.cer
[Di 24. Mai 16:56:21 CEST 2022] Your cert key is in: /root/.acme.sh/pd-network.de/pd-xxxxxxx.de.key
[Di 24. Mai 16:56:21 CEST 2022] The intermediate CA cert is in: /root/.acme.sh/pd-xxxxxx.de/ca.cer"

Ich sehe das er es ausgestellt hat und gehe nun in den Debug modus über
 

Till

Administrator
Und das ist nicht der server Hostname und das cert welches der ISPConfig Installer erstellt hat? Denn mit acme.sh kannst du das cert nur einmal nutzen da acme.sh keine doppelten Ziele für ein cert kann, also nicht für eine website wenn es das cert des Hostnamens ist.
 

volvo1979

New Member
Das Zertifikat hat ispconfig erstellt nachdem ich den button "letsencrypt" für die 2te Domain aktiviert habe
ich habe also
Serverdomain mit ssl Port 8080
und eine weitere Domain siehe oben wo das Zertifikat vorhanden ist aber nicht unter /var/www/client... ssl und deswegen auch kein 443 da ist

/root/.acme.sh/
15:23 xxxxxx.yyyyyyyy-web.de <- Servercert -funzt
15:56 xxxxx-myyyylle.de <- erste Domain (haken da aber kein 443)
16:56 pd-xxxxxx.de <- zweite Domain (haken da aber ebenfalls kein 443)

Die erste Frage für mich wäre schon wie kommen diese Zertifikate nach /var/www/clien.../ssl/
und wenn das alles nicht klappt wieso ist der Haken dann da und nicht aus?
 
Zuletzt bearbeitet:

Till

Administrator
Bitte folge dem FAQ. Gehe jeden Punkt durch, wenn Du alle Punkte geprüft hast, dann aktiviere den debug mode, kommentier den server.sh cronjob aus, setze den haken bei lets encrypt, rufe server.sh auf der shell auf und poste die Ausgabe. Also das was der letzte punkt im faq ist.
 

Till

Administrator
Die erste Frage für mich wäre schon wie kommen diese Zertifikate nach /var/www/clien.../ssl/

Das macht acme.sh selbst.

15:56 xxxxx-myyyylle.de <- erste Domain (haken da aber kein 443)

schau ins apache oder nginx sites-available verzeichnis ob da eine .err datei ist für die seite. aber findest du auch alles raus wenn du dem letzten punkt vom faq folgst, also dem debug mode.

16:56 pd-xxxxxx.de <- zweite Domain (haken da aber ebenfalls kein 443)

Das findest Du auch über das faq raus, im zweifel durch den letzten pubkt debug mode.
 

volvo1979

New Member
Code:
24.05.2022-18:33 - DEBUG [letsencrypt.inc:431] - Let's Encrypt SSL Cert domains:
24.05.2022-18:33 - DEBUG [system.inc:1819] - exec: R=0 ; C=0 ; /root/.acme.sh/acme.sh --issue  -d xxx-modyyyle.de -d www.xxx-modyyyle.de -w /usr/local/ispconfig/interface/acme --always-force-new-domain-key --keylength 4096; R=$? ; if [[ $R -eq 0 || $R -eq 2 ]] ; then /root/.acme.sh/acme.sh --install-cert  -d xxx-moyyyle.de -d www.xxx-moyyyle.de --key-file '/var/www/clients/client2/web2/ssl/xxx-moyyyle.de-le.key' --fullchain-file '/var/www/clients/client2/web2/ssl/xxx-moyyyle.de-le.crt' --reloadcmd 'systemctl force-reload apache2.service' --log '/var/log/ispconfig/acme.log'; C=$? ; fi ; if [[ $C -eq 0 ]] ; then exit $R ; else exit $C  ; fi
sh: 1: [[: not found
sh: 1: 2: not found
sh: 1: [[: not found

So recht werde ich aus dem sh:[[ nicht schlau
 

Till

Administrator
Da hast Du eine falsche Shell als /bin/sh Ersatz. Ruf auf:

dpkg-reconfigure dash

und wähle im folgenden Dialog 'nein' aus.
 

Till

Administrator
In Debian, ja. das problem besteht halt darin dass sich dash, die weniger kann als bash, als /bin/sh ausgibt und somit viele shell scripte nicht mehr gehen. Der ISPConfig Autoinstaller ändert die Shell aber selbst zurück auf bash, daher wundert es mich dass Du die falsche shell hast. Aber wie Du nun siehst, einfach dem FAQ folgen bis zum Ende und das Problem ist gelöst.
 

Werbung

Top