Was ist ein Webserver?

Ein Webserver liefert Daten über das HTTP-Protokoll an Web-Browser. Diese Daten sind typischerweise HTML, CSS, JavaScript und Bild-Dateien.

Je nach gewähltem Webserver können gewisse Scriptsprachen bzw. dynamische Daten mit interpretiert und ausgegeben werden wie z.B.

  • PHP
  • JS
  • ASP
  • JSP

Hier hängt es aber von dem gewählten Webserver ab wie/ob/welche Scriptsprache standardmäßig interpretiert wird.

Typische Webserver Implementierung

  • Apache
  • NGINX
  • Cloudflare
  • Microsoft ISS
  • Node.js
  • Tomcat (Java)
  • lighthttpd

Aktuelle Aufteilung (11. Mai 2019) der meist verwendeten Webserver Implementierungen

Source: https://de.wikipedia.org/wiki/Webserver

Apache

Der Apache HTTP Server ist ein freier Webserver der im Jahr 1995 veröffentlicht wurde und ist aktuell der am meisten verwendete Webserver (Stand Mai 2019 – siehe „Was ist ein Webserver„).

Das installieren vom Apache Webserver ist bei jedem Betriebssystem etwas anders. An den folgenden Beispielen wird immer von Debian/Ubuntu ausgegangen.

sudo apt-get install apache2

Danach sollte folgender Befehl die aktuell installierte Apache2 Version ausgeben:

apache2 -v

Wie sonst bei allen anderen Software-Packages üblich befinden sich die Config-Dateien in /etc/apache2.

In diesem befinden sich folgende Dateien und Ordner

  • apache2.conf
    • Enthält die allgemeinen Apache2-Einstellungen.
  • conf-available
    • Enthält alle Config-Dateien die potentiell in den Server geladen werden sollen.
  • conf-enabled
    • Enthält symbolische Links zu allen Config-Dateien, die wirklich aktiviert werden sollen.
  • envvars
    • Datei, in der Apache2-Umgebungsvariablen gesetzt werden.
  • mods-available
    • gleich wie conf-available nur für Apache2-Module
  • mods-enabled
    • gleich wie conf-enabled nur für Apache2-Module
  • ports.conf
    • enthält Einstellungen auf welche Ports der Webserver Standardmäßig hören soll
  • sites-available
    • gleich wie conf-available nur für vHost-Configs
  • sites-enabled
    • gleich wie conf-available nur für vHost-Configs
  • magic
    • Regeln, um anhand der führenden Bytes einer Datei dem MIME-Typ zu erkennen.

Standard Apache vHost Config

Ordner: /etc/apache2/sites-available/<Dateiname>

<VirtualHost *:80>
    ServerName www.domain.com
    ServerAlias domain.com
    DocumentRoot /var/www/html/docroot
</VirtualHost>

Erklärung

  • VirtualHost *:80
    • Höre auf den Port 80
  • ServerName www.domain.com
    • Wende die unten angeführten Einstellungen an wenn der Hostname „www.domain.com“ ist
  • ServerAlias domain.com
    • Wende die unten angeführten Einstellungen an auch wenn der Hostname „domain.com“ ist
  • DocumentRoot /var/www/html/docroot
    • Zeige den Inhalt vom Ordner „/var/www/html/docroot“ an

Aktivieren einer neu erstellten vHost Config

ln -s /etc/apache2/sites-available/<Dateiname> /etc/apache2/sites-enabled/<Dateiname>

Testen der neu erstellten Apache vHost Config

apache2ctl configtest

Neustarten des Apache Webserver

apache2ctl restart

PHP-Handler hinzufügen

Bei Ubuntu/Debian basierenden Systemen funktioniert dies relativ einfach über ein Package welches – wie jede andere Software – über apt-get installiert wird.

sudo apt-get install -y php7.2-curl php7.2-gd php7.2-json php7.2-mbstring php7.2-mcrypt libapache2-mod-php7.2

Das wichtige hier ist das Package „libapache2-mod-php7.2“ was die Verbindung zwischen dem systemweit installierten PHP und dem Apache Webserver herstellt. Siehe mod_php für weitere Details.

Anstatt php7.2 kann php7.3 oder jegliche zukünftige PHP-Version angegeben werden die verwendet werden sollte.

Bei anderen Betriebssystemen kann dieser Prozess etwas anders ablaufen – hier bitte einfach Dr. Google fragen^^

Wenn alles funktioniert hat und der Webserver über apachectl restart neu gestartet wurde kann die Datei /var/www/html/info.php erstellt werden und mit folgendem Inhalt befüllt werden:

<?php phpinfo();

Danach kann über den Browser die Datei wie folgt aufgerufen werden:

http://<Server-IP>/info.php

Dies sollte nun die PHP-Info Seite der aktiv verwendeten PHP-Version anzeigen.

NGINX

NGINX ist ein freier Webserver der im Jahr 1999 von Igor Sysoev entwickelt wurde und ist aktuell die Nummer 2 der meist verwendetesten Webserver (Stand Mai 2019 – siehe „Was ist ein Webserver„).

Warum wurde noch ein Webserver entwickelt wenn es eh schon Apache gab?

NGINX ist primär aus dem sogenannten „C10k Problem“ entstanden.

Beim „C10k Problem“ geht es um die Optimierung der Handhabung von Network-Sockets um eine große Anzahl an Clients zu verabeiten.

C => Connection | 10k => 10.000

Hier hat NGINX mit seiner Event getriebenen, asynchronen Architektur die Basis für weitere zukünftigen „High-Performance“ Server-Software gelegt und wurde zum schnellsten verfügbaren Webserver.

Installation und Konfiguration

Das installieren vom NGINX Webserver ist bei jedem Betriebssystem etwas anders. An den folgenden Beispielen wird immer von Debian/Ubuntu ausgegangen.

sudo apt-get install nginx

Danach sollte folgender Befehl die aktuell installierte NGINX Version ausgeben:

nginx -v

Wie sonst bei allen anderen Software-Packages üblich befinden sich die Config-Dateien in /etc/nginx.

In diesem befinden sich folgende Dateien und Ordner

  • conf.d/
    • Hier können Konfigruationsdateien abgelegt werden
  • fastcgi.conf & fastcgi_params
    • Setzt Standardparameter für FastCGI Aufrufe.
  • mime.types
    • Mapping für Dateiendungen zu MIME-Types
  • modules-available/
    • Enthält Konfigurationsdateien von verfügbaren NGINX-Modulen
  • modules-enabled/
    • Enthält Symlinks zu den Konfigurationsdateien (in modules-available), welche aktiviert werden sollen
  • nginx.conf
    • Basis NGINX-Config File, welche für alle vHosts geladen wird
    • In dieser werden alle aktivierten Module, Konfigurationen und vHosts geladen
  • proxy_params
    • Hier sind ein paar standard Proxy-Parameter vorhanden.
  • scgi_params
    • Setzt standard SCGI-Parameter vorhanden
  • sites-available/
    • Beinhaltet Konfigurationen für die jeweiligen vHosts
  • sites-enabled/
    • Beinhaltet Symlinks zu den vHosts-Konfigurationsdateien (in sites-available), welche aktiviert werden sollen
  • snippets/
    • Beinhaltet Snippets für den Aufruf von PHP Dateien über FastCGI und für die Implementierung von selbst erstellten HTTPS Zertifikaten

Unwichtigere Dateien

  • uwsgi_params
  • koi-utf
    • Mapping für „KOI8-R“ (Kyrillisch) zu „UTF-8“ Characters
  • koi-win
    • Mapping für „KOI8-R“ (Kyrillisch) zu „Windows-1251“ Characters
  • win-utf
    • Mapping für „Windows-1251“ zu „UTF-8“ Characters

Neuen vHost erstellen

In /etc/nginx/sites-available befindet sich eine Datei „default“.

Diese baut sich wie folgt auf (unwichtige Kommentare (#) wurden entfernt)

server {
	listen 80 default_server; # IPv4 listen on Port 80
	listen [::]:80 default_server; # IPv6 listen on Port 80

	root /var/www/html; # Absolute path to Document-Root

	# Set default files to show when accessing the website
	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;

	server_name mydomain.at; # the domain name

	location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ =404;
	}

	# pass PHP scripts to FastCGI server
	#
	#location ~ \.php$ {
	#	include snippets/fastcgi-php.conf;
	#
	#	# With php-fpm (or other unix sockets):
	#	fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
	#	# With php-cgi (or other tcp sockets):
	#	fastcgi_pass 127.0.0.1:9000;
	#}

	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	#
	#location ~ /\.ht {
	#	deny all;
	#}
}

Wenn diese Konfiguration aktiviert werden soll muss ein „Symlink“ in den Ordner /etc/nginx/sites-enabled erstellt werden.

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Bzw. wenn eine schon aktivierte Config deaktiviert werden soll:

unlink /etc/nginx/sites-enabled/default

Bevor man aber nun den NGINX Service neu startet sollte man checken, ob die neue Configuration auch valide ist:

nginx -t

Nach einer Änderungen der Config im NGINX muss immer der Service neu gestartet bzw. neu geladen werden.

systemctl reload nginx

Source: https://www.nginx.com/resources/glossary/nginx/

Gratis HTTPS Zertifikate mit LetsEncrypt

HTTPS-Zertifikate sind notwendig um ein Schloss bzw. ein grünes Symbol links neben der URL im Browser zu erhalten.

Arten von Zertifikaten

  • Self-Signed Certificates
    • Jeder kann selbst Zertifikate erstellen und in seine Webseiten integrieren.
    • Jedoch werden diese NICHT automatisch von den aktuellen Browsern als „sicher“ anerkannt und erhalten deswegen KEIN grünes Schlosssymbol neben der URL.
    • Diese Zertifikate müssen pro Client erst als „sicher“ akzeptiert werden.
  • Wildcard Certificate
    • Wird oft für Subdomain Certificate verwendet damit nicht pro Subdomain ein extra Certificate erstellt und eingebunden ist.
    • Beispiel: *.pfiff.me
  • Domain Validation (DV)
    • Hier wird überprüft, ob der Antragssteller der Inhaber der spezifischen Domain ist. Es werden keine Informationen zur Unternehmensidentität überprüft und es werden keine anderen Informationen angezeigt.
    • Wildcard-Certificates sind möglich!
    • Dies ist das Standardverfahren für die Gratis LetsEncrypt Zertifikate.
  • Organization Validation (OV)
    • Gleich wie DV aber es wird auch eine Überprüfung des Organisations-Standorts und Namens durchgeführt. Diese Informationen sind dann auch im Zertifikat für den Endkunden ersichtlich. Dadurch wird für dem Endkunden besser dargestellt, wer hinter der Webseite steckt.
    • Wildcard-Certificates sind möglich!
  • Extended Validation (EV)
    • Gleich wie OV, nur wird detaillierter die Organisation überprüft.
    • Der Name der Organisation wurde früher neben dem grünen Schloss angezeigt. Jedoch wurde dieses Feature von den aktuellen Browser Herstellen wie Chrome, Firefox, Safari etc. inzwischen schon entfernt. Daher ist die Sinnhaftigkeit von einem EV-Certificate fragwürdig.
      Siehe https://www.troyhunt.com/extended-validation-certificates-are-dead/
    • Wildcard-Certificates sind NICHT möglich!

Was ist eine „Certificate Authority“ (CA)?

Eine „Certificate Authority“ (kurz CA) wird benötigt um erstellte Zertifikate mit gewissen vordefinierten Methoden zu überprüfen und bei erfolgreicher Prüfung diese signieren. Zusätzlich wird bei der Signierung ein Ablaufdatum gesetzt ab wann eine erneute Überprüfung durchgeführt werden muss.

„Früher“ gab es prinzipiell nur die Möglichkeit ein HTTPS-Zertifikate käuflich zu erhalten. Jedoch gibt es seit 2015 „LetsEncrypt“ bzw. die in Python geschriebene Software „Certbot“.

LetsEncrypt nimmt als Basis die „Domain-Vaildation“ (DV). Daher kann jeder, der Inhaber einer Domain ist und diese auf einen Server zeigen lässt, ein signiertes LetsEncrypt Zertifikat generieren lassen.

Was ist Certbot?

Certbot ist eine Software, die das automatische generieren und verwalten von HTTPS-Zertifikaten übernimmt.

Aktuell gibt es für die 2 am meisten verwendeten Webserver (Apache und NGINX) Plugins, die sogar das installieren der Zertifikate übernehmen.

Damit muss man nicht selbst in der jeweiligen Apache oder NGINX vHost Config die Zertifikat-Pfade händisch eingeben.

Am einfachsten folgt man den Anleitungen laut https://certbot.eff.org wie man Certbot für das aktuelle Betriebsystem und für den verwendeten Webserver installiert und verwendet.

Die Gültigkeit eines über Certbot bzw. LetsEncrypt generierten Zertifikats ist 90 Tage. Jedoch überprüft Certbot regelmäßig die Gültigkeit alles generierten Zertifikate und erneuert automatisch alle Zertifikate die nur mehr 1 Monat lang gültig sind.

Damit braucht man nur 1 mal ein Zertifikat für eine Webseite erstellen und installieren und es sollte in Zukunft keine Probleme geben mit dem Zertifikat.

Informationen von einem Zertifikat

Source: https://www.digitalocean.com/community/tutorials/a-comparison-of-let-s-encrypt-commercial-and-private-certificate-authorities-and-self-signed-ssl-certificates