Ein Umzug in eine andere Netzwerkzone, eine Registrierungsfunktion, die dort nichts zu suchen hatte, und eine Fehleinschätzung: Daraus ist bei der Zertifizierungsstelle (CA) DigiCert ein Datenleck geworden. Ein Unbekannter legte sich im Sommer ein Konto auf einem internen Geschäftssystem an und las darüber archivierte Kundendaten, bei einem kleinen Teil der Kunden auch Kopien von Führerscheinen, Reisepässen oder Versorgerrechnungen. DigiCert hat den Vorfall im Bugtracker von Mozilla offengelegt, über den CAs den Root-Programmen von Browser- und Betriebssystemherstellern Vorfälle melden. Inzwischen verschickt das Unternehmen Benachrichtigungen an Kunden.

Was passiert ist

Laut dem vollständigen Vorfallbericht, den DigiCert am 1. November veröffentlicht hat, wurde das betroffene System am 4. Februar 2025 im Zuge einer Infrastruktur-Migration aus einem nur per VPN erreichbaren Netzsegment in eine andere Availability Zone verschoben. Dadurch war es unbeabsichtigt von außen erreichbar. Das System nutzt einen Account-Manager, den DigiCert auch für Kundenprodukte einsetzt. Dessen Selbstregistrierung, eigentlich für andere Anwendungen gedacht, stand damit auch für das interne System offen. So angelegte Konten unterlagen nicht der Mehrfaktor-Authentifizierung, die DigiCert sonst verlangt, und erhielten standardmäßig Lesezugriff. Weil das Berechtigungsmodell keine Selbstregistrierung vorsah, konnten sie auch ohne zugewiesene Anwendung archivierte Daten abrufen.

Am 18. Juni 2026 bemerkte ein internes Team fremde Konten auf dem System. Es schloss aus der fehlenden Anwendungszuordnung jedoch, dass diese keinen Datenzugriff hätten, und stellte das System hinter eine Web Application Firewall. Drei Tage später ging über DigiCerts Programm für externe Sicherheitsforscher der Hinweis ein, dass sich von außen Konten anlegen ließen. Am 2. Juli spielte DigiCert einen Fix ein, der Konten ohne zugewiesene Anwendung abweist. Dass zu diesem Zeitpunkt bereits Daten abgeflossen waren, bemerkte das Unternehmen erst Monate später: Am 12. Oktober kam der Verdacht auf, am 19. Oktober bestätigte DigiCert den Zugriff. Nach Auswertung von Dateizugriffen und Anfragevolumen lag das Zugriffsfenster zwischen dem 27. Juni und dem 2. Juli 2026. DigiCert räumt im Bericht ein, der Vorfall sei zunächst als Problem bei der Kontoerstellung behandelt worden statt als Datenzugriff.

Welche Daten betroffen sind und welche nicht

Der Großteil der abgerufenen Datensätze enthielt laut DigiCert geschäftliche Kontaktdaten: Namen, geschäftliche E-Mail-Adressen, Telefonnummern und Geschäftsadressen. Bei einer „kleinen Minderheit“ der Kundenkonten lagen zusätzlich vom Kunden eingereichte Dokumente mit Name und Adresse, etwa Führerschein, Reisepass oder eine Versorgerrechnung. Laut BleepingComputer prüft DigiCert noch, wessen Ausweisdokumente betroffen sind, und will diese Personen nach Abschluss der Prüfung informieren. Wie viele Kunden betroffen sind, hat DigiCert nicht veröffentlicht. Ein Teilnehmer im Bugzilla-Thread fragte am Donnerstag ausdrücklich nach Zahlen; eine Antwort stand bei Redaktionsschluss aus.

Die Zertifikatsinfrastruktur selbst war laut DigiCert nicht betroffen. Der Zugriff war rein lesend; das Konto konnte weder Datensätze ändern noch Validierungen freigeben oder Zertifikate ausstellen. Die CA-Systeme laufen in eigenen Netzsegmenten, und die Auswertung der Logs ergab nach Angaben des Unternehmens keine Validierungs-, Ausstellungs- oder Sperraktivität dieses Kontos. CertCentral, DigiCert ONE, Kunden-Logins und ausgestellte Zertifikate seien sicher; bei aktiven Zertifikaten müssten Kunden nichts unternehmen. Von privaten Schlüsseln ist im Bericht keine Rede. Bei TLS-Zertifikaten erzeugt sie üblicherweise der Kunde selbst und reicht bei der CA nur einen Certificate Signing Request (CSR) ein.

Gang zwischen Serverschränken in einem Rechenzentrum (Symbolbild)

Bild: Kaltgang im Rechenzentrum des Technologiezentrums Písek (Symbolbild) – Foto: Eclipse55 / Wikimedia Commons, CC BY-SA 4.0

Warum eine CA Ausweiskopien archiviert

