Update deployment/https.md

docs/de/docs/deployment/https.md

@@ -1,4 +1,4 @@
-# Über HTTPS
+# Über HTTPS { #about-https }
 
 Es ist leicht anzunehmen, dass HTTPS etwas ist, was einfach nur „aktiviert“ wird oder nicht.
 
@@ -22,13 +22,13 @@ Aus **Sicht des Entwicklers** sollten Sie beim Nachdenken über HTTPS Folgendes
 * Die Verschlüsselung der Verbindung erfolgt auf **TCP-Ebene**.
     * Das ist eine Schicht **unter HTTP**.
     * Die Handhabung von **Zertifikaten und Verschlüsselung** erfolgt also **vor HTTP**.
-* **TCP weiß nichts über „<abbr title="Domäne, Bereich, Wirkungsraum">Domains</abbr>“**. Nur über IP-Adressen.
+* **TCP weiß nichts über „Domains“**. Nur über IP-Adressen.
     * Die Informationen über die angeforderte **spezifische Domain** befinden sich in den **HTTP-Daten**.
 * Die **HTTPS-Zertifikate** „zertifizieren“ eine **bestimmte Domain**, aber das Protokoll und die Verschlüsselung erfolgen auf TCP-Ebene, **ohne zu wissen**, um welche Domain es sich handelt.
 * **Standardmäßig** bedeutet das, dass Sie nur **ein HTTPS-Zertifikat pro IP-Adresse** haben können.
     * Ganz gleich, wie groß Ihr Server ist oder wie klein die einzelnen Anwendungen darauf sind.
     * Hierfür gibt es jedoch eine **Lösung**.
-* Es gibt eine **Erweiterung** zum **TLS**-Protokoll (dasjenige, das die Verschlüsselung auf TCP-Ebene, vor HTTP, verwaltet) namens **<a href="https://en.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Server Name Indication – Angabe des Servernamens">SNI</abbr></a>**.
+* Es gibt eine **Erweiterung** zum **TLS**-Protokoll (dasjenige, das die Verschlüsselung auf TCP-Ebene, vor HTTP, verwaltet) namens **<a href="https://en.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Server Name Indication">SNI</abbr></a>**.
     * Mit dieser SNI-Erweiterung kann ein einzelner Server (mit einer **einzelnen IP-Adresse**) über **mehrere HTTPS-Zertifikate** verfügen und **mehrere HTTPS-Domains/Anwendungen** bedienen.
     * Damit das funktioniert, muss eine **einzelne** Komponente (Programm), die auf dem Server ausgeführt wird und welche die **öffentliche IP-Adresse** überwacht, **alle HTTPS-Zertifikate** des Servers haben.
 * **Nachdem** eine sichere Verbindung hergestellt wurde, ist das Kommunikationsprotokoll **immer noch HTTP**.
@@ -43,7 +43,7 @@ Einige der Optionen, die Sie als TLS-Terminierungsproxy verwenden können, sind:
 * Nginx
 * HAProxy
 
-## Let's Encrypt
+## Let's Encrypt { #lets-encrypt }
 
 Vor Let's Encrypt wurden diese **HTTPS-Zertifikate** von vertrauenswürdigen Dritten verkauft.
 
@@ -57,11 +57,11 @@ Die Domains werden sicher verifiziert und die Zertifikate werden automatisch gen
 
 Die Idee besteht darin, den Erwerb und die Erneuerung der Zertifikate zu automatisieren, sodass Sie **sicheres HTTPS, kostenlos und für immer** haben können.
 
-## HTTPS für Entwickler
+## HTTPS für Entwickler { #https-for-developers }
 
 Hier ist ein Beispiel, wie eine HTTPS-API aussehen könnte, Schritt für Schritt, wobei vor allem die für Entwickler wichtigen Ideen berücksichtigt werden.
 
-### Domainname
+### Domainname { #domain-name }
 
 Alles beginnt wahrscheinlich damit, dass Sie einen **Domainnamen erwerben**. Anschließend konfigurieren Sie ihn in einem DNS-Server (wahrscheinlich beim selben Cloud-Anbieter).
 
@@ -77,17 +77,17 @@ Dieser Domainnamen-Aspekt liegt weit vor HTTPS, aber da alles von der Domain und
 
 ///
 
-### DNS
+### DNS { #dns }
 
 Konzentrieren wir uns nun auf alle tatsächlichen HTTPS-Aspekte.
 
-Zuerst würde der Browser mithilfe der **DNS-Server** herausfinden, welches die **IP für die Domain** ist, in diesem Fall für `someapp.example.com`.
+Zuerst würde der Browser mithilfe der **DNS-Server** herausfinden, welches die **IP für die Domain** ist, in diesem Fall `someapp.example.com`.
 
 Die DNS-Server geben dem Browser eine bestimmte **IP-Adresse** zurück. Das wäre die von Ihrem Server verwendete öffentliche IP-Adresse, die Sie in den DNS-Servern konfiguriert haben.
 
 <img src="/img/deployment/https/https01.drawio.svg">
 
