eine sichere Seite

Glückicherweise stellen moderne Browser große Warnschilder auf, wenn man eine Webseite über HTTP oder mit ungültigem Zertifikat besucht. Jedoch macht es den Aufruf von selbst gehosteten Webseiten im eigenen Heimnetzwerk etwas schwerer. Technisch unversierte Familienmitglieder oder Freunde, die regelmäßig auf diese Dienste zugreifen, werden dadurch die schlechte Angewohnheit entwickeln einfach Sicherheitswarnungen zu ignorieren.

Für mein geplantes Zertifikatsmanagement will ich natürlich minimalen Management-Aufwand, aber trotzdem die Sicherheit des Netzwerks zu jeder Zeit gewährleisten.

keine selbst-signierten Zertifikate

Selbst-signierte werden standardmäßig nicht von Browsern vertraut. Damit die Zertifikatsvalidiierung funktioniert, müsste also jeder Browser auf jedem Endgerät meine Zertifizierungsstelle installiert haben. Diese Arbeit ist ohne exzessiv invase Kontrolle über alle Geräte im Netzwerk absolut unvorstellbar. Außerdem sollte jeder skeptisch reagieren, wenn jemand eine Zertifizierungsstelle installieren will, damit Sicherheitswarnungen verschwinden.

keine Wildcard-Domänen

Zertifikate sollen die Identität des Servers gegenüber dem Client gewährleisten. Da Wildcard-Domänen auf alles übereinstimmen, bekommt der Client zwar keine Warnungen, aber er weiß nur, dass der Server sich in der richtigen Domäne befindet. Ob der Server der Host ist zu dem sich der Client verbinden will, kann nicht mehr validiiert werden.

Dieses Problem verschlimmert sich zudem, wenn der mehrere Server das gleiche Zertifikat benutzen wollen. Das herumkopieren des privaten Schlüssels ist eines der sicherheitskritischen Operationen, die es gibt.

Automatische Erneuerung

Certbot

kein Portforwarding über die Firewall

Der interne Webserver soll zu keiner Zeit aus dem Internet erreichbar sein.

Split-Host HTTP-Challenge

Vorraussetzungen

Die Kosten für dieses Setup belaufen sich auf minimal 5€ pro Monat. Jenachdem wie teuer die gewählten Optionen sind:

  • öffentlich eingetragene Domäne
  • VPS
  • Webserver (ich werde für das Beispiel nginx benutzen)

Konfiguration des internen Webserver

apt install certbot
certbot register --email admin@$(hostname --domain) --agree-tos --no-eff-email
certbot show_account
certbot certonly --manual --domain "$(hostname --fqdn)" \
    --preferred-challenges http-01 --key-type ecdsa --debug-challenges
ssh-keygen -t ed25519
#!/bin/bash
certbot renew --cert-name "$(hostname --fqdn)" \
        --manual-auth-hook /usr/local/bin/cert-auth \
        --manual-cleanup-hook /usr/local/bin/cert-auth-cleanup
#!/bin/bash
# Die Variablen CERTBOT_VALIDATION und CERTBOT_TOKEN kommen von certbot
ssh $(hostname --domain) \
        "echo $CERTBOT_VALIDATION >.well-known/acme-challenge/$CERTBOT_TOKEN"
#!/bin/bash
ssh $(hostname --domain) "rm .well-known/acme-challenge/$CERTBOT_TOKEN"

Konfiguration des öffentlichen Webservers

apt install nginx
vim /etc/nginx/sites-available/$(hostname --domain)
server {
        listen 80;
        listen [::]:80;

        server_name     *.mydomain.com;

        access_log      /var/log/nginx/letsencrypt-challenge.log;

        location /.well-known/acme-challenge/ {
                root /var/www/letsencrypt/;
                autoindex off;
                index off;
                if ($uri ~ /$) {
                        return 444;
                }
                try_files $uri $uri/ =404;
        }
        location / {
                return 444;
        }
}

Erklärung bitte…

Proxmox

pvenode cert set