Alle Anleitungen

Eine eigene Website auf einem .lopux-Namen

Sie haben einen Namen im Lopux-Internet; diese Anleitung stellt eine echte Website dahinter, erreichbar für jeden, der die App benutzt. Wenn Sie noch keinen Namen haben, belegen Sie zuerst einen.

Vorausgesetzt wird, dass Sie einen Webserver betreiben können, sonst nichts. Alles, was am Lopux-Internet besonders ist, steht hier: warum das Zertifikat selbstsigniert ist, was neben Ihrer Website laufen muss und welche zwei Einträge den Namen zum Funktionieren bringen.

Die Screenshots zeigen die englische Oberfläche. Der Kundenbereich spricht sechs Sprachen — wählen Sie Ihre mit der Schaltfläche EN oben rechts.

1. Was Sie brauchen und was nicht funktioniert

Eine Maschine, auf der Sie TLS auf Port 443 kontrollieren. Ein VPS, ein dedizierter Server, ein Rechner zu Hause mit erreichbarer Adresse. Das ist die ganze Anforderung, und sie ist eine echte.

Verwaltete Plattformen können das nicht hosten, aus zwei unabhängigen Gründen. Vercel, Netlify, Cloudflare Pages, die meisten PaaS: Sie tragen eine eigene Domain ein, und sie besorgen und liefern das Zertifikat. Der ganze Punkt hier ist, dass Ihr Server beweist, den Schlüssel zu besitzen, den Sie veröffentlicht haben — eine Plattform, die ihren eigenen Schlüssel ausliefert, kann diesen Beweis nicht führen, und die App eines Besuchers würde die Seite zurückweisen, zu Recht. Den Namen würden sie ohnehin nicht annehmen: Die Domain-Einrichtung prüft den Besitz über das gewöhnliche DNS, wo mysite.lopux nicht existiert und nie existieren wird.

Ein CDN davor hilft ebenfalls nicht — es terminiert TLS, also dasselbe Problem.

Plattformen, bei denen Sie eigenes Zertifikat und Schlüssel hochladen können, funktionierten technisch. Dann aber kann diese Partei sich gegenüber jedem Besucher als Ihre Website ausgeben, unbemerkt, und nichts in diesem Aufbau kann das entdecken. Behandeln Sie es wie das, was es ist: die Weitergabe Ihres privaten Schlüssels.

2. Warum das Zertifikat selbstsigniert ist

Keine Zertifizierungsstelle darf für einen Lopux-Internet-Namen ausstellen. Nicht weil es schwierig wäre, sondern weil es verboten ist: Eine Stelle darf nur für Namen unter der gewöhnlichen DNS-Wurzel ausstellen, und diese Namen liegen bewusst außerhalb davon.

Statt einen Fremden für sich bürgen zu lassen, veröffentlichen Sie den Fingerabdruck Ihres eigenen Schlüssels in der Zone Ihres Namens, und die App jedes Besuchers prüft den erreichten Server gegen diesen Eintrag. Der Eintrag ist die Autorität.

In einer Hinsicht ist das strenger als eine Zertifizierungsstelle: Mit einer Stelle könnten Hunderte Organisationen je ein Zertifikat für Ihren Namen ausstellen, und jedem würde geglaubt. Hier funktioniert nur der Schlüssel, den Sie veröffentlicht haben.

3. Das Zertifikat erstellen

Zehn Jahre, ohne Passphrase, und jeder Name, den Sie ausliefern, in subjectAltName:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -keyout site.key -out site.crt -days 3650 -nodes \
  -subj "/CN=mysite.lopux" \
  -addext "subjectAltName=DNS:mysite.lopux,DNS:www.mysite.lopux"

Drei Dinge zu diesem Befehl:

• die Gültigkeitsdaten spielen hier keine Rolle. Apps ignorieren sie absichtlich: Ob Ihr

Schlüssel noch gilt, entscheidet der veröffentlichte Eintrag, nicht ein Datum im Zertifikat. Es gibt also keine Erneuerung, nie. Zehn Jahre sind schlicht länger, als es Sie kümmern wird;

• -nodes heißt, der Schlüssel hat keine Passphrase, und genau das braucht ein Webserver, um

ohne Menschen zu starten. Halten Sie ihn nur für den Server-Benutzer lesbar (chmod 600) und außerhalb jedes Images, das Sie irgendwohin schieben;

• legen Sie nichts ins Zertifikat, was Sie nicht veröffentlichen würden. Wer den Handshake mit Ihrem Server abschließt, bekommt es und liest den Namen daraus. Ein Name, keine Organisation,

keine E-Mail.