-### TLS-Handshake-Start
+### TLS-Handshake-Start { #tls-handshake-start }
 
 Der Browser kommuniziert dann mit dieser IP-Adresse über **Port 443** (den HTTPS-Port).
 
@@ -97,7 +97,7 @@ Der erste Teil der Kommunikation besteht lediglich darin, die Verbindung zwische
 
 Diese Interaktion zwischen dem Client und dem Server zum Aufbau der TLS-Verbindung wird als **<abbr title="TLS-Handschlag">TLS-Handshake</abbr>** bezeichnet.
 
-### TLS mit SNI-Erweiterung
+### TLS mit SNI-Erweiterung { #tls-with-sni-extension }
 
 **Nur ein Prozess** im Server kann an einem bestimmten **Port** einer bestimmten **IP-Adresse** lauschen. Möglicherweise gibt es andere Prozesse, die an anderen Ports dieselbe IP-Adresse abhören, jedoch nur einen für jede Kombination aus IP-Adresse und Port.
 
@@ -127,7 +127,7 @@ Beachten Sie, dass die Verschlüsselung der Kommunikation auf der **TCP-Ebene**
 
 ///
 
-### HTTPS-Request
+### HTTPS-Request { #https-request }
 
 Da Client und Server (sprich, der Browser und der TLS-Terminierungsproxy) nun über eine **verschlüsselte TCP-Verbindung** verfügen, können sie die **HTTP-Kommunikation** starten.
 
@@ -135,19 +135,19 @@ Der Client sendet also einen **HTTPS-Request**. Das ist einfach ein HTTP-Request
 
 <img src="/img/deployment/https/https04.drawio.svg">
 
-### Den Request entschlüsseln
+### Den Request entschlüsseln { #decrypt-the-request }
 
 Der TLS-Terminierungsproxy würde die vereinbarte Verschlüsselung zum **Entschlüsseln des Requests** verwenden und den **einfachen (entschlüsselten) HTTP-Request** an den Prozess weiterleiten, der die Anwendung ausführt (z. B. einen Prozess, bei dem Uvicorn die FastAPI-Anwendung ausführt).
 
 <img src="/img/deployment/https/https05.drawio.svg">
 
-### HTTP-Response
+### HTTP-Response { #http-response }
 
 Die Anwendung würde den Request verarbeiten und eine **einfache (unverschlüsselte) HTTP-Response** an den TLS-Terminierungsproxy senden.
 
 <img src="/img/deployment/https/https06.drawio.svg">
 
-### HTTPS-Response
+### HTTPS-Response { #https-response }
 
 Der TLS-Terminierungsproxy würde dann die Response mithilfe der zuvor vereinbarten Kryptografie (als das Zertifikat für `someapp.example.com` verhandelt wurde) **verschlüsseln** und sie an den Browser zurücksenden.
 
@@ -157,7 +157,7 @@ Als Nächstes überprüft der Browser, ob die Response gültig und mit dem richt
 
 Der Client (Browser) weiß, dass die Response vom richtigen Server kommt, da dieser die Kryptografie verwendet, die zuvor mit dem **HTTPS-Zertifikat** vereinbart wurde.
 
-### Mehrere Anwendungen
+### Mehrere Anwendungen { #multiple-applications }
 
 Auf demselben Server (oder denselben Servern) könnten sich **mehrere Anwendungen** befinden, beispielsweise andere API-Programme oder eine Datenbank.
 
@@ -167,7 +167,7 @@ Nur ein Prozess kann diese spezifische IP und den Port verarbeiten (in unserem B
 
 Auf diese Weise könnte der TLS-Terminierungsproxy HTTPS und Zertifikate für **mehrere Domains**, für mehrere Anwendungen, verarbeiten und die Requests dann jeweils an die richtige Anwendung weiterleiten.
 
-### Verlängerung des Zertifikats
+### Verlängerung des Zertifikats { #certificate-renewal }
 
 Irgendwann in der Zukunft würde jedes Zertifikat **ablaufen** (etwa 3 Monate nach dem Erwerb).
 
@@ -190,7 +190,7 @@ Um dies zu erreichen und den unterschiedlichen Anwendungsanforderungen gerecht z
 
 Dieser ganze Erneuerungsprozess, während die Anwendung weiterhin bereitgestellt wird, ist einer der Hauptgründe, warum Sie ein **separates System zur Verarbeitung von HTTPS** mit einem TLS-Terminierungsproxy haben möchten, anstatt einfach die TLS-Zertifikate direkt mit dem Anwendungsserver zu verwenden (z. B. Uvicorn).
 
-## Zusammenfassung
+## Zusammenfassung { #recap }
 
 **HTTPS** zu haben ist sehr wichtig und in den meisten Fällen eine **kritische Anforderung**. Die meiste Arbeit, die Sie als Entwickler in Bezug auf HTTPS aufwenden müssen, besteht lediglich darin, **diese Konzepte zu verstehen** und wie sie funktionieren.