CA (Certificate Authority)

Als Admin:

1. Erstelle einen CSR (Certificate Signing Request) auf deinem Server.
2. Sende den CSR an die CA (z. B. Let's Encrypt via certbot).
3. Beweise Domainbesitz (DNS-Eintrag oder HTTP-Upload).
4. CA schickt dir das unterschriebene Cert (.crt) zurück.
5. Installiere es im Webserver.

1. Root vs. Intermediate CA

Die CA nutzt ihren Root Key (den allerheiligsten Schlüssel) fast nie. Er liegt offline in einem Tresor (Air-Gapped). Sie erstellt damit Intermediate CAs ("Arbeits-Schlüssel"). Diese unterschreiben dann die Millionen Kunden-Zertifikate. Vorteil: Wenn eine Intermediate CA gehackt wird, muss man nicht das Root Cert tauschen (was Milliarden Geräte betreffen würde), sondern sperrt nur die Intermediate (Revocation).

2. CA/Browser Forum

Wer entscheidet, wer CA sein darf? Ein Gremium aus Browser-Herstellern (Google, Mozilla, Apple) und CAs. Wenn eine CA Mist baut (z. B. Symantec hat 2017 illegal Zertifikate ausgestellt), werfen die Browser sie raus ("Distrusted"). Über Nacht sind Millionen Webseiten "unsicher". CAs haben immense Verantwortung.

3. Private CA

In Firmen nutzt man oft eine eigene CA (Microsoft Active Directory Certificate Services). Man installiert das Root-Cert dieser privaten CA auf allen Firmen-Laptops (per Group Policy). Damit kann die Firma interne Seiten (wiki.internal) absichern oder Traffic "aufbrechen" (SSL Inspection an der Firewall), ohne dass Warnmeldungen kommen.

The Root Key Ceremony

Wie erstellt man das Root-Zertifikat einer vertrauenswürdigen CA (wie DigiCert)? Das ist ein Event wie aus einem Heist-Movie. Es ist eine hoch-formalistische Key Ceremony. Sie findet in einem Bunker-ähnlichen Raum statt (meist tief in Rechenzentren, bewacht von bewaffnetem Sicherheitspersonal). Es gibt eine physische "Air Gap": Der Computer, der den Schlüssel generiert, hat weder WLAN noch Bluetooth-Chips und wird nach der Generierung oft zerstört oder dauerhaft weggeschlossen. Mehrere Personen (oft Auditoren großer WP-Gesellschaften) müssen ihre Badges und biometrischen Daten kombinieren, um den Safe mit Hardware Security Modulen (HSMs) zu öffnen. Alles wird per Video aufgezeichnet und notariell beglaubigt.

Revocation Constraints: CRLs vs. OCSP

Wenn ein privater Schlüssel (dein Let's Encrypt Schlüssel) gestohlen wird, musst du das Zertifikat widerrufen (Revocation). Wie erfährt der Browser das?

1. CRL (Certificate Revocation List): Die CA pflegt eine riesige Liste gesperrter Arrays. Früher luden Browser diese Gigabyte-große Liste regelmäßig herunter. Sehr ineffizient.
2. OCSP (Online Certificate Status Protocol): Der Browser fragt die CA bei jedem Seitenaufruf "live": "Ist Zertifikat X noch gültig?". Problem bei OCSP: A) Performance (die Seite lädt langsam). B) Privacy (die CA weiß, wann welcher User welche Webseite besucht). Deshalb setzt sich OCSP Stapling durch: Der Webserver selbst holt sich eine zeitlich begrenzte, signierte Bestätigung ("Ticket") von der CA und legt ("stapelt") sie dem Zertifikat beim Handshake bei. Der Browser muss die CA nicht mehr kontaktieren.

Das ACME-Protokoll

Let's Encrypts größte Innovation ist das ACME (Automatic Certificate Management Environment) Protokoll. Es automatisiert die Ausstellung vollends. Es fungiert als API:

1. Client an Let's Encrypt (LE): "Ich will ein Zertifikat für example.com."
2. LE: "Beweise es. Lege eine Datei mit folgendem kryptografischen Token unter http://example.com/.well-known/acme-challenge/XYZ ab." (HTTP-01 Challenge).
3. Client generiert die Datei.
4. LE schickt seinen Requesting Server los, um die URL extern abzurufen. Stimmt das Token, ist die Domain validiert. Zusätzlich gibt es die DNS-01 Challenge (Hinzufügen eines TXT-Records zum DNS), welche zwingend erforderlich ist, wenn man Wildcard-Zertifikate (*.example.com) beantragen möchte.