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.
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.
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 Namen bei: Eine andere URL würde eine andere Identität prüfen.
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.
Prüfe in Client 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.
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 zu Server. openssl x509 -in liest ein lokales Zertifikat statt einer Netzwerkantwort:
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. Zeige in Server mit cat die Konfiguration:
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 zu Client und wiederhole die vorgesehene Anfrage. Das Neuladen kann kurz dauern; wiederhole dieselbe Anfrage, falls noch das alte Zertifikat erscheint.
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:
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. Kehre zu Server zurück, lies die aktive Datei und öffne sie:
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
Frage in Client 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.
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 HTTPS Monitor aktualisieren und seine unabhängigen Live-Prüfungen vergleichen. Korrigiere Fehler in der passenden Konfiguration, prüfe und lade neu; ändere weder die Vertrauenswurzel des Clients noch die vorgesehenen Namen. 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.
