Webserver Apache 2.4 inkl. SSL

    Bitte nicht auf diesen Artikel antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    Inhalt:

    1. Vorbereitung
    1.1 System aktualisieren
    1.2 benötigte Software installieren
    2. Zertifikat erstellen
    3. Konfiguration des SSL im VirtualHost
    4. Vorschlag für eine mögliche Konfiguration der VirtualHosts
    4.1 Beispiel 1: default (HTTP und HTTPS)
    4.2 Beispiel 2: secundus (HTTPS erzwingen [redirect])
    4.3 Beispiel 3: dualino (HTTP und HTTPS mit unterschiedlichen Inhalten)
    4.4 Beispiel 4: chimaira (Inhalte abhängig vom Netzwerkdevice)
    5. Appendix
    5.1 Zeichensatz


    Offizielle Apache 2.4 Dokumentation https://httpd.apache.org/docs/2.4/en/

    (Edit 31.12.24)
    Von Einfach- auf Mehrfachbeitrag umgestellt, damit das Inhaltsverzeichnis klickbar ist und ewiges Scrollen auf akzeptables Scrollen begrenzt wird.

    (Edit)
    Die Anleitung ist unvollständig und bedarf an ein paar Stellen eine bessere Beschreibung. Wird aber wohl nicht mehr kommen. Aber das Prinzip sollte verständlich sein und man kann die Multiuser-Anleitung auch für Singleuser-Systeme verwenden. Dieser braucht keine Extragruppe erstellen, er nimmt einfach die Hauptgruppe, zu der er gehört.

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    1. Vorbereitung

    In dieser kleinen Anleitung behandele ich nur die Installation, grundlegende Konfiguration der Virtuellen Host und die Erstellung bzw. das Einbinden eines selbstsignierten Zertifikats, welches im Heimnetz ok ist, aber keinesfalls für die weite Welt taugt.

    Die Anleitung wurde getestet mit:
    (zepi3 ist der Rechnername des Testrechners)

    Code
    grep -i pretty /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
uname -a
Linux zepi3 6.6.62+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.62-1+rpt1 (2024-11-25) armv7l GNU/Linux
grep Model /proc/cpuinfo
Model           : Raspberry Pi Zero 2 W Rev 1.0

    1.1 System aktualisieren

    Wie immer, sollte das System zuallererst auf den aktuellen Stand gebracht werden:
    Ob upgrade oder full-upgrade (bei apt-get: dist-upgrade) muß jeder selbst entscheiden.

    sudo apt update && sudo apt full-upgrade

    1.2 benötigte Software installieren

    Wer kein PHP benötigt, läßt es einfach weg. Auf PHP gehe ich hier sowieso nicht ein.
    Den Textbrowser lynx verwende ich für Schnelltest. Dessen Installation ist nicht notwendig.

    sudo apt install apache2 php lynx

    Nach der Installation wird der Webserver gleich gestartet. Wer kein ss zur Verfügung hat, kann das veraltete netstat verwenden.

    OK, der Webserver läuft.
    Er ist auch von außen erreichbar (0.0.0.0:http) und mit http://zepi3/ (in meinem Fall: zepi3 und ein Slash am Ende - weil sonst der Browser die Suchmaschine befragt). Kommt natürlich auch darauf an, wie man die Namensauflösung (DNS) konfiguriert hat.

    Zum Inhaltsverzeichnis

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    2. Zertifikat erstellen

    Jetzt muß für den Zugriff über SSL das Zertifikat erstellt werden.

    Zuerst legt man ein Verzeichnis für die eigenen Zertifikate an. Sinnigerweise unter /etc/ssl/

    sudo mkdir -p /etc/ssl/localcerts

    Danach erstellt man das/die Zertifikate in diesem Verzeichnis:

    Code
    sudo openssl req -new -x509 \
				 -days 365 \
				 -noenc \
				 -out /etc/ssl/localcerts/apache.pem \
				 -keyout /etc/ssl/localcerts/apache.key

    Währenddessen kommen ein paar Abfragen:
    Die Fragen sollten entsprechend seinem Lan beantwortet werden.
    Im Grunde kann man reinschreiben was man will, aber bei Common Name muß die Angabe zu dem Rechner und dem VirtualHost passen.
    Ich setze hier mal fiktive Werte ein.

    Code
    Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Raspberry Land
