Einführung
Ein Supportteam hat eine Hilfeseite bereitgestellt, doch die Clients lehnen die HTTPS-Verbindung ab. HTTPS verwendet TLS, um Daten zu verschlüsseln und die Identität des antwortenden Servers nachzuweisen. Verschlüsselung allein genügt nicht: Der Client muss auch den angefragten Namen erkennen und dem Aussteller des Zertifikats vertrauen.
Du reparierst synthetische Schulungszertifikate auf einem echten Nginx-Server. Grundlegende Terminalkenntnisse reichen aus; Zertifikatsprüfung und Dienstkonfiguration werden hier erklärt. Client und Server sind getrennte Sitzungen und Verzeichnisse derselben VM, keine getrennten Rechner. Nginx läuft in einem vorbereiteten Container. Der optionale HTTPS Monitor zeigt echte interne TLS-Prüfungen; das Schloss des Browsers gehört zu einer anderen äußeren Verbindung.
Eine vertrauenswürdige Referenz abrufen
In diesem Schritt rufst du zunächst ein Dokument eines funktionierenden Dienstes ab und vergleichst ihn anschließend mit der defekten Hilfeseite. Ein Hostname bezeichnet den angefragten Dienst. Alle Schulungsnamen enden auf .lab.test und gelten nur in dieser Übung.
Wähle zu Beginn dieses Schritts den Tab Client in der Lab-Oberfläche aus.
Verwende Client. curl ruft eine URL ab. --cacert root.crt vertraut der bereitgestellten Zertifizierungsstelle (CA), die Zertifikate signiert. Diese CA ist ein Schulungsvertrauensanker, keine öffentliche Stelle. --resolve ordnet einen Namen mit Port einer IP-Adresse zu und behält den Namen für TLS und HTTP bei. 127.0.0.1 bezeichnet diese VM; Port 8443 führt zum vorbereiteten Nginx-Dienst. --noproxy '*' sendet die Anfrage direkt; Anführungszeichen verhindern die Erweiterung von * durch die Shell. --fail weist HTTP-Fehler zurück und --output speichert das tatsächliche Dienstdokument für später.
Wechsle zum Tab Client, bevor du den folgenden Befehl ausführst.
curl --noproxy '*' --fail --cacert root.crt --resolve status.lab.test:8443:127.0.0.1 --output reference.txt https://status.lab.test:8443/
cat zeigt den Dateiinhalt:
cat reference.txt
status service: training content available
Der Download ist ein echtes Referenzdokument, kein Bericht. Frage jetzt den vorgesehenen Hilfeseiten-Hostnamen an. Dieser Befehl soll fehlschlagen und zur Eingabe zurückkehren; fahre danach fort.
curl --noproxy '*' --cacert root.crt --resolve help.lab.test:8443:127.0.0.1 https://help.lab.test:8443/
curl: (60) SSL: no alternative certificate subject name matches target host name 'help.lab.test'
...
Die Referenz funktionierte mit derselben CA und Adresse. Dieser Fehler deutet konkret auf einen unpassenden Namen hin, nicht auf einen gestoppten Server. Behalte den vorgesehenen Hostnamen bei: Eine andere URL würde eine andere Identität prüfen. Wechsle zum Tab HTTPS Monitor, um seine unabhängigen Live-Prüfungen zu sehen: Die Referenz gelingt, während die Anfragen für Hilfe und Dokumentation scheitern. Diese Webseite ist eine Überwachungsansicht; führe die folgenden Terminalarbeiten erst aus, nachdem du den jeweils benannten Terminal-Tab ausgewählt hast.
Die Zertifikatskette prüfen und zusammenstellen
In diesem Schritt vergleichst du die ausgelieferte Identität mit einem vorbereiteten Zertifikat und erstellst ein nutzbares Serverbündel. Ein Zertifikat enthält einen öffentlichen Schlüssel und Identitätsinformationen. Der passende private Schlüssel bleibt auf dem Server. Kopiere private Schlüssel niemals in Berichte und sende sie nicht an Clients.
Wähle zu Beginn dieses Schritts den Tab Client in der Lab-Oberfläche aus.
Wechsle zum Tab Client. Prüfe das tatsächlich ausgelieferte Zertifikat. openssl s_client öffnet eine TLS-Verbindung; -connect nennt die Adresse und -servername sendet den gewünschten Namen über Server Name Indication (SNI), sodass ein Nginx-Listener mehrere Websites bedienen kann. < /dev/null beendet die interaktive Eingabe. 2>/dev/null unterdrückt nur für diese Prüfung die Verbindungsdiagnose. Die Pipe | übergibt das Zertifikat an openssl x509; -noout unterdrückt das codierte Zertifikat, die übrigen Optionen zeigen ausgewählte Felder. Diese Ansicht allein beweist noch kein Vertrauen.
Wechsle zum Tab Client, bevor du den folgenden Befehl ausführst.
openssl s_client -connect 127.0.0.1:8443 -servername help.lab.test </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = legacy.lab.test
issuer=CN = LabEx Training Issuing CA
notBefore=...
notAfter=...
X509v3 Subject Alternative Name:
DNS:legacy.lab.test
Der Subject Alternative Name (SAN) enthält akzeptierte Hostnamen. issuer bezeichnet den Signierer; die Daten begrenzen die Gültigkeit. Das Setup erzeugt neue Zertifikate für diese VM: Endzertifikate gelten 365 Tage. Ein gültiges Datum gleicht einen falschen Namen nicht aus.
Wechsle zum Tab Server. openssl x509 -in liest ein lokales Zertifikat statt einer Netzwerkantwort:
Wechsle zum Tab Server, bevor du den folgenden Befehl ausführst.
openssl x509 -in certs/help.crt -noout -subject -issuer -dates -ext subjectAltName
Sein SAN lautet DNS:help.lab.test und passt zur Anfrage. Die vorgesehenen Zusammenhänge:
| Element | Aufgabe |
|---|---|
help.crt und help.key |
Zertifikat der Hilfeseite und passender privater Schlüssel |
docs.crt und docs.key |
Zertifikat der Dokumentationsseite und passender privater Schlüssel |
issuing.crt |
Zwischen-CA, die beide Seiten signiert hat |
../client/root.crt |
Vom Client vertraute Stamm-CA |
Die Kette lautet Websitezertifikat → Zwischen-CA → vertraute Stamm-CA. Nginx sollte zuerst das Endzertifikat und dann das Zwischenzertifikat senden. Der Client vertraut der Wurzel bereits; sie muss nicht mitgesendet werden. Erstelle das öffentliche Bündel mit cat; > schreibt die Ausgabe in eine Datei und ersetzt deren bisherigen Inhalt. Der private Schlüssel gehört nicht in dieses Bündel.
cat certs/help.crt certs/issuing.crt > certs/help-fullchain.pem
openssl verify prüft das Bündel gegen die angegebene vertrauenswürdige Wurzel. -untrusted stellt Zwischenzertifikate als mögliche Kettenglieder bereit, nicht als weitere Vertrauenswurzeln; -verify_hostname prüft den vorgesehenen Namen.
openssl verify -CAfile ../client/root.crt -untrusted certs/help-fullchain.pem -verify_hostname help.lab.test certs/help-fullchain.pem
certs/help-fullchain.pem: OK
Prüfe bei Fehlern Dateireihenfolge und Schreibweise und wiederhole cat. Damit ist das vorbereitete Bündel geprüft; der laufende Server muss es noch verwenden.
Die Identität der Hilfeseite anwenden
In diesem Schritt liefert Nginx die richtige Identität aus, während die Statusseite funktioniert. Wechsle zum Tab Server. Zeige mit cat die Konfiguration:
Wähle zu Beginn dieses Schritts den Tab Server in der Lab-Oberfläche aus.
Wechsle zum Tab Server, bevor du den folgenden Befehl ausführst.
cat conf/help.conf
server_name wählt die Website aus. ssl_certificate nennt die öffentliche Kette; ssl_certificate_key den privaten Schlüssel. Pfade mit /tls/ liegen im vorbereiteten Nginx-Container und entsprechen hier certs/. Die Zeile return 200 liefert den tatsächlichen Schulungsinhalt. Behalte Listener, Namen und Antwort bei.
Öffne die Datei mit dem Texteditor nano:
nano conf/help.conf
Suche mit den Pfeiltasten die beiden TLS-Direktiven. Ersetze nur diese zwei Zeilen durch:
ssl_certificate /tls/help-fullchain.pem;
ssl_certificate_key /tls/help.key;
Semikolons beenden Nginx-Direktiven. Speichere mit Ctrl+O, bestätige mit Enter und verlasse den Editor mit Ctrl+X. Bei einem falsch geschriebenen Pfad öffnest du dieselbe Datei erneut und korrigierst ihn.
sudo führt einen Befehl mit Administratorrechten aus. docker exec https-edge führt den folgenden Befehl im vorbereiteten Dienstcontainer aus. nginx -t prüft die Konfiguration, ohne sie anzuwenden:
sudo docker exec https-edge nginx -t
Achte auf syntax is ok und test is successful. Bei Fehlern korrigierst du zuerst die genannte Datei und Zeile. nginx -s reload fordert den laufenden Dienst auf, die geprüfte Konfiguration zu laden:
sudo docker exec https-edge nginx -s reload
Wechsle zum Tab Client und wiederhole die vorgesehene Anfrage. Das Neuladen kann kurz dauern; wiederhole dieselbe Anfrage, falls noch das alte Zertifikat erscheint.
Wechsle zum Tab Client, bevor du den folgenden Befehl ausführst.
curl --noproxy '*' --fail --cacert root.crt --resolve help.lab.test:8443:127.0.0.1 https://help.lab.test:8443/
help service: training content available
Erhalte auch die normale Funktion der Referenzseite:
curl --noproxy '*' --fail --cacert root.crt --resolve status.lab.test:8443:127.0.0.1 https://status.lab.test:8443/
Dieser Erfolg prüft den tatsächlich ausgelieferten Namen, die Kette und die Gültigkeitsdaten vor der Antwortannahme. Eine Änderung an einer ungenutzten Zertifikatsdatei reicht dafür nicht.
Ein fehlendes Zwischenzertifikat ergänzen
In diesem Schritt unterscheidest du eine unvollständige Kette vom bereits behobenen Namensfehler. Frage in Client die vorbereitete Dokumentationsseite an. Dieser Fehler ist beabsichtigt:
Wähle zu Beginn dieses Schritts den Tab Client in der Lab-Oberfläche aus.
Wechsle zum Tab Client, bevor du den folgenden Befehl ausführst.
curl --noproxy '*' --cacert root.crt --resolve docs.lab.test:8443:127.0.0.1 https://docs.lab.test:8443/
curl: (60) SSL certificate problem: unable to get local issuer certificate
...
Beide Fehler verwenden Exitcode 60; lies die zugehörige Erklärung. Prüfe das ausgelieferte Zertifikat mit derselben Befehlsform:
openssl s_client -connect 127.0.0.1:8443 -servername docs.lab.test </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Diesmal lautet der SAN DNS:docs.lab.test. Der Name stimmt, aber Nginx sendet nur das Endzertifikat. Der Client kann dessen Aussteller nicht mit der Wurzel verbinden.
Für einen kontrollierten Vergleich überspringt -k die Zertifikatsprüfung. So siehst du, dass Inhalte trotz defekter Vertrauenskette abrufbar sind:
curl --noproxy '*' -k --resolve docs.lab.test:8443:127.0.0.1 https://docs.lab.test:8443/
docs service: training content available ist hier kein Reparaturnachweis. Wechsle zurück zum Tab Server, lies die aktive Datei und öffne sie:
Wechsle zum Tab Server, bevor du den folgenden Befehl ausführst.
cat conf/docs.conf
nano conf/docs.conf
Die vorbereitete docs-fullchain.pem enthält bereits End- und Zwischenzertifikat in dieser Reihenfolge. Ersetze nur die Zeile ssl_certificate:
ssl_certificate /tls/docs-fullchain.pem;
Behalte /tls/docs.key als privaten Schlüssel. Speichere und schließe wie zuvor, prüfe und lade dann neu:
sudo docker exec https-edge nginx -t
sudo docker exec https-edge nginx -s reload
Wechsle zum Tab Client. Frage alle drei vorgesehenen Namen ohne -k an. Die Schleife weist host nacheinander jeden Wert zu; $host fügt ihn ein und doppelte Anführungszeichen halten die entstehenden Argumente zusammen.
Wechsle zum Tab Client, bevor du den folgenden Befehl ausführst.
for host in help docs status; do
curl --noproxy '*' --fail --cacert root.crt --resolve "$host.lab.test:8443:127.0.0.1" "https://$host.lab.test:8443/"
done
Erwarte die drei zugehörigen Dienstantworten. Du kannst zum Tab HTTPS Monitor wechseln und die Seite aktualisieren, um seine unabhängigen Live-Prüfungen zu vergleichen. Scheitert eine Prüfung, wechsle zurück zum Tab Server, korrigiere die passende Konfiguration, prüfe sie und lade Nginx neu. Wechsle anschließend zum Tab Client, um die verifizierten Anfragen zu wiederholen; ändere weder die Vertrauenswurzel des Clients noch die vorgesehenen Hostnamen. In realen Deployments beziehst du genehmigte Zertifikate über den Ausstellungsprozess deiner Organisation; diese Übung bietet synthetische Kandidaten für die Diagnose.
Zusammenfassung
Du hast eine vertrauenswürdige Referenz abgerufen, echte Zertifikatsnamen und Aussteller geprüft, ein Bündel aus End- und Zwischenzertifikat erstellt und es durch ein geprüftes Nginx-Neuladen angewendet. Du hast Namensfehler und unvollständige Ketten behoben und den normalen Dienst erhalten. Die folgende Challenge kombiniert diese Entscheidungen für ein anderes Portal.
