Skip to content

Hochsicheres Certificate-Transparency-Monitoring mit Red Sift Certificates

Erfahren Sie, wie Sie mit Certificate-Transparency-Monitoring nicht autorisierte Zertifikatsausstellungen erkennen. Richten Sie CAA-Richtlinien, CT-Monitoring-Regeln und hochsichere Eskalation in Red Sift Certificates ein.

Bhushan Lokhande·Principal Software Engineer
Published: May 1, 2026·6 min read

Öffentliche PKI und digitale Zertifikate bieten für die meisten Internetpräsenzen eine akzeptable Grundlage, aber manche bergen ein deutlich höheres Risiko als andere. Bereiche wie Ihre Anwendungs-Login-Seite, Zahlungsabläufe, Unternehmensdomains und alles, was Ihrer Marke schaden könnte, wenn es imitiert wird, sind bevorzugte Ziele für Angreifer. Diese Bereiche müssen aktiv geschützt werden, indem Abwehrmaßnahmen mit Technologien wie Certificate Transparency (CT) und CAA aufgebaut werden. Da wir bereits ausführlich auf High-Assurance CT eingegangen sind, wollten wir uns hier auf die praktischen Aspekte der Erkennung nicht autorisierter Ausstellungen, der Anwendung verfügbarer Präventionsmechanismen und der Konfiguration von hochsicherem Monitoring mit Red Sift Certificates konzentrieren.

Was ist Certificate Transparency?

Certificate Transparency (CT) ist ein offener Standard, der öffentlich vertrauenswürdige Zertifizierungsstellen (Certificate Authorities, CAs) dazu verpflichtet, jedes von ihnen ausgestellte Zertifikat in öffentlich prüfbaren, nur anhängbaren Protokollen zu erfassen. Dadurch ist jedes für Ihre Domain ausgestellte Zertifikat für jeden sichtbar.

CT wurde entwickelt, um eine grundlegende Schwäche der öffentlichen PKI zu beheben: Jede CA im Trust Store kann technisch gesehen ein Zertifikat für jede beliebige Domain ausstellen. CT verhindert dies nicht, macht aber nicht autorisierte Ausstellungen erkennbar. Red Sift erfasst und verarbeitet CT-Protokolle seit 2017 und hat damit einen der umfassendsten verfügbaren Datenspeicher zur Zertifikatserkennung aufgebaut.

Ausfälle der öffentlichen PKI sind keine reine Theorie – werfen Sie einen Blick auf unsere Übersicht historischer Angriffe auf öffentliche PKIs, die durch CT und CAA hätten erkannt werden können.

Mehr erfahren

Ebene 1: Beginnen Sie mit einer grundlegenden CAA-Richtlinie

Die erste Verteidigungslinie ist die Prävention, und diese beginnt mit einer DNS-CAA-Richtlinie (Certification Authority Authorization). Eine CAA-Richtlinie ermöglicht es Ihnen festzulegen, welche CAs Zertifikate für Ihre Domain ausstellen dürfen. Ohne eine solche Richtlinie kann jede CA ein Zertifikat für Ihre Bereiche ausstellen. Bereits eine grundlegende CAA-Konfiguration reduziert Ihre Angriffsfläche erheblich.

Empfohlene Grundeinstellung: Grundlegende CAA-Richtlinie mit Standard-CT-Monitoring-Einstellungen.

Definieren einer CAA-Richtlinie. Richten wir nun eine CAA-Richtlinie mit Red Sift Certificates ein. Bevor Sie etwas festlegen, finden Sie heraus, wer aktuell für Ihre Domains ausstellt. Andernfalls könnte ein neuer Eintrag die rechtmäßige Ausstellung über Nacht unterbrechen. Die Issuer-Facette auf der Zertifikate-Seite zeigt dies sofort an. Filtert man beispielsweise nach „Hostnamen enthält redsift.com“, erhält man Let's Encrypt (114), Google Trust Services (34), Sectigo (24) und Amazon (4).

cas_for_domaincas_for_domain
Filtern von Zertifikaten nach Aussteller in Red Sift Certificates

Diese Liste lässt sich direkt in eine CAA-Richtlinie übersetzen, die Sie in Ihrem DNS-Eintrag einrichten müssen:

redsift.com.  CAA  0  issue      "letsencrypt.org"
redsift.com.  CAA  0  issue      "pki.goog"
redsift.com.  CAA  0  issue      "sectigo.com"
redsift.com.  CAA  0  issue      "amazon.com"
redsift.com.  CAA  0  issuewild  "letsencrypt.org"
redsift.com.  CAA  0  issuewild  "pki.goog"
redsift.com.  CAA  0  issuewild  "sectigo.com"
redsift.com.  CAA  0  iodef      "mailto:security@redsift.com"

issue deckt reguläre Zertifikate ab, issuewild deckt Wildcard-Zertifikate ab. Beschränken Sie die Wildcard-Liste auf die CAs, die Sie tatsächlich für Wildcard-Ausstellungen nutzen; der Filter „Wildcard“ in Red Sift Certificates zeigt in Kombination mit einem „Hostnamen“-Filter Ihre aktuelle Wildcard-Nutzung. Benötigen Sie Hilfe bei den Identifier-Domains? Mit diesem CAA-Generator können Sie die korrekte Identifier-Domain für jede CA nachschlagen.

CAs sind verpflichtet, CAA-Einträge vor der Ausstellung zu prüfen und zu beachten. Sollte ein entdecktes Zertifikat gegen Ihre CAA-Richtlinie verstoßen, kennzeichnet Red Sift Certificates das CAA-Konfigurationsproblem (zum Beispiel einen fehlerhaften CAA-Eintrag oder eine fehlende Eigenschaft) und sendet Ihnen zur Sichtbarkeit eine Benachrichtigung.

CT monitoring snapshotCT monitoring snapshot
CAA IssuesCAA Issues
Nach CAA-Kategorie gefilterte Probleme

Ebene 2: Einrichten des CT-Monitorings

CAA verhindert, dass regelkonforme CAs nicht autorisierte Zertifikate ausstellen, stoppt jedoch keine kompromittierte oder betrügerische CA. CT-Monitoring ist die Methode, mit der Sie erkennen, was CAA nicht verhindern kann.

Red Sift Certificates überwacht CT-Protokolle kontinuierlich und erstellt für jedes neu entdeckte Zertifikat, das zu Ihren Domains passt, einen Fall. Jeder Fall wird automatisch anhand einer Reihe von Abschluss- und Eskalationsregeln bewertet, um festzustellen, ob das Zertifikat rechtmäßig, unerwartet oder ein potenzieller Hinweis auf eine Kompromittierung ist.

Abschlussregeln

Abschlussregeln lösen Fälle automatisch auf, wenn ausreichend Belege dafür vorliegen, dass das Zertifikat rechtmäßig ist:

CT monitoringCT monitoring
Abschlussregeln in Red Sift Certificates

Abschlussregeln

Regel

Hinweise

Zertifikat ist bestätigt (als bekannt markiert)

Wird ausgelöst, wenn ein Zertifikat über eine CA-Integration importiert oder über die API markiert wird. Diese Zertifikate stehen garantiert unter Ihrer Kontrolle, weshalb die Fälle sofort geschlossen werden.

Zertifikat ist auf Ihren Hosts installiert

Bestätigt durch aktive Host-Beobachtung

Zertifikat ist abgelaufen

Verhindert, dass historische Zertifikate die Warteschlange überfüllen

Zertifikat ist widerrufen

Schließt Fälle für Zertifikate, die von der ausstellenden CA widerrufen wurden und nicht mehr nutzbar sind

CAA-Richtlinie stimmt mit Zertifikatsaussteller überein

Bestätigt, dass die CA zur Ausstellung berechtigt war. Gilt nur für Hostnamen mit vorhandenem CAA-Eintrag

Aussteller stimmt mit bekannten Schlüsselwörtern überein

Schließt Fälle, bei denen der Ausstellername mit einer vertrauenswürdigen Schlüsselwortliste übereinstimmt.

Fall ist seit N Tagen ohne Eskalation offen

Schließt automatisch veraltete Fälle, die keine Eskalationsregel ausgelöst haben. Empfohlen: 30 Tage.