Locality Name (eg, city) []:Raspi City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:RPi-Net
Organizational Unit Name (eg, section) []:privat
Common Name (e.g. server FQDN or YOUR name) []:*.meinlan.intern
Email Address []:root@localhost.de

    Das Zertifikat ist jetzt für 365 Tage gültig (-days 365).
    Da ich ein 'Sternchen'zertifikat vergeben habe, schließt das alle VirtualHosts/Subdomains ein. Wer das nicht will, muß dann für jeden VirtualHosts/Subdomain ein Zertifikat erstellen.


    Jetzt müssen die Zugriffsrechte auf die Zertifikate noch gesetzt werden.

    sudo chmod 600 /etc/ssl/localcerts/apache*

    Nur root sollte sie lesen (und natürlich auch schreiben) können.

    Code
    ls -lh /etc/ssl/localcerts/apache*
-rw------- 1 root root 1,7K 30. Dez 19:24 /etc/ssl/localcerts/apache.key
-rw------- 1 root root 1,5K 30. Dez 19:25 /etc/ssl/localcerts/apache.pem

    Und natürlich muß noch das SSL-Apache-Modul aktiviert werden:

    sudo a2enmod ssl

    Jetzt sollte man die Konfiguration des Apachen überprüfen:

    Code
    sudo apachectl configtest
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

    Das wirft natürlich eine Warnung. Der Apache wird mit den fehlenden Eintrag ausgeliefert. Schließlich sollte, nein muß man einen Server auf sein System zugeschnitten konfigurieren.

    Es fehlt nur der Eintrag ServerName, den man der apache2.conf noch hinzufügen muß. Dafür ermittelt man den Hostnamen (den man eigentlich weis)

    Code
    hostname
zepi3

    In meinem Fall ist das zepi3. Nun editiert man mit dem Editor seiner Wahl die Datei /etc/apache2/apache2.conf und schreibt ans Ende der Datei
    ServerName $HOSTNAME.localhost. In meinem Fall:

    ServerName zepi3.localhost

    (Groß-, Kleinschreibung beachten) und schließt die Zeile mit Eingabe der Taste <Enter> ab und speichert die Datei.
    Eine Überprüfung ergibt:

    Code
    $ sudo apachectl configtest
Syntax OK

    So, jetzt den Apachen neu starten:

    sudo systemctl restart apache2

    und Check:

    Code
    $ ss -tl | grep -i http
LISTEN 0      511          0.0.0.0:https      0.0.0.0:*
LISTEN 0      511          0.0.0.0:http       0.0.0.0:*

    HTTP und HTTPS ist vorhanden.
    Jetzt muß HTTPS natürlich noch konfiguriert werden.

    Zum Inhaltsverzeichnis

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    3. Konfiguration des SSL im VirtualHost

    Als erstes ein Blick auf die vorhandene /etc/apache2/sites-available/000-default.conf

    Code
    cd /etc/apache2/sites-available
grep -v '#'  000-default.conf
<VirtualHost *:80>
       ServerAdmin webmaster@localhost
       DocumentRoot /var/www/html

       ErrorLog ${APACHE_LOG_DIR}/error.log
       CustomLog ${APACHE_LOG_DIR}/access.log combined

    Hier schlampt grep, da er
    </VirtualHost>
    unterschlägt.
    Die Verursacher sind die Ersteller der 000-default.conf. Nach </VirtualHost> kommt kein Zeilenumbruch und die Datei ist zu Ende. Klassischer Fehler bei (Konfigurations)Dateien.

    Zur Sicherheit erstellt man eine Kopie des Originals:

    sudo cp 000-default.conf 000-default.conf.orig

    und jetzt wird die 000-default.conf angepasst. Dazu wird diese Datei editiert und sollte anschließend (ohne die Kommentare) so aussehen (Leerzeilen entfernt):

    Ein Configtest sollte mit OK quittiert werden:

    Code
    sudo apachectl configtest
Syntax OK

    Neu starten des Webservers:

    sudo systemctl restart apache2

    Da es sich um ein selbstsigniertes Zertifikat handelt, welches keine CA kennt, kommt natürlich 400 Bad Request, wenn man mit lynx -dump -head https://localhost/ überprüfen möchte. Für localhost wurde ja kein Zertifikat erstellt. Es muß über Rechnername.Domain.TLD (wie im Zertifikat angegeben) zugegriffen werden.

    lynx https://zepi3.meinlan.intern/

    lynx zeigt folgendes an:

    SSL-Fehler:The certificate is NOT trusted. The certificate issuer is unknown. - Fortfahren? (n)
    Was man mit j erlaubt und danach wird die Seite angezeigt.
    So wie oben der Apache konfiguriert wurde, ist es die selbe Seite wie bei HTTP.

    Wenn man mit dem Firefox die URL https://rechnername.meinlan.intern aufruft, kommt eine Warnmeldung, daß das Zertifikat nicht verifiziert ist. Da es unseres ist (man sollte sich das Zertifikat im Browser ruhig einmal anzeigen lassen) spricht man sein dauerhaftes Vertrauen für dieses Zertifikat in diesen Browser aus.

    Zum Inhaltsverzeichnis

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    4. Vorschlag für eine mögliche Konfiguration der VirtualHosts

    Wenn man mit VirtualHosts arbeiten will oder muß, sei zu beachten, das in den Konfigurationsdateien ServerName und evtl. ServerAlias definiert wird und der DN-Server einen CNAME-Eintrag erhält. Wenn das nicht beachtet wird, wird das in 000-default.conf konfigurierte, abgearbeitet (evtl. die zuerst eingelesene Konfig, z.B _bla.conf - das habe ich aber nicht getestet und werde es auch nicht).
    Wer Zugriff auf einen VirtualHost aus dem Internet bewerkstelligen will, braucht dafür einen dynamischen DNS und muß den Namen des, für den der dDNS die IP liefert, als ServerAlias mit in die Konfiguration schreiben. Die Portweiterleitung am Router sollte natürlich funktionieren.

    In den folgenden Beispielen lege ich alle Verzeichnisse und Dateien der VirtualHosts nach /home/webserver /home/websites.
    Der Hintergrund für diese Entscheidung ist, das /home eine eigene Partition ist, die mittels /etc/fstab als home unter / eingehängt wird. Das hat den Vorteil, wenn ich ein neues OS aufspiele, brauche ich nur die alte Apache-Konfiguration in die Neue zu übertragen. Und das Backup der Daten ist leichter vom OS zu trennen. Aber das darf man auch anders sehen.
    Ich muß es nur erwähnen, um die folgenden Beispiele nachvollziehbar zu halten. (Edit 17.02.25 falsche Besitzerangabe korrigiert)

    Das Verzeichnis /home/websites muß als root (mit sudo) angelegt werden und danach können die Eigentümer geändert werden:

    Code
    sudo mkdir /home/websites
ls -ld /home/websites/
drwxr-xr-x 3 root root 4096  2. Jan 16:25 /home/websites/

    Wichtig ist, das nur root Schreibrechte hat und Other lesend in das Verzeichnis wechseln können.
    Unter diesem Verzeichnis werden die Verzeichnisse für die VirtualHosts angelegt.

    Ab jetzt muß man bei der Rechtevergabe etwas aufpassen.
    Folgende Anforderungen sollen erfüllt werden:
    * Niemand außer den berechtigten Users dürfen auf das Verzeichnis des VirtualHost zugreifen dürfen.
    Das bedeutet, der Webserver [ (uid=33(www-data) gid=33(www-data) ] und evtl. mehrere User benötigen Zugriff.
    Daraus folgt, Eigentümer des VirtualHost-Verzeichnisses wird www-data, es wird eine Gruppe erstellt, in die die berechtigten User aufgenommen werden und Other bekommt keinerlei Berechtigung.

    [Edit: 18.02.25]
    Unterhalb der DocumentRoot sollte www-data nur da Schreibrechte erhalten, wo das für die Erlangung der Aufgabe zwingend erforderlich ist. Der Grund ist leicht verständlich: Wenn durch ein fehlerhaftes Skript oder URL-Manipulationen ein Angreifer sich die Rechte von www-data erschleicht, kann er natürlich nur dort etwas verändern, wo www-data schreibend Zugreifen kann. Ganz bös, wenn davon die .htacces betroffen ist. Er könnte dann die durch den Options zugestandenen Einstellungveränderungen den VHost in seinem Verhalten verändern.

    Im Prinzip sollten die Berechtigungen so aussehen:

    Code
    DocumentRoot                    drwxrwx--- www-data  www-gruppe
└── htdocs                      drwxrwxr-x CHEF-USER www-gruppe
   └── index.html              -rw-rw-r-x USER      www-gruppe
└── sensibles                   drwxr----- CHEF-USER www-data

    DocumentRoot: Besitzer www-data und als Gruppe eine extra angelegte Gruppe, in der die User aufgenommen werden, die da rein dürfen. Other haben keinerlei Rechte. Damit wird auf Filesystemebene sichergestellt, das niemand außer den erlaubten Zugriff erhält.

    htdocs: der VHost-Verantworliche sollte hier der Besitzer sein. Jedenfalls nicht www-data (aus den oben angeführten Gründen). Gruppe natürlich die für diesen VHost angelegte Gruppe und Other muß r-x haben, damit der Webserver in das Verzeichnis kommt.

    index.html: steht symbolisch für alle Dateien, die über den Webserver erreichbar sind. Sie sollten rw-rw-r-- für Dateien und für Verzeichnisse rwxrwxr-x sein. Bei Verzeichnissen wo es erforderlich ist, das www-data Schreibrechte haben muß, sieht das natürlich anders aus. Darauf gehe ich vielleicht in einem späteren Teil darauf ein.

    sensibles: Nehmen wir mal an, da liegen die Zugangsdaten für die Datenbank und die sollen nicht alle Mitglieder der Gruppe sehen, da bekommt der, der die zu kennen hat, das Besitzrecht und die Gruppe www-data leserecht (der muß die schließlich lesen können) und other bekommt keinerlei Rechte.
    [/Edit: 18.02.25]

    Ein Beispiel zum Verständnis. Es soll für den VirtualHost 815-demoweb.conf das Verzeichnis demoweb angelegt werden. Und alle Mitglieder der Gruppe www-demo, welche vorher angelegt wird, erhalten Schreibberechtigung.

    Code
    sudo groupadd www-demo
sudo mkdir /home/websites/demoweb
sudo chown www-data:www-demo /home/websites/demoweb
# berechtigte User zur Gruppe www-demo hinzufügen.
sudo adduser USER-A www-demo
sudo adduser USER-C www-demo

    Hinweis: Wenn man Besitzrechte/Berechtigungen geändert hat, kann es vorkommen, das man doch keinen Zugriff erhält (z.B. nach chown :GRUPPE ZIEL und adduser USER GRUPPE), einfach ausloggen und neu einloggen, damit die Berechtigungen in der Shell neu eingelesen werden.

    In diesem Verzeichnis wird noch ein Unterverzeichnis benötigt, in dem die HTML/PHP/...-Dateien liegen. Ich verwende traditionell htdocs (HyperTextDOCumentS). Diesem vergebe ich die selben Besitzrechte wie das höhere Verzeichnis.

    Code
    sudo mkdir /home/websites/demoweb/htdocs
sudo chown www-data:www-demo /home/websites/demoweb/htdocs

    Edit 17.02.25 /home/websites/demoweb/htdocs sollte besser nicht www-data gehören, eher dem Hauptverantwortlichen des VirtualHosts. Somit wird dem Webserver das Recht genommen, htdocs zu löschen oder umzubenennen. Wenn jemand durch einen Bug in seinen PHP-Skripten oder vergleichbares anderen Webserverrechte zugestehen muß, darf dieser zumindest nicht dieses Verzeichnis einfach löschen.

    Unter /home/websites/demoweb/ lege ich bei Bedarf noch weitere Verzeichnisse, in den ich z.B. die Zugangsdaten für die Datenbank ablege oder die Zugangsdaten geschützter Bereiche. Da kann man mit den Eigentümerrechten an den Verzeichnissen, welcher der Zugriffsberechtigten welche Passwörter etc. sehen darf. Wichtig dabei ist, das der Webserver die lesen können muß. Dazu auch ein kleines Beispiel. Auf die Zugangsdaten für die SQL-DB soll nur USER-A Zugriff haben, aber USER-C (der auch in der Gruppe www-demo ist) nicht.

    Code
    sudo mkdir /home/websites/demoweb/env
sudo chown USER-A:www-data /home/websites/demoweb/env
sudo chmod 750 /home/websites/demoweb/env

    Damit darf nur USER-A als Besitzer (rwx) und Mitglieder der Gruppe www-data (r-x) zugreifen. Alle anderen sind nicht berechtigt.

    Noch einen Hinweis zum Erstellen von Dateien. Wenn mehrere Benutzer (gleiche Gruppe) die Datei bearbeiten können sollen, vorher in der Shell umask 0002 eingeben und die Dateien werden mit -rw-rw-r-- erstellt. Die Änderung gilt nur in dieser Shell und geht bei logout wieder verloren. Und natürlich die neu erstellte Datei/Verzeichnis der richtigen Gruppe zuweisen (es wird ja immer die eigene Hauptgruppe vergeben): chown :GRUPPENNAME ZIEL. Nach obigen Beispiel: chown :www-demo index.html.

    Wie man das in GUI-Dateimanagern macht, darf jeder selbst herausfinden.


    So, lange, aber notwendige Vorrede.

    1. Beispiel 1: default
      Der 000-default wird nach /home/websites/default gelegt, mit HTTP und HTTPS
    2. Beispiel 2: secundus
      Der 002-secundus erhält /home/websites/secundus als Wurzel und erzwingt HTTPS
    3. Beispiel 3: dualino
      Der 030-dualino erhält /home/websites/intern als Wurzel, und liefert über HTTP einen anderen Inhalt, als über HTTPS aus.

    Zum Inhaltsverzeichnis

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    4.1 Beispiel 1: default

    Zuerst muß eine Verzeichnisstruktur angelegt und die Besitzer- und Zugriffsrechte vergeben werden (bei chown, groupadd und adduser brauchts root-Rechte).

    Code
    sudo groupadd www-default
sudo mkdir -p /home/websites/default/htdocs
sudo chown -R www-data:www-default /home/websites/default
sudo chmod -R 770 /home/websites/default
sudo adduser bwichtel www-default

    Edit 17.02.25 /home/websites/default/htdocs sollte besser nicht www-data gehören, eher dem Hauptverantwortlichen des VirtualHosts. Somit wird dem Webserver das Recht genommen, htdocs zu löschen oder umzubenennen. Wenn jemand durch einen Bug in seinen PHP-Skripten oder vergleichbares anderen Webserverrechte zugestehen muß, darf dieser zumindest nicht dieses Verzeichnis einfach löschen.

    Jetzt noch eine index.html zur Kontrolle ins Verzeichnis htdocs legen:
    (Falls das verweigert wird, ausloggen und wieder einloggen.)

    Code
    # bei mehreren Bearbeitern die kommentierten Befehle auskommentieren
# umask 0002
echo 'It works - default' > /home/websites/default/htdocs
# chown :www-default

    Das sollte dann so aussehen (umask 0002 und chown :www-default) :

    Code
    default                   drwxrwx--- www-data www-default
└── htdocs                drwxrwx--- www-data www-default
    └── index.html        -rw-rw-r-- bwichtel www-default

    Edit 17.02.25 Wenn der Besitzer von htdocs wie weiter oben empfohlen, nicht www-data ist, müssen die Zugriffsrechte für others mit r-x versehen werden, damit www-data Zugriff behält. Also:
    └── htdocs                drwxrwxr-x CHEF-USER www-default

    Jetzt ist die Apachekonfiguration für 000-default.conf dran.
    Die conf für den VirtualHost teile ich der Übersicht wegen in zwei oder drei Teile.
    Da ich die Vorgabe gab, 000-default soll gleiche Inhalte auf HTTP und HTTPS ausliefern, teile ich in zwei Teile.

    In der 000-default.conf schreibe ich nur das Netzwerkdevice, auf denen der Apache reagieren soll (hier * für alle -> localhost, lan, wlan, ...), die Ports (80 für http und 443 für https) und für den Port 443 den Start der SSLEngine und die zugehörigen Zertifikate. Da ich ein Sternchen-Zertifikat erstellt habe, kann ich für alle das selbe Zertifikat verwenden. Wer das nicht will, muß für jeden VirtualHost sein eigenes Zertifikat erstellen und dieses hier einbinden.

    Immer dran denken, vor Änderungen an einer Datei eine Kopie anlegen (sudo cp ...). Sicher ist sicher.

    In beiden VirtualHost includiere ich die selbe Datei, da der Webserver auf beiden Ports das selbe ausgeben soll.
    In der Include-Datei, die natürlich kein <VirtualHost ...> bzw. </VirtualHost> erhalten darf, sind Servername und DocumentRoot zwingend erforderlich. Beim 000-default-ServerName gibt man den Hostnamen mit Domainnamen und Tld an. Zur Erinnerung, mein Testrechner nennt sich zepi3, Domain ist meineDomain und die Tld ist meineTld. Dann gibt man noch eine Adresse für den Kontakt an.

    Mit dem Directory-Eintrag erlaubt man noch den Zugriff des Apachen auf die DocumentRoot. Wenn man das nicht macht, gibt es ein 403 Forbidden.

    Unter Umständen, falls der Zugriff über http://zepi3/ nicht funktioniert, könnte ein
       ServerAlias zepi3
    unterhalb des Servernamens Abhilfe schaffen. Ich brauche das bei mir nicht.

    Die default-Seite ist ja schon enabled, also brauchen wir das nicht mehr zu tun.
    Jetzt sollte man die Konfiguration testen. Tippfehler sind schnell basiert.

    Code
    apache2ctl configtest
Syntax OK

    Gut. Dann den Apachen neu starten und mit lynx testen.

    Durch das SSL kann ich mit lynx nicht mit -dump und oder -head testen. Ich muß ihn so aufrufen und ein paar Fragen beantworten und dann sehe ich die Webseite.

    (Edit 17.02.25: curl)
    Oder man verwendet curl mit der --insecure-Option (curl --insecure oder curl -k)

    Code
    curl -k https://zepi3/
   It works - default

    Wer will kann die alte Datei /var/www/html/index.html nach den neuen Ort /home/websites/default/htdocs/ kopieren.

    Zum Inhaltsverzeichnis

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    4.2 Beispiel 2: secundus

    In diesem Beispiel wird eine Subdomain zu zepi3.meineDomain.meineTld erstellt.

    Folgende Eigenschaften soll sie aufweisen:
    - nur über HTTPS erreichbar
    - HTTP-Anfragen werden auf HTTPS umgeltet
    - es soll die Möglichkeit bestehen, das mehrere User an der Seite auf Dateiebene arbeiten dürfen

    Folgende Struktur wird benötigt:

    Code
    secundus                  drwxrwx--- www-data www-secundus
└── htdocs                drwxrwx--- www-data www-secundus
    └── index.html        -rw-rw-r-- bwichtel www-secundus

    Edit 17.02.25 Wenn der Besitzer von htdocs wie weiter unten empfohlen, nicht www-data ist, müssen die Zugriffsrechte für others mit r-x versehen werden, damit www-data Zugriff behält. Also:
    └── htdocs                drwxrwxr-x CHEF-USER www-secundus

    Das erreicht man mit folgender Befehlsabfolge:

    Code
    sudo groupadd www-secundus
sudo adduser bwichtel www-secundus
sudo mkdir -p /home/websites/secundus/htdocs
sudo chown -R www-data:www-secundus /home/websites/secundus
sudo chmod -R 770 /home/websites/secundus
# hier evtl. ausloggen und wieder einloggen (wegen neuen Zugriffsrechten)
umask 0002
echo 'It works - secundus' > /home/websites/secundus/htdocs/index.html
chown :www-secundus /home/websites/secundus/htdocs/index.html

    Edit 17.02.25 /home/websites/secundus/htdocs sollte besser nicht www-data gehören, eher dem Hauptverantwortlichen des VirtualHosts. Somit wird dem Webserver das Recht genommen, htdocs zu löschen oder umzubenennen. Wenn jemand durch einen Bug in seinen PHP-Skripten oder vergleichbares Anderen Webserverrechte zugestehen muß, darf dieser zumindest nicht dieses Verzeichnis einfach löschen können.

    Jetzt muß der Webserver konfiguriert werden.
    Unter /etc/apache2/sites-available/ werden zwei Dateien angelegt:
    002-secundus.conf
    002-secundus_https.inc

    Den VirtualHost aktivieren

    sudo a2ensite 002-secundus

    und die Konfiguration testen:

    Code
    sudo apache2ctl configtest
Syntax OK

    Bei OK den Apache neu starten (oder reload um die Konfiguration neu einzulesen.):

    sudo systemctl restart apache2


    Ab jetzt sollte man die Log-Dateien unter /var/log/apache2/ im Auge behalten. Dazu verwende ich den Befehl ls mit der Anweisung nach Zeit (-t neueste zuerst) und mit Datum/Uhrzeit anzuzeigen. Weil da mit der Zeit sich einige Dateien ansammeln, begrenze ich die Ausgabe auf die ersten 5 Zeilen:

    Code
    ls -lht /var/log/apache2 | head -n 5
insgesamt 40K
-rw-r----- 1 root adm  2,3K  4. Jan 10:53 error.log
-rw-r----- 1 root adm  1,9K  4. Jan 10:53 default_error.log
-rw-r----- 1 root adm  1,7K  4. Jan 10:41 default_access.log
-rw-r----- 1 root adm   396  4. Jan 00:00 error.log.1

    Nach den Neustart/Reload des Apachen erscheinen dann noch die Logdateien von secundus (secundus_error.log und secundus_access.log)

    Jetzt ist secundus.meineDomain.meineTld konfiguriert - ABER man kann nicht drauf zugreifen, weil secundus.zepi3 nicht bekannt ist.
    Um den Zugriff zu ermöglichen, bedarf es mehr: DNS

    In der Zonen-Datei meineDomain.meineTld von meinem DNS ist mein zepi3 bereits eingetragen:
    zepi3           IN A 192.168.X.Y
    Jetzt bedarf es noch einen CNAME-Eintrag für secundus:

    Code
    ; auf zepi3
secundus.zepi3       IN CNAME zepi3

    Den DNS die Konfiguration neu einlesen lassen und testen (hier mal ohne den Befehl host):

    Code
    getent hosts secundus.zepi3
192.168.X.Y   zepi3.meineDomain.meineTld secundus.zepi3.meineDomain.meineTld

    Na dann, los gehts:

    HTTP
    lynx -dump -head http://secundus.zepi3.meineDomain.meineTld
HTTP/1.1 301 Moved Permanently
Date: Sat, 04 Jan 2025 13:02:29 GMT
Server: Apache/2.4.62 (Raspbian)
Location: https://secundus.zepi3.meineDomain.meineTld/
Connection: close
Content-Type: text/html; charset=iso-8859-1

    Sehr schön. Die Umleitung wird angezeigt und der Browser kann darauf regieren.
    Aber der Content-Type mißfällt mir. Ich schreibe alles mit UTF-8, ergo sollte der Webserver das auch anzeigen.

    sudo $EDITOR /etc/apache2/conf-available/charset.conf
    die Zeile auskommentieren oder folgende Zeile einfügen:
    AddDefaultCharset UTF-8
    speichern, reload des Apachen.
    Mmh. Bei der Weiterleitung zeigt er weiter charset=iso-8859-1; aber ansonsten liefert er mit UTF-8 aus.

    Code
    lynx -dump -head http://secundus.zepi3.meineDomain.meineTld | grep -i 'content-type'
Content-Type: text/html; charset=iso-8859-1
lynx -dump -head http://zepi3.meineDomain.meineTld | grep -i 'content-type'
Content-Type: text/html; charset=UTF-8

    Naja, erstmal unwichtig.

    Jetzt mit die Subdomain direkt mit HTTPS aufrufen:

    Code
    lynx https://secundus.zepi3.meineDomain.meineTld/
(Zweimal j drücken und lynx zeigt:)
  It works - secundus
# Edit 17.02.25 ... oder besser 
curl -k https://secundus.zepi3.meineDomain.meineTld/
  It works - secundus

    So. Das war es für dieses Szenario.

    Zum Inhaltsverzeichnis

    Bitte nicht auf diesen Beitrag antworten. Für Fragen, Anmerkungen, etc. folgenden Thread benutzen:
    Diskussion zu Webserver Apache 2.4 mit SSL

    4.3 Beispiel 3: dualino

    In diesem Beispiel wird eine Subdomain dualino.zepi3.meineDomain.meineTld erstellt.
    Folgende Eigenschaften soll sie aufweisen:
    - über HTTP und HTTPS erreichbar
    - unterschiedliche Inhalte bei HTTP und HTTPS
    - es soll die Möglichkeit bestehen, das mehrere User an der Seite auf Dateiebene arbeiten dürfen

    folgende Struktur wird benötigt:

    Code
    dualino                  drwxrwx--- www-data www-dualino
└── htdocs               drwxrwx--- www-data www-dualino
    └── index.html       -rw-rw-r-- bwichtel www-dualino
└── shtdocs              drwxrwx--- www-data www-dualino
    └── index.html       -rw-rw-r-- bwichtel www-dualino

    Edit 17.02.25 Wenn der Besitzer von htdocs wie weiter oben empfohlen, nicht www-data ist, müssen die Zugriffsrechte für others mit r-x versehen werden, damit www-data Zugriff behält. Also:
    └── htdocs               drwxrwxr-x CHEF-USER www-dualino
    └── shtdocs              drwxrwxr-x CHEF-USER www-dualino

    Das erreicht man mit folgender Befehlsabfolge:

    Edit 17.02.25 /home/websites/dualino/htdocs sollte besser nicht www-data gehören, eher dem Hauptverantwortlichen des VirtualHosts. Somit wird dem Webserver das Recht genommen, htdocs zu löschen oder umzubenennen. Wenn jemand durch einen Bug in seinen PHP-Skripten oder vergleichbares Anderen Webserverrechte zugestehen muß, darf dieser zumindest nicht dieses Verzeichnis einfach löschen können.

    Jetzt muß der Webserver konfiguriert werden.
    Unter /etc/apache2/sites-available/ werden drei Dateien angelegt:
    030-dualino.conf
    030-dualino_http.inc
    030-dualino_https.inc

    Den VirtualHost aktivieren:

    sudo a2ensite 030-dualino

    und die Konfiguration testen:

    Code
    sudo apache2ctl configtest
Syntax OK

    und jetzt noch die neue Konfiguration einlesen:

    sudo systemctl reload apache2

    Jetzt ist dualino.meineDomain.meineTld konfiguriert - ABER man kann nicht drauf zugreifen, weil dualino.zepi3 nicht vom DNS aufgelöst wird.
    Um den Zugriff zu ermöglichen, muß noch ein Eintrag im DN-Server gemacht werden.

    In der Zonen-Datei meineDomain.meineTld von meinem DNS ist mein zepi3 bereits eingetragen:
    zepi3           IN A 192.168.X.Y
    Jetzt bedarf es noch einen CNAME-Eintrag für dualino

    Code
    ; auf zepi3
secundus.zepi3       IN CNAME zepi3
dualino.zepi3        IN CNAME zepi3

    (secundus stammt aus Beispiel 2)

    Den DNS die Konfiguration neu einlesen lassen und testen (hier mal ohne den Befehl host):

    Code
    getent hosts dualino.zepi3
192.168.X.Y   zepi3.meineDomain.meineTld dualino.zepi3.meineDomain.meineTld

    Jetzt noch die Tests, ob alles so funktioniert, wie gewollt.

    Code
    lynx -dump http://dualino.zepi3.meineDomain.meineTld
   It works - dualino (HTTP)

    Wegen dem Zertifikat (und meiner unzureichenden Kenntnis von lynx) muß ich ohne -dump den lynx benutzen.
    lynx https://dualino.zepi3.meineDomain.meineTld
    Nach zwei Fragen zeigt dieser:

    Code
       It works - dualino (HTTPS)

    Edit 17.02.25 Oder besser mit

    Code
    lynx -dump http://dualino.zepi3.meineDomain.meineTld
   It works - dualino (HTTPS)

    Fein. Funktioniert wie gewollt.

    Zum Inhaltsverzeichnis

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login