Dass eine Zertifizierungsstelle Pässe und Führerscheine vorhält, ist kein Versehen, sondern Vorgabe. Für domainvalidierte TLS-Zertifikate genügt der Nachweis, dass der Antragsteller die Domain kontrolliert. Zertifikate, die eine Identität bestätigen, also organisationsvalidierte (OV), Extended-Validation- (EV) und Code-Signing-Zertifikate, setzen dagegen voraus, dass die CA prüft, wer hinter dem Antrag steht. Die Baseline Requirements des CA/Browser Forum für Code-Signing-Zertifikate verlangen bei Privatpersonen eine lesbare Kopie eines gültigen amtlichen Lichtbildausweises wie Reisepass, Führerschein oder Personalausweis. Dazu kommt etwa ein Foto des Antragstellers mit dem Ausweis in der Hand oder eine Prüfung per Videoanruf. Für den Adressnachweis lassen die Regeln unter anderem Versorgerrechnungen und Kontoauszüge zu. Bei EV-Code-Signing-Zertifikaten für bestimmte Unternehmensformen muss eine verantwortliche Person ihren Ausweis zudem persönlich vor einem Notar, Anwalt, Wirtschaftsprüfer oder Mitarbeiter der CA vorlegen.

Zugleich verpflichten dieselben Regeln die CAs, alle Unterlagen zur Prüfung, Ausstellung und Sperrung von Zertifikaten zu archivieren, und zwar mindestens zwei Jahre über die letzte Verwendung oder den Ablauf der darauf beruhenden Zertifikate hinaus. Eine CA sammelt so zwangsläufig über Jahre einen Bestand an Identitätsnachweisen, und genau solche Archivdaten waren hier betroffen. DigiCert verweist im eigenen Bericht auf zwei weitere aktuelle Vorfälle rund um Archivdaten bei anderen CAs: einen unbefugten Zugriff auf einen Server der Registrierungsstelle beim taiwanischen Anbieter TWCA und den Verlust archivierter Registrierungsunterlagen für S/MIME-Zertifikate bei einer externen Registrierungsstelle der deutschen CA D-Trust.

Nicht der erste Vorfall

Erst im April hatte DigiCert einen Sicherheitsvorfall melden müssen. Ein Angreifer schickte damals über den Kunden-Chat eine als Screenshot getarnte Schadsoftware an den Support, infizierte zwei Rechner und griff über das interne Support-Portal Initialisierungscodes für bereits genehmigte EV-Code-Signing-Bestellungen ab. DigiCert widerrief daraufhin 60 Zertifikate, 27 davon ordnete die CA direkt dem Angreifer zu; einige waren zum Signieren von Malware verwendet worden. Mit dem aktuellen Leck hat das technisch nichts zu tun. Gleiches gilt für die Massensperrung im Sommer 2024: Damals musste DigiCert wegen eines Fehlers bei der DNS-basierten Domainvalidierung mehr als 83.000 Zertifikate von rund 6.800 Kunden kurzfristig widerrufen.

Was du jetzt tun solltest

Die größte unmittelbare Gefahr ist gezieltes Phishing. Wer Name, Telefonnummer und Firmenadresse eines Zertifikatsverantwortlichen kennt und weiß, dass dessen Firma bei DigiCert bestellt, kann glaubwürdige Mails über angeblich ablaufende, gesperrte oder neu zu validierende Zertifikate verschicken.

  • Keinen Links aus Mails folgen: Bestellungen, Validierungen und Verlängerungen nur direkt im CertCentral-Konto prüfen, nicht über Links oder Rückrufnummern aus E-Mails. DigiCert betont, dass bei aktiven Zertifikaten kein Handlungsbedarf besteht. Wer zu eiligem Handeln gedrängt wird, sollte misstrauisch werden.
  • Konten absichern: Auch wenn die Logins laut DigiCert nicht betroffen sind, lohnt ein Blick auf die Kontoverwaltung: Mehrfaktor-Anmeldung für alle Nutzer aktivieren, berechtigte Nutzer und API-Schlüssel durchsehen.
  • Ausstellung überwachen: Über die Certificate-Transparency-Logs fällt auf, wenn jemand für deine Domains Zertifikate erhält. CAA-Einträge im DNS legen fest, welche CAs überhaupt ausstellen dürfen.
  • Bei Ausweiskopien wachsam bleiben: Wer erfährt, dass ein eigenes Ausweisdokument betroffen ist, sollte auf unerwartete Verträge, Kontoeröffnungen oder Inkassoschreiben achten. Eine kostenlose Datenkopie nach Art. 15 DSGVO bei Auskunfteien wie der Schufa zeigt, ob Unbekanntes eingetragen wurde.
  • Intern informieren: Benachrichtigt werden die bei DigiCert hinterlegten Personen. Unternehmen sollten klären, wessen Daten und Dokumente sie der CA in den vergangenen Jahren übermittelt haben, und diese Kollegen informieren.

CAA-Einträge und CT-Logs lassen sich schnell auf der Kommandozeile prüfen:

# Welche CAs dürfen für die Domain ausstellen?
dig +short CAA example.com

# Zuletzt in Certificate-Transparency-Logs erfasste Zertifikate (über crt.sh)
curl -s "https://crt.sh/?q=example.com&output=json" \
  | jq -r '.[] | "\(.not_before)  \(.issuer_name)"' | sort -r | head -n 20

Quellen

Bildnachweis