Begriff
Certificate Authority (CA)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Wenn du deinen Reisepass zeigst, glaubt dir der Polizist. Warum?
Nicht weil du nett aussiehst, sondern weil der Bundesadler (Staat) drauf gedruckt ist.
Der Staat bürgt für deine Identität.
Im Internet ist die Certificate Authority (CA) der Staat.
Wenn du google.com öffnest, zeigt dir der Server einen Ausweis (Zertifikat).
Woher weiß dein Browser, dass das echt ist?
Weil eine CA (z. B. "Let's Encrypt" oder "DigiCert") diesen Ausweis unterschrieben hat.
Dein Browser vertraut der CA, also vertraut er auch google.com.
Es ist eine Kette des Vertrauens (Chain of Trust).
Merksatz: Eine vertrauenswürdige Organisation oder Instanz, die digitale Zertifikate ausstellt, signiert und verwaltet, um Identitäten im Netzwerk (z. B. Webserver) zu bestätigen.
Als Admin willst du HTTPS für deine Webseite.
- CSR erstellen: Du erstellst einen "Certificate Signing Request" auf deinem Server. Da steht drin: "Ich bin mein-shop.de".
- Einreichen: Du schickst den CSR an die CA (z. B. Let's Encrypt).
- Validierung: Die CA prüft: "Gehört dir die Domain wirklich?". (Oft muss man eine Datei auf den Webserver legen).
- Issuance: Wenn Prüfung OK -> CA unterschreibt deinen CSR und schickt dir das
.crt(Zertifikat) zurück. - Installation: Du konfigurierst Nginx/Apache mit dem Zertifikat. Der Browser zeigt nun das grüne Schloss.
1. Root vs. Intermediate CA
Dein Browser (Chrome/Firefox) hat ~150 Root CAs fest eingebaut (Trust Store). Das sind die "Ur-Vertrauensanker".
Die Root CA unterschreibt aber fast nie direkt Webseiten. (Ihr Private Key liegt im Hochsicherheits-Tresor, offline).
Sie unterschreibt eine Intermediate CA (Zwischen-Zertifikat).
Die Intermediate CA unterschreibt dann google.com.
Vorteil: Wenn die Intermediate CA gehackt wird, muss man nur diese sperren (Revoke), nicht die ganze Root CA austauschen (was ein globales Browser-Update erfordern würde).
2. Revocation (CRL & OCSP)
Was, wenn ein Zertifikat gestohlen wird? Die CA muss es für ungültig erklären.
- CRL (Certificate Revocation List): Eine riesige Liste "gesperrter Seriennummern". Browser laden die ungern (zu groß, langsam).
- OCSP (Online Certificate Status Protocol): Der Browser fragt live bei der CA: "Ist Zertifikat X noch gut?". Problem: Datenschutz (CA weiß, wo du surfst) und Performance (wenn CA down -> Seite lädt nicht).
- OCSP Stapling: Der Webserver holt selbst den "Beweis" von der CA ("Hier, ich bin noch gültig, Unterschrift von vor 5 Minuten") und liefert ihn direkt mit. Beste Lösung.
3. Private CA (Intern)
In Firmen nutzt man oft eine Private CA (HashiCorp Vault, Active Directory CS).
Damit sichert man interne Server (db.internal).
Wichtig: Damit Browser das akzeptieren, muss man das "Root Zertifikat" der Firma per Gruppenrichtlinie (GPO) auf alle Mitarbeiter-Laptops verteilen. Sonst kommt "Warnung: Unsicher".
The WebPKI Ecosystem und CAA Records
Die WebPKI ist ein fragiles Ökosystem. Es reicht, dass eine Root-CA gehackt wird, und der Angreifer kann Zertifikate für jede Domain weltweit ausstellen.
Um das zu verhindern, nutzen DNS-Admins CAA Records (Certificate Authority Authorization).
Wenn du im DNS für example.com einen CAA Record mit issue "letsencrypt.org" setzt, sagst du damit allen anderen CAs der Welt: "Nur Let's Encrypt darf Zertifikate für mich ausstellen." Alle vertrauenswürdigen CAs prüfen diesen Record zwingend vor der Ausstellung (RFC 8659). Weigert sich eine CA oder ignoriert sie den Record, verliert sie ihren Status im Browser-Trust-Store.
Cross-Signing und Root-Expiration
Was passiert, wenn ein Root-Zertifikat abläuft? (Let's Encrypt DST Root CA X3 lief 2021 aus). Mio. Geräte (alte Smart-TVs, Android 7) bekommen kein Update mehr, um das neue Root-Cert in ihren Trust-Store zu laden. Die Lösung ist Cross-Signing. Let's Encrypt ließ sein neues Root/Intermediate-Zertifikat zusätzlich von einer alten, noch gültigen Root-CA eines Drittanbieters unterschreiben. Somit gibt es zwei Validierungspfade: Moderne Geräte nutzen den kurzen Pfad zur neuen ISRG Root X1, alte Geräte ignorieren diesen und gehen den langen Pfad zur uralten (cross-signed) Root-CA. Das kaufte der Industrie Jahre an Zeit, bevor alte Geräte endgültig aus dem Netz fallen.
Sub-CAs und Name Constraints
Firmen kaufen sich manchmal eine dedizierte Intermediate-CA (eine "Sub-CA") von einer Root-CA, um Zertifikate intern selbst ("on the fly") signieren zu können, die im Browser als öffentlich vertrauenswürdig gelten.
Das ist ein massives Risiko für die Root-CA (die Firma könnte ja ein Cert für google.com signieren).
Deshalb setzt die Root-CA Name Constraints im X.509-Profil der Intermediate.
Der Constraint besagt: "Diese Sub-CA darf nur Zertifikate signieren, die auf .firma-xyz.com enden." Jeder Browser lehnt ein Zertifikat ab, das von dieser Sub-CA für andere Domains ausgestellt wurde.
Quick-Check
Was ist Let's Encrypt?
Eine gemeinnützige CA, die Zertifikate kostenlos und automatisiert (ACME Protokoll) ausstellt. Hat das Internet revolutioniert (HTTPS Everywhere). Früher kosteten Zertifikate hunderte Euro.Was passiert, wenn die Root CA "böse" wird?
Wie bei "Symantec" oder "DigiNotar" passiert. Die Browser-Hersteller (Google, Apple) entfernen die Root CA aus dem Trust Store ("Distrust"). Millionen Webseiten werden über Nacht "unsicher". Das ist das Todesurteil für eine CA.Wildcard Zertifikat?
Gilt für*.example.com(alsowww,mail,api). Praktisch, aber gefährlich: Wenn der Key aufmailgeklaut wird, ist auchapikompromittiert.