Zertifikatsstellen

Kurz: Vertrauenswürdige Organisationen (Certificate Authorities, CAs), die digitale Zertifikate ausstellen und mit ihrer eigenen Signatur bestätigen.

Genauer: Bevor eine CA ein Zertifikat ausstellt, prüft sie (je nach Zertifikatstyp mehr oder weniger streng), ob der Antragsteller wirklich Kontrolle über die betreffende Domain/Organisation hat. Browser und Betriebssysteme vertrauen einer vordefinierten Liste von Root-CAs — jedes Zertifikat, das sich bis zu einer dieser Root-CAs zurückverfolgen lässt (Zertifikatskette), gilt als vertrauenswürdig. Bekannte CAs: Let’s Encrypt (kostenlos, automatisiert), DigiCert.

Im Detail

CAs bilden eine hierarchische Vertrauensstruktur:

Root-CA (extrem streng geschützter privater Schlüssel, selten direkt genutzt)
  |
  v
Zwischen-CA (signiert im Auftrag der Root-CA)
  |
  v
Server-Zertifikat (z. B. emzett-digital.com, signiert von der Zwischen-CA)

Root-CAs verwenden ihren eigenen, hochsensiblen privaten Schlüssel praktisch nie direkt für alltägliche Server-Zertifikate — der Schlüssel liegt oft physisch getrennt vom Internet (“Air-Gapped”) und wird nur genutzt, um seltener neue Zwischen-CAs zu autorisieren. Diese Zwischen-CAs übernehmen das operative Tagesgeschäft, sodass im (seltenen) Fall eines kompromittierten Zwischenzertifikats nur dieses eine widerrufen werden muss, statt die viel wertvollere Root-CA selbst zu gefährden.

Let’s Encrypt hat die Landschaft seit 2016 grundlegend verändert: Vorher kosteten Zertifikate oft Geld und die Ausstellung war ein manueller, mehrtägiger Prozess — Let’s Encrypt bietet kostenlose, vollautomatisierte Domain-Validation-Zertifikate an, die per Skript (z. B. certbot) alle paar Monate automatisch erneuert werden. Das hat maßgeblich dazu beigetragen, dass HTTPS heute für praktisch jede Website der Standard ist, nicht mehr die Ausnahme für Banken und Shops.

Wird eine CA selbst kompromittiert (z. B. gehackt, oder stellt fälschlich ein Zertifikat für eine fremde Domain aus), verlieren Browser und Betriebssysteme in gravierenden Fällen das Vertrauen in die gesamte CA und entfernen sie aus ihrer vertrauenswürdigen Root-Liste — ein Vorfall, der in der Vergangenheit schon mehrfach ganze CAs faktisch aus dem Geschäft gedrängt hat, weil plötzlich kein Browser mehr ihre Zertifikate akzeptierte.

Wie CAs finanziell funktionieren

Vor Let’s Encrypt finanzierten sich Zertifizierungsstellen fast ausschließlich über direkte Gebühren für ausgestellte Zertifikate, gestaffelt nach Prüftiefe — ein einfaches Domain-Validation-Zertifikat kostete deutlich weniger als ein aufwendig geprüftes Extended-Validation-Zertifikat für eine Bank. Let’s Encrypt finanziert sich dagegen als gemeinnützige Organisation über Spenden großer Technologieunternehmen (u. a. Mozilla, Google, Cisco waren frühe Unterstützer), die ein gemeinsames Interesse an einem verschlüsselten, für jeden zugänglichen Web haben. Kommerzielle CAs existieren weiterhin parallel und differenzieren sich heute vor allem über zusätzliche Dienstleistungen (Support, Garantieleistungen bei Fehlausstellung, höhere Prüfstufen wie Extended Validation), die für Unternehmen mit besonderen Compliance-Anforderungen relevant bleiben, auch wenn die reine technische Verschlüsselung durch ein kostenloses Let’s-Encrypt-Zertifikat genauso stark wäre.

Der Widerruf eines Zertifikats

Muss ein Zertifikat vor Ablauf seiner regulären Gültigkeit ungültig gemacht werden (z. B. weil der zugehörige private Schlüssel gestohlen wurde), stehen CAs zwei Mechanismen zur Verfügung: Certificate Revocation Lists (CRL) sind regelmäßig aktualisierte Listen widerrufener Zertifikate, die Clients herunterladen und abgleichen können. OCSP (Online Certificate Status Protocol) erlaubt stattdessen eine Live-Abfrage direkt bei der CA, ob ein bestimmtes Zertifikat noch gültig ist. Beide Verfahren haben praktische Schwächen — CRLs können durch die Zeit zwischen Aktualisierungen veraltet sein, OCSP-Abfragen verlangsamen jeden Verbindungsaufbau und geben der CA theoretisch Einblick, welche Websites ein Nutzer besucht — moderne Browser setzen deshalb zunehmend auf “OCSP Stapling”, bei dem der Server selbst den aktuellen OCSP-Status direkt mitliefert, ohne dass der Client die CA separat kontaktieren muss.

Siehe auch: Zertifikat, Authentizität