Webserver Apache 2.4 mit SSL

    • New

    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.

    • New

    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

    • New

    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

    • New

    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.

    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

    • New

    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.
    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.

    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.

    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

    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ützte 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

    • New

    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

    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


    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.
    Wenn jemand weiß, wie man mit lynx ein selbstsigniertes Zertifikat speichert, kann das im Diskussionsthread gern posten.

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

    Zum Inhaltsverzeichnis

    • New

    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

    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

    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

    So. Das war es für dieses Szenario.

    Zum Inhaltsverzeichnis

    • New

    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

    Das erreicht man mit folgender Befehlsabfolge:

    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.hcpnet.lan
   It works - dualino (HTTP)

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

    Code
       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