Ebene 3: Hochsicheres CT-Monitoring

Standard-CT-Monitoring kennzeichnet Anomalien reaktiv. Hochsicheres CT-Monitoring verfolgt einen strengeren Ansatz: Es erstellt ein vollständiges Inventar aller Zertifikate, die Sie besitzen, und behandelt standardmäßig alles in CT-Protokollen, das nicht in diesem Inventar enthalten ist, als verdächtig.

Dafür sind zwei Dinge erforderlich:

  1. Ein vollständiges „bekannt-gut“-Inventar. Aufgebaut durch den Import von Zertifikaten über CA-Integrationen oder die Create-Certificate-API. Jedes importierte Zertifikat wird automatisch als bestätigt markiert (bekanntermaßen unter Ihrer Kontrolle).
  2. Strikte Eskalationsregeln. Konfiguriert, um jedes Zertifikat zu eskalieren, das innerhalb eines kurzen Zeitfensters nicht erfasst wurde.
CT monitoring escalation rulesCT monitoring escalation rules
Eskalationsregeln in Red Sift Certificates

Eskalationsregeln

Regel

Hinweise

Zertifikat wurde nicht innerhalb von X Tagen bestätigt

Kernregel für hochsicheres Monitoring. Empfohlen: 1–3 Tage (Standard ist 30). Optional nur auf besonders wichtige Domains beschränken.

Zertifikat wurde nicht als auf Hosts installiert erkannt

Erkennt Zertifikate, die ausgestellt, aber nie bereitgestellt wurden. Empfohlen: 30 Tage.

CAA-Richtlinie stimmt nicht mit Zertifikatsaussteller überein

Weist auf eine Ausstellung außerhalb Ihrer zulässigen CA-Richtlinie hin. Mit Vorsicht verwenden.

Zertifikat ist nicht CT-konform

Kann auf eine nicht standardmäßige Ausstellung oder ein außerhalb normaler CA-Workflows eingereichtes Zertifikat hinweisen

Zertifikatsaussteller steht nicht auf der Liste zulässiger CAs

Erfordert die Definition einer expliziten Positivliste vertrauenswürdiger Aussteller

Aussteller stimmt mit verdächtigen Schlüsselwörtern überein

Z. B. unbekannte CA-Namen, interne/Test-CAs, bekanntermaßen riskante Aussteller

Zertifikat überschreitet die maximale Gültigkeitsdauer

Kennzeichnet Richtlinienverstöße, z. B. eine Gültigkeit von über 200 Tagen

Hinweis: CT-Protokolle haben eine inhärente Merge-Verzögerung, die bei manchen Protokollen bis zu 24 Stunden betragen kann. Red Sift verarbeitet Zertifikate, sobald sie in CT-Protokollen erscheinen, nahezu in Echtzeit, jedoch nicht sofort.

Alles zusammengeführt

Certificate Transparency verwandelt ein unsichtbares Risiko – dass jede CA für jede Domain ausstellen kann – in ein öffentlich prüfbares Signal. Doch rohe CT-Daten sind unübersichtlich; um daraus ein zuverlässiges Frühwarnsystem zu machen, braucht es ein bekannt-gutes Inventar, sinnvolle Abschlussregeln und strikte Eskalationsschwellen.

Red Sift Certificates vereint diese drei Ebenen an einem Ort: Durchsetzung der CAA-Richtlinie, kontinuierliches CT-Monitoring und hochsichere Eskalation, gestützt auf nahezu ein Jahrzehnt CT-Protokollerfassung. Beginnen Sie mit der empfohlenen Grundeinstellung und verschärfen Sie die Eskalationsregeln für Ihre wichtigsten Domains, sobald Ihr bekannt-gutes Inventar reift.

Bereit loszulegen? Melden Sie sich für eine Red Sift Certificates Lite-Testversion an oder loggen Sie sich ein, um hochsicheres CT-Monitoring für Ihre Domains einzurichten, falls Sie bereits ein Konto haben.

Kostenlose Testversion anfordern
Bhushan Lokhande
Bhushan Lokhande
Principal Software Engineer

Bhushan is the leading Principal Engineer for Red Sift's Certificate products and innovation.