4. Was neben Ihrer Website läuft

Ihre Website spricht einfaches HTTP und sieht nie ein Zertifikat. Davor steht nginx, der TLS mit dem veröffentlichten Schlüssel terminiert und die Anfrage nach innen reicht.

Diesen Vorbau braucht es, weil ein Lopux-Internet-Ursprung mehrere Einstellungen verlangt, die das Gegenteil dessen sind, was eine gewöhnliche „gehärtete nginx"-Vorlage liefert — und jede davon geht so kaputt, dass es im Browser in Ordnung aussieht:

Hier ist dieser nginx, vollständig. Ersetzen Sie Namen, Pfade und die Adresse dahinter:

map $http_upgrade $connection_upgrade { default upgrade; '' close; }
server_tokens off;

# nicht Ihr Name: verschlossene Tür, vor jedem Zertifikat
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name mysite.lopux;

    ssl_certificate     /etc/ssl/site.crt;   # der veröffentlichte Schlüssel
    ssl_certificate_key /etc/ssl/site.key;
    ssl_protocols       TLSv1.2 TLSv1.3;     # selbstsigniert: nichts zu stapeln

    client_header_timeout 10s;   # begrenzen den Handshake — siehe unten
    client_body_timeout   10s;
    send_timeout          10s;
    keepalive_timeout     30s;
    reset_timedout_connection on;

    proxy_hide_header Strict-Transport-Security;

    location / {
        proxy_pass http://127.0.0.1:8080;   # Ihre Website, HTTP, nicht öffentlich
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto https;   # Regel 2: keine Umleitung
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header Upgrade           $http_upgrade;
        proxy_set_header Connection        $connection_upgrade;
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
    }
}

Eine Falle in diesen Fristen, an der nginx schlicht nicht startet: ssl_handshake_timeout gibt es im http-Modul von nginx nicht — es gehört zu stream. In http wird der Handshake von client_header_timeout begrenzt, und genau dieser Wert leistet hier die Arbeit.

Zum SNI-Gatter noch ein Absatz, denn es leistet etwas weniger Offensichtliches, als sich vor Scannern zu verstecken. Ohne es reicht Ihr Server dasselbe Zertifikat — und damit dieselbe Browserwarnung — an zwei Besucher in entgegengesetzten Lagen: an einen, dessen App Ihren Schlüssel gegen den Eintrag geprüft hat, bevor ein Byte der Seite floss, und an einen, der Ihre IP-Adresse eingetippt hat, wo gar nichts geprüft wurde. Das Gatter entfernt den zweiten Fall. Es macht die Warnung nicht zu einer Prüfung: Wer Ihren Namen kennt, trägt ihn in seine eigene hosts ein und kommt ungeprüft an wie zuvor.

Eine Regel zu Ihren Seiten, die leicht übersehen wird: verwenden Sie relative Links. /about, nicht https://mysite.lopux/about. Ein Besucher im einfachen http://-Modus kann einem absoluten https://-Link auf Ihre eigene Website nicht folgen, und das Lopux-Internet schreibt Ihre Seiten bewusst nicht um. Links auf andere Websites sind Ihre Sache und davon nicht betroffen.

5. Den Fingerabdruck veröffentlichen

Öffnen Sie Ihren Namen im Kundenbereich und scrollen Sie zu Zertifikate. Solange nichts veröffentlicht ist, sagt der Bereich es deutlich: Es gibt nichts zu prüfen, also weigert sich die App, die Seite zu öffnen, statt ungeprüft zu verbinden.

Laden Sie site.crt mit Zertifikatsdatei wählen… hoch oder fügen Sie es ein. Nur das Zertifikat — die Datei, die mit -----BEGIN PRIVATE KEY----- beginnt, bleibt auf Ihrem Server, und der Kundenbereich weist sie ab, statt sie zu speichern.

Drücken Sie Schlüssel-Fingerabdruck veröffentlichen. Der Kundenbereich liest das Zertifikat, nimmt den SHA-256 seines öffentlichen Schlüssels und schreibt ihn in Ihre Zone.

Vergleichen Sie ihn mit Ihrer eigenen Kopie — sie müssen übereinstimmen:

openssl x509 -in site.crt -noout -pubkey \
  | openssl pkey -pubin -outform der | openssl dgst -sha256

Der Bereich ist eine Vordertür zu einem gewöhnlichen Eintrag. Derselbe Wert steht in Ihrer Eintragsliste als TLSA-Eintrag unter _443._tcp, und dort ist er zu sehen:

6. Den Namen auf Ihren Server richten

Fügen Sie in derselben Ansicht einen A-Eintrag hinzu, dessen Wert die öffentliche Adresse Ihres Servers ist. @ meint den Namen selbst.

Jetzt trägt die Zone beide Einträge, und zusammen sind sie alles, was die App eines Besuchers braucht: Der A-Eintrag sagt, wo Ihr Server steht, der TLSA-Eintrag, welchen Schlüssel er vorlegen muss.

Rechnen Sie mit etwa zehn Minuten, bevor eine Änderung überall sichtbar ist. Zwei Zwischenspeicher liegen im Weg — der des Resolvers und der der App — je fünf Minuten.

7. Prüfen

Der Kundenbereich holt Ihre Website so, wie ein Besucher es täte, und meldet, was den Betrieb verhindern würde: ein Schlüssel, der nicht dem veröffentlichten entspricht, ein fehlender Fingerabdruck, ein HSTS-Header, eine Umleitung auf https://, absolute Selbstlinks oder ein Server, der nicht geantwortet hat.

Auf diesem Screenshot verweigert die Prüfung den Dienst: Die Adresse im Beispiel ist eine Dokumentationsadresse, und der Kundenbereich stochert nicht in etwas, das aus dem Internet nicht erreichbar ist — einen Namen auf eine private oder Loopback-Adresse zu richten würde die Prüfung zu einem Scan in fremden Netzen machen. Mit einem echten Server unter einer echten Adresse antwortet sie, dass alles in Ordnung ist, oder benennt genau, was nicht stimmt.

Zwei Prüfungen, die Sie selbst ausführen können, und es sind die wichtigsten:

# ohne SNI — abgelehnt
openssl s_client -connect YOUR_ADDRESS:443 </dev/null

# Ihr Zertifikat
openssl s_client -connect YOUR_ADDRESS:443 -servername mysite.lopux </dev/null

Die zweite sollte Ihnen das Zertifikat reichen, dessen Fingerabdruck Sie veröffentlicht haben. Nehmen Sie dessen Schlüssel-Fingerabdruck wie in §5 und vergleichen Sie: Gehen die Zeichenfolgen auseinander, wird jeder Besucher abgewiesen — und für ihn sieht es genau wie ein Täuschungsversuch aus.

8. Was ein Besucher sieht

Eine richtig eingerichtete Website öffnet sich unter ihrem eigenen Namen wie jede andere:

Das ist lopux.ipvx — die eigene Website dieses Projekts. Sie lebt im Namensraum genauso, wie Ihre es tun wird, und ist genau in dieser Form aufgesetzt. Der ausgelieferte Schlüssel entspricht ihrem veröffentlichten Fingerabdruck, und deshalb öffnet eine App sie ohne ein Wort der Warnung.

Was verschiedene Besucher bekommen:

Die letzte Zeile ist der Sinn des Namensraums, keine Einschränkung. Beachten Sie aber die Zeile darüber: Ihr Server ist eine gewöhnliche öffentliche Maschine, und jeder kann ihn über seine Adresse erreichen. Der Namensraum verbirgt ihn nicht, und Ihr Zertifikat nennt Ihre Website jedem, der den Handshake abschließt — dafür ist das SNI-Gatter aus §4 da.

9. Den Schlüssel hüten

Nichts hier bemerkt einen gestohlenen Schlüssel; es macht nur die Bindung zwischen Ihrem Namen und Ihrem Schlüssel verbindlich. Wer Ihren Schlüssel hat, weist sich einwandfrei aus, bis Sie einen neuen Fingerabdruck veröffentlichen.

• halten Sie site.key nur für den Webserver-Benutzer lesbar und außerhalb des ausgelieferten Verzeichnisses;
• sichern Sie ihn verschlüsselt — ein Verlust kostet Sie einen Wechsel, nicht Ihren Namen;
• ein Wechsel ist billig, also wechseln Sie bei jedem Verdacht. Veröffentlichen Sie das neue Zertifikat vor dem Umschalten: Solange zwei Fingerabdrücke veröffentlicht sind, wird jeder der beiden Schlüssel akzeptiert, und es gibt keinen Moment, in dem Ihre Website unerreichbar ist. Dann schalten Sie den Server um, warten zehn Minuten und entfernen den alten;
• einen Fingerabdruck zu entfernen ist der Widerruf. Niemanden zu fragen, nichts abzuwarten: innerhalb des Zwischenspeicher-Fensters wird ein Besucher abgewiesen, statt dem gezeigt zu werden, der den alten Schlüssel hat.

10. Wenn etwas nicht stimmt

Die App benennt den Fehler, statt eine leere Seite zu zeigen. Was jeder bedeutet:

Alle Anleitungen