Vorabprüfung des Zertifikats mit pkilint und zlint

Die Zertifikatsprüfung vor der Ausstellung überprüft ein zu signierendes Zertifikat anhand von RFC 5280, den CA/Browser Forum Baseline Requirements und den geltenden Profilregeln, bevor es signiert wird. Hierfür werden Open-Source-Tools wie pkilint und zlint verwendet. Da ein fehlerhaft ausgestelltes Zertifikat innerhalb von nur 24 Stunden widerrufen werden muss, ist das Erkennen von Profilfehlern vor der Signierung mittlerweile eine betriebliche Notwendigkeit und keine bloße Best Practice mehr. Dies gilt insbesondere, da die immer kürzeren Gültigkeitsdauern von Zertifikaten das Ausstellungsvolumen stark ansteigen lassen.

Ein Zertifikat ist eine kleine, starre Datenstruktur, die umfangreichen Regeln unterliegt: RFC 5280, die CA/Browser Forum Baseline Requirements, profilspezifische Richtlinien und die Richtlinien jedes Root-Programms, das ihm vertraut. Ist ein Feld fehlerhaft, eine Dateiendung fehlt, der Name falsch oder ein Wert außerhalb der Richtlinien, ist das Zertifikat nicht nur fehlerhaft, sondern gemäß den Branchenregeln fälschlicherweise ausgestellt. Fälschlicherweise ausgestellte Zertifikate müssen innerhalb kürzester Zeit widerrufen werden. Certificate Linting ist die automatische Überprüfung eines Zertifikats anhand dieser Regeln, während Pre-Issuing Linting es prüft, bevor es signiert wird. Der Unterschied zwischen den beiden Verfahren ist vergleichbar mit dem Unterschied zwischen dem Beheben eines Fehlers und der Entschuldigung dafür.

Dieser Artikel erklärt, warum die Vorabprüfung von Zertifikaten (Pre-Issues Linting) bis 2026 von einer guten Hygienemaßnahme zu einer betrieblichen Notwendigkeit geworden ist, wie die Open-Source-Linter pkilint und zlint funktionieren, welche Kosten ein einzelnes fehlerhaftes Profil verursachen kann, wenn es zu einer Massensperrung führt, und wie Linting in den Veröffentlichungsprozess integriert werden kann, um Profilfehler zu erkennen, bevor es zu einer Sperrung und damit verbundenen rechtlichen Auseinandersetzungen kommt. Die These ist einfach: Bei den heutigen Veröffentlichungsvolumina ist Prävention die einzig wirtschaftliche Maßnahme, und die Vorabprüfung von Zertifikaten (Pre-Issues Linting) ist der Ort, an dem Prävention stattfindet.

Wichtige Erkenntnisse

• Die Vorabprüfung (Pre-Issue Linting) überprüft ein Zertifikat anhand von RFC 5280, den Baseline Requirements und den entsprechenden Profilen, bevor es signiert wird. Dadurch wird ein Fehler verhindert, anstatt im Nachhinein einen Widerruf auszulösen.
• Ein irrtümlich ausgestelltes Zertifikat kann gemäß Abschnitt 4.9.1.1 der Basisanforderungen innerhalb von 24 Stunden widerrufen werden. Deshalb ist Vorbeugung besser als Entdeckung.
• zlint und pkilint sind die beiden dominierenden Open-Source-Linter, und ausgereifte Ausgabepipelines verwenden beide, da sich ihre Regelabdeckung unterscheidet.
• Die vom CA/Browser Forum vorgeschlagene schrittweise Verkürzung der Gültigkeitsdauer um 200, 100 und 47 Tage verachtfacht das Ausstellungsvolumen um etwa das Achtfache, von rund 1,000 Verlängerungen pro Jahr auf über 8,000, wodurch sowohl die Wahrscheinlichkeit als auch die Auswirkungen eines Fehlers im Zusammenhang mit einem gemeinsam genutzten Profil steigen.
• Die Teams für PKI, Sicherheit, Plattform und Compliance sind jeweils für eine bestimmte Aufgabe zuständig; die untenstehende Verantwortlichkeits-/Aufgabenmatrix und Entscheidungstabelle zeigen genau, was und wer dafür verantwortlich ist.

Direkt zu: Zusammenfassung | Checkliste | Entscheidungstabelle | Verantwortlichkeits-/Aktionsmatrix | Nächste Schritte | FAQ

Zusammenfassung für die Teams PKI, Sicherheit, Plattform und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die in diesem Artikel unterstützte Entscheidung und die entsprechende Kurzanleitung.

• PKI-Teams: Bestätigen Sie, dass die Vorabprüfung mit zlint und pkilint als Fail-Closed-Gateway auf jedem Ausgabepfad ausgeführt wird und dass jedes Profil vor der Veröffentlichung geprüft wird.
• Sicherheitsteams: Verstehen Sie die 24-Stunden-Frist für den Widerruf, die ein abfangbarer Linting-Fehler auslösen kann, und bestätigen Sie, dass kein Ausstellungspfad die Kontrollinstanz umgeht.
• Plattform-/DevOps-Teams: Wire Linting wird als Build-Time-Check in CI/CD integriert, analog zur Sicherheitsprüfung des Codes vor der Bereitstellung.
• Compliance-Teams: Es muss sichergestellt werden, dass die Aufzeichnungen über die Faserprüfung und den Lagerbestand als revisionssichere Nachweise für die Einhaltung der Basisanforderungen aufbewahrt werden.

Kurzcheckliste zur Einsatzbereitschaft

Nutzen Sie diese Checkliste, um zu beurteilen, ob Ihre Emissionspipeline tatsächlich geschützt ist und nicht nur das Risiko kennt.

• Die vor der Ausstellung durchgeführte Prüfung (Pre-Issue Linting) erfolgt nach dem Prinzip „Fail-Closed Gate“, sodass ein Zertifikat, das die Prüfung nicht besteht, niemals signiert wird.
• Es wurde überprüft, ob sowohl zlint als auch pkilint in diesem Gate ausgeführt werden, und die Vereinigung ihrer Ergebnisse blockiert die Ausgabe.
• Es wurde sichergestellt, dass jedes Profil vor der Massenausgabe durch Linting geprüft wird, sobald es erstellt oder geändert wird.
• Die bestätigte Nachprüfung der Protokolle und die stichprobenartigen CT-Protokollprüfungen nach der Veröffentlichung dienen als Sicherheitsnetz und nicht als primäre Kontrollmaßnahme.
• Die Vorgehensweise zur Ermittlung des Geltungsbereichs, zur Benachrichtigung der Eigentümer und zur Neuausstellung der Zertifikate wurde innerhalb eines 24-Stunden-Fensters geübt.

Warum ist das jetzt wichtig?

Drei Faktoren machen die Vorabprüfung von Zertifikaten dringlich. Die Gültigkeitsdauer von Zertifikaten verkürzt sich, während das Ausgabevolumen steigt; fehlerhaft ausgestellte Zertifikate können innerhalb weniger Stunden widerrufen werden; und die teuersten Fehler der letzten Zeit lassen sich auf Profilfehler zurückführen, die ein Linter erkannt hätte. Zusammengenommen machen diese Faktoren die Vorabprüfung von einer reinen Hygienemaßnahme zu einer operativen Kontrollmaßnahme.

Kürzere Laufzeiten bedeuten ein deutlich höheres Emissionsvolumen

Die schrittweise Reduzierung der Gültigkeitsdauer von TLS-Zertifikaten durch das CA/Browser Forum – beginnend mit maximal 200 Tagen im März 2026 und bis zu 47 Tagen im Jahr 2029 – führt zu einer Vervielfachung des Ausstellungsvolumens. Derselbe Zertifikatsbestand, der bisher etwa 1,000 Verlängerungen pro Jahr generierte, wird im Rahmen der 47-Tage-Regelung über 8,000 Verlängerungen jährlich verursachen. Jede dieser Ausstellungen durchläuft dieselbe Profillogik, sodass ein einzelner Konfigurationsfehler kein Einzelfall ist, sondern sich auf jedes von diesem Profil erzeugte Zertifikat auswirkt.

Jede einzelne dieser Zertifikatsausstellungen birgt das Risiko, dass ein Profilfehler unentdeckt bleibt, und bei diesem Volumen breitet sich ein Fehler in einem gemeinsam genutzten Profil schnell aus. Ein höherer Durchsatz erhöht sowohl die Wahrscheinlichkeit als auch die Auswirkungen eines fehlerhaften Zertifikats. Zudem verkürzt er die Zeitspanne, die zur Erkennung eines systemischen Fehlers zur Verfügung steht, bevor dieser sich über das gesamte Profil ausbreitet.

Laut der am 2. Juli 2025 veröffentlichten DigiCert Trust Pulse Survey gaben 45 % der Unternehmen an, im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten erlebt zu haben. 37.5 % dieser Unternehmen konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen . Jede dieser Verlängerungen durchläuft erneut dieselbe Profillogik . Je häufiger die Zertifikate verlängert werden, desto mehr Zertifikate können von einem einzelnen Profilfehler betroffen sein, bevor er entdeckt wird.

Der vom CA/Browser Forum verabschiedete Wahlvorschlag SC-081v3 , der am 14. April 2025 angenommen wurde, sieht eine schrittweise Verlängerung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate von derzeit 398 Tagen auf 200 Tage (März 2026), 100 Tage (März 2027) und 47 Tage (März 2029) vor. Dies ist der vollständige Zeitplan, der der oben beschriebenen Erhöhung des Ausstellungsvolumens zugrunde liegt.

Bei einer Fehlausstellung gilt eine 24-Stunden-Frist für den Widerruf.

Die Folgen eines ungültigen Zertifikats sind in den Basisanforderungen definiert. Abschnitt 4.9.1.1 legt die Widerrufsfristen fest: In manchen Fällen muss der Widerruf innerhalb von 24 Stunden erfolgen, in anderen Fällen innerhalb von bis zu 5 Tagen. Diese Fristen gelten unabhängig davon, ob es sich um einen einzelnen Zertifikatswiderruf oder einen Massenwiderruf handelt.

Ein Linting-Fehler fällt eindeutig in den Geltungsbereich: Wird ein Problem gemeldet, das durch Linting hätte erkannt werden können oder sollen, handelt es sich eher um einen Designfehler als um ein extern gemeldetes Problem. Daher beginnt in diesem Fall die 24-Stunden-Frist. Es bleibt kaum Zeit zu reagieren, weshalb Prävention wichtiger ist als Erkennung. Eine Sicherheitsmaßnahme, die ein ungültiges Zertifikat vor der Signierung blockiert, beseitigt die Frist vollständig, da keine nicht vertrauenswürdigen Zertifikate ausgestellt werden.

Die warnenden Beispiele sind aktuell und kostspielig.

Zwei Ereignisse verdeutlichen die Brisanz der Situation. Im Juli 2024 kündigte DigiCert die erzwungene Aufhebung von 83,267 Zertifikaten an, die an 6,807 Kunden ausgestellt worden waren. Den Kunden wurde eine Frist von 24 Stunden eingeräumt, um die Zertifikate zu ersetzen, nachdem festgestellt worden war, dass bei einigen CNAME-basierten Domainvalidierungen ein Unterstrich als Präfix fehlte. Die Folgen waren so gravierend, dass ein betroffener Kunde, das Technologieunternehmen Alegeus für das Gesundheitswesen, DigiCert verklagte und eine einstweilige Verfügung erwirkte, die die Aufhebung der Zertifikate vorerst aussetzte. Unabhängig davon trug die fehlerhafte Ausstellung von mehr als 26,000 EV-TLS-Zertifikaten durch Entrust, verbunden mit einer schleppenden Behebung der Mängel, dazu bei, dass Google Chrome nach dem 31. Oktober 2024 beschloss, Entrust-TLS-Zertifikaten nicht mehr zu vertrauen. Profil- und Validierungsfehler sind keine theoretischen Probleme; sie haben Massenaufhebungen, Rechtsstreitigkeiten und den Verlust des Vertrauensstatus einer Zertifizierungsstelle zur Folge.

Wie funktioniert das Linting?

Bevor wir uns damit befassen, wo Linting in einer Pipeline seinen Platz hat, ist es hilfreich zu verstehen, was ein Linter leistet, wie sich diese Vorgehensweise zum Branchenstandard entwickelt hat und welche Tools am weitesten verbreitet sind. Die folgenden Abschnitte erläutern, was Linting-Prüfungen sind, wie sie aus Certificate Transparency hervorgegangen sind, die beiden Open-Source-Linter, auf die die meisten Teams setzen, und den entscheidenden Unterschied zwischen der Prüfung eines Zertifikats vor und nach dessen Signierung.

Was Linting-Prüfungen

Linting ist der Prozess der statischen Analyse von Quellcode, um Muster zu erkennen, die zu Fehlern führen könnten. Angewendet auf Zertifikate, analysiert es jedes einzelne anhand der TLS-Basisanforderungen, der EV-Richtlinien und gegebenenfalls RFC 5280.

Ein Linter analysiert ein Zertifikat und wertet Hunderte von Regeln aus: erforderliche und verbotene Erweiterungen, Namenskodierung, Konsistenz der Schlüsselverwendung und der erweiterten Schlüsselverwendung, Gültigkeitsdauer, Entropie der Seriennummer sowie die zahlreichen strukturellen Einschränkungen der Standards. Er kodiert Tausende von Einzelprüfungen, die auf RFC 5280, den Baseline Requirements und Root-Programmprofilen basieren. Der Linter gibt Fehler, Warnungen und Hinweise zurück, sodass der Aussteller ein nicht konformes Zertifikat korrigieren oder ablehnen kann. Da die Regeln zahlreich sind und häufig aktualisiert werden, kann ein menschlicher Prüfer sie nicht zuverlässig in Ausstellungsgeschwindigkeit anwenden. Genau deshalb muss die Prüfung automatisiert werden.

Wie das Entfernen von Fusseln zur Standardpraxis wurde

Linting entstand aus der Zertifikatstransparenz. Nachdem Zertifizierungsstellen (CAs) verpflichtet wurden, Zertifikate in öffentlichen CT-Protokollen zu protokollieren, konnten Tools wie crt.sh jedes protokollierte Zertifikat analysieren. Die Linting-Ergebnisse von Anfang 2016 deckten weit verbreitete Fehler und Warnungen in den Zertifikaten nahezu aller CAs auf – eine Art öffentliche Anprangerung. Entscheidend ist, dass Linting von der CA direkt auf ihr eigenes, noch zu signierendes Zertifikat oder CT-Vorzertifikat angewendet werden kann. Dadurch kann die CA entweder die Ausstellung eines nicht konformen Zertifikats verhindern oder es kurz danach erkennen. Die erste Option, die Prävention vor der Signierung, ist das Pre-Issue-Linting. Es verlagert die Prüfung von einer öffentlichen Überprüfung bereits ausgestellter Zertifikate zu einer internen Kontrolle zukünftiger Zertifikate.

pkilint und zlint

Zwei Open-Source-Linter dominieren den Markt: zlint (im Rahmen des zmap-Projekts) und pkilint (von DigiCert). Sie sind die beiden am weitesten verbreiteten Linter, neben älteren Tools wie certlint und dem manuellen lintcert-Dienstprogramm. zlint ist unter github.com/zmap/zlint und pkilint unter github.com/digicert/pkilint zu finden.

Sie unterscheiden sich in Implementierung und Regelabdeckung, weshalb ausgereifte Zertifikatsverarbeitungs-Pipelines oft mehrere Linter gleichzeitig verwenden: zlint ist ein weit verbreiteter, Go-basierter Linter mit umfassender Abdeckung der Baseline Requirements und RFC 5280, während pkilint ein Python-basiertes Framework mit tiefgreifender, profilbasierter Prüfung verschiedener Zertifikatstypen, einschließlich S/MIME und anderer Profile, ist. Die gleichzeitige Verwendung beider Linter erhöht die Wahrscheinlichkeit, dass ein Fehler vor der Signierung erkannt wird. In der Praxis ist die Profilbasierung von pkilint besonders für Nicht-Web-Zertifikatstypen wertvoll, während die Reife und Geschwindigkeit von zlint für die Ausstellung von Webzertifikaten mit hohem Durchsatz geeignet sind.

Linting vor versus nach der Emission

Diese Unterscheidung ist betrieblich wichtig. Die Vorabprüfung (Pre-Issueslinging) des zu signierenden Zertifikats führt zu einer einfachen Verhinderung der Ausstellung, ohne dass Schaden entsteht. Die Nachprüfung (Post-Issueslinging) erfolgt im Nachhinein, beispielsweise als Stichprobe, zur Kompensation oder beim Testen neuer Linter-Regeln.

Diese Unterscheidung ist für die Widerrufsfrist relevant: Ein Fehler bei der Vorabprüfung, der ein erkennbares Problem durchlässt, stellt einen Designfehler dar, der die 24-Stunden-Frist auslöst. Fehler nach der Veröffentlichung hingegen ähneln eher extern gemeldeten Problemen, da die Prüfrichtlinie noch nicht optimiert ist und untersucht werden muss. Die Lehre daraus: Die Vorabprüfung dient der Schadensverhütung; die Nachprüfung ist ein Sicherheitsnetz, kein Ersatz. Wird dieses Sicherheitsnetz als primäre Kontrollmaßnahme behandelt, gelangen erkennbare Fehler überhaupt erst in die Produktion.

Risiken und Fallstricke

Sowohl das Fehlen als auch die unsachgemäße Anwendung von Linting bergen Risiken. Die folgende Tabelle zeigt die häufigsten Fehlerursachen, die einen Profilfehler zu einem Geschäftsvorfall führen, sowie die jeweilige Ursache und wahrscheinliche Folge.

Risiko	Verursachen	Folge
Massenaufhebung	Ein fehlerhaftes, gemeinsam genutztes Profil wurde in großer Menge ausgegeben.	Innerhalb von 24 Stunden wurden Tausende von Zertifikaten widerrufen.
Rechtsstreitigkeiten und Stromausfälle	Kunden können Zertifikate nicht rechtzeitig ersetzen.	Unterlassungsverfügungen, Stromausfälle und Reputationsschäden.
Verlust des CA-Vertrauens	Wiederholte Fehlausstellungen und schleppende Korrekturmaßnahmen.	Root-Programme misstrauen der Zertifizierungsstelle und erklären daher alle ihre Zertifikate für ungültig.
Falsches Vertrauen	Sich ausschließlich auf die Linting-Prüfung nach der Veröffentlichung zu verlassen.	Die Defekte gelangen in die Produktion, bevor sie entdeckt werden.
Linter-Totwinkel	Ein einzelner Linter übersieht eine Regel, die ein anderer erkennen würde.	Bemerkbare Mängel gelangen in die Veröffentlichung.
Profildrift	Neue Profile oder Regeländerungen sind ungetestet.	Eine zuvor gültige Ausstellung entspricht nun nicht mehr den Vorschriften.

Der Fehler liegt im Profil, nicht im Zertifikat.

Ein entscheidender Punkt ist, dass Massensperrungen von Zertifikaten in der Regel auf einen Fehler in einem Profil oder einer Ausstellungskonfiguration zurückzuführen sind, der viele Zertifikate betrifft, und nicht auf einen einmaligen Fehler. Der Fall DigiCert verdeutlicht dies genau: Das Fehlen des Unterstrichpräfixes war eine Eigenschaft eines Validierungspfads und betraf etwa 0.4 Prozent der relevanten Domänenvalidierungen bei Zehntausenden von Zertifikaten.

Ein einzelner Profilfehler wirkt sich auf die gesamte Zertifikatspopulation aus, die von diesem Profil betroffen ist. Die Vorabprüfung (Pre-Issuing Linting) erkennt den Fehler im ersten Zertifikat, bevor das Profil Tausende weitere Zertifikate ausgestellt hat. Dies ist das entscheidende wirtschaftliche Argument für die Kontrolle: Die Kosten für die Erkennung eines Fehlers skalieren mit einem einzelnen Zertifikat, während die Kosten für dessen Übersehen mit der gesamten Profilpopulation skalieren.

Selbst disziplinierte Wirtschaftsprüfer haben mit der Logistik zu kämpfen.

Bei einem Massenwiderruf gestaltet sich die fristgerechte Durchführung schwierig. Im Fall DigiCert hatte die Zertifizierungsstelle Probleme, die betroffenen und bereits ersetzten Zertifikate zu identifizieren. Erschwerend kam hinzu, dass viele Kunden die automatisierte Zertifikatsverwaltung nicht umfassend nutzten, was einen schnellen Austausch sehr aufwendig machte. Prävention bei der Ausstellung vermeidet dieses ganze Chaos. Ein Fehler, der nie signiert wird, führt weder zu einem Widerruf noch zu einer Kundenbenachrichtigung oder einem Wettlauf gegen die 24-Stunden-Frist.

Best Practices für die Implementierung

Effektives Linting bedeutet, die richtige Prüfung an der richtigen Stelle im Prozess zu platzieren. Die folgenden Vorgehensweisen beginnen mit der wichtigsten Kontrollmaßnahme, dem Linting vor der Unterzeichnung, und umfassen anschließend die Bestandsaufnahme und die Proben, die alle Fehler enthalten, die beim ersten Kontrollschritt übersehen werden.

1. Vor dem Unterschreiben immer fusseln: Führen Sie vor der Ausstellung eine Prüfung des zu signierenden Zertifikats oder des CT-Vorzertifikats durch und konfigurieren Sie die Ausstellung so, dass sie fehlschlägt: Meldet die Prüfung einen Fehler, wird das Zertifikat nicht signiert. Diese Maßnahme verhindert Schaden, anstatt ihn aufzudecken. CertSecure Manager Diese Sicherheitsmaßnahme wird standardmäßig bei jeder Ausgabe erzwungen, sodass ein Ausfallschutzverhalten eingebaut ist und nicht von jeder Pipeline manuell eingerichtet werden muss.
2. Führen Sie mehrere Linter gleichzeitig aus: Verwenden Sie sowohl zlint als auch pkilint, da sich deren Regelabdeckung unterscheidet und der eine häufig Fehler erkennt, die der andere übersieht. Behandeln Sie die Summe ihrer Fehler als Blockierungsbedingung. Die zusätzlichen Kosten für die Ausführung eines zweiten Linters sind im Vergleich zu den Kosten eines einzelnen übersehenen Fehlers vernachlässigbar. Da beide Linter innerhalb des Ausgabegates ausgeführt werden, blockiert die Summe ihrer Fehler die Signierung ohne zusätzlichen Integrationsaufwand.
3. Prüfen Sie das Profil, nicht nur das Zertifikat: Da Massensperrungsfehler ihren Ursprung in Profilen und der Ausstellungskonfiguration haben, sollten repräsentative Zertifikate aus jedem Profil geprüft werden, sobald ein Profil erstellt oder geändert wird, bevor es in großem Umfang ausgestellt wird.
4. Halten Sie Linter und Regelsätze aktuell: Die Basisanforderungen, die Richtlinien des Stammprogramms und die Profilvorgaben ändern sich; aktualisieren Sie die Linter-Versionen und Regelkonfigurationen, damit die heutige konforme Ausgabe auch morgen noch konform ist.
5. Die nachträgliche Überprüfung nach der Veröffentlichung sollte als Sicherheitsnetz und nicht als Ersatz dienen: Führen Sie weiterhin Stichproben bei ausgestellten und CT-protokollierten Zertifikaten durch, um etwaige Fehler der Vorabprüfung aufzudecken und neue Regeln zu validieren. Verlassen Sie sich jedoch niemals darauf als primäres Kontrollinstrument.
6. Linting mit Automatisierung und Inventarisierung kombinieren: Da kürzere Gültigkeitsdauern das Volumen erhöhen, ist es wichtig, dass abhängige Systeme im Falle eines Widerrufs schnell neue Zertifikate ausstellen können. Zudem sollte ein Verzeichnis geführt werden, das jedes Zertifikat seinem Inhaber und Profil zuordnet, sodass der Umfang innerhalb von Minuten statt Tagen ermittelt werden kann. Ein aktuelles Verzeichnis wandelt einen Widerrufsauftrag in eine Arbeitsliste statt in eine Untersuchung um. Genau das bietet es: die automatisierte Erneuerung über alle Ihre Zertifizierungsstellen hinweg sowie ein zentrales Verzeichnis, das jedes Zertifikat seinem Inhaber und Profil zuordnet.
7. Üben Sie eine Antwort auf einen Widerruf: Selbst bei einer gründlichen Vorabprüfung sollten Sie planen und testen, wie Sie den Umfang ermitteln, die Verantwortlichen benachrichtigen und innerhalb von 24 Stunden eine Neuveröffentlichung durchführen, damit ein verbleibender Vorfall eingedämmt und nicht zu Chaos führt.

Was bedeutet das für Sicherheitsteams?

Die Prüfung vor der Ausstellung von Zertifikaten ist nicht nur ein Anliegen der PKI; sie betrifft jedes Team, das Zertifikate ausstellt, verwendet oder darauf reagiert. Die Verantwortlichkeiten variieren je nach Rolle, aber die immer kürzer werdende Gültigkeitsdauer erhöht den Druck für alle.

• PKI-Teams Sie besitzen die Emissionspipeline und die Profile, in denen Fehler entstehen, und sind die Hauptverantwortlichen für das Pre-Issues-Linting. CertSecure Manager Bietet ihnen eine zentrale Anlaufstelle, um die Linting-Gateways durchzusetzen und Profile über alle Zertifizierungsstellen hinweg, sowohl öffentliche als auch private, zu verwalten.
• Jeder, der eine private CA betreibt birgt das gleiche Risiko auf interner Ebene und profitiert von Linting, obwohl private Zertifikate außerhalb der Regeln des öffentlichen Stammprogramms liegen, da ein fehlerhaftes internes Zertifikat immer noch mTLS unterbrechen oder einen Dienst lahmlegen kann.
• DevSecOps-Teams Die Integration der automatisierten Zertifikatsausstellung in Pipelines sollte Linting als Build-Time-Gateway behandeln, analog zur Sicherheitsprüfung von Code, und den Build fehlschlagen lassen, wenn ein Zertifikat nicht bestanden würde. Dank der ACME- und REST-API-Integrationen lässt sich dieses Gate direkt in bestehende CI/CD-Pipelines einbinden.
• CISOS die Folgen eines Massenwiderrufs mit sich bringen, einschließlich Ausfallzeiten, Rechtsstreitigkeiten und im schlimmsten Fall des vollständigen Verlusts des Vertrauens in CA.
• Compliance- und Audit-Teams Das System nutzt Linting als dokumentierten Nachweis dafür, dass die Ausgabe die Basisanforderungen und relevanten Profile erfüllt, und dient als wiederholbare, automatisierte Prüfung anstelle einer manuellen Überprüfung. Es erfasst diese Nachweise zentral und wandelt die Auditvorbereitung in einen Bericht statt in ein hektisches Durcheinander um.

Wie kann Verschlüsselungsberatung helfen?

Um fehlerhafte Profile vor der Unterzeichnung zu erkennen und seltene Fehler zu überstehen, reichen Open-Source-Linter, die in ein Skript integriert sind, nicht aus. Es bedarf einer Plattform, die bei jeder Ausstellung eine Linting-Prüfung durchführt, eine aktuelle Liste der bereits ausgestellten Dokumente führt und bei Bedarf sofort eine große Anzahl von Dokumenten neu ausstellen kann, falls ein Widerruf erforderlich ist.

Genau dafür wurde unser CertSecure Manager entwickelt. Unsere Plattform für das Zertifikatslebenszyklusmanagement führt vor der Ausstellung eine konsistente, fehlerfreie Prüfung aller Profile durch. So wird ein fehlerhaftes Zertifikat blockiert, bevor es überhaupt signiert wird, anstatt erst später in einem CT-Protokoll entdeckt zu werden. Da sich die Regelabdeckung je nach Linter unterscheidet, werden in dieser Prüfung sowohl zlint als auch pkilint ausgeführt. Die Summe ihrer Ergebnisse wird als Blockierung gewertet. Zudem werden repräsentative Zertifikate bei jeder Profilerstellung oder -änderung geprüft, um Fehler im Profil zu erkennen, bevor sie sich massenhaft auswirken. Die Plattform verwaltet ein zentrales Inventar, das jedes Zertifikat seinem Besitzer, Profil und abhängigen Systemen zuordnet. Dadurch kann ein Widerrufsauftrag innerhalb von Minuten statt Tagen erteilt werden.

Hinter dem Gate hält es die Linter-Regelsätze aktuell, während sich die Baseline Requirements und die Richtlinien des Root-Programms weiterentwickeln. Es überprüft stichprobenartig CT-protokollierte Zertifikate als zusätzliche Sicherheitsmaßnahme nach der Ausstellung und protokolliert jede Prüfung als revisionssicheren Nachweis. Zudem automatisiert es die Erneuerung und Neuausstellung über Ihre öffentlichen und privaten Zertifizierungsstellen hinweg, sodass die kurzen Gültigkeitsdauern, die dieses hohe Volumen bedingen, niemals zu Ausfällen führen. Dank der ACME- und REST-Integrationen gelten dieselben Kontrollen unabhängig davon, ob ein Zertifikat über eine CI/CD-Pipeline oder eine traditionelle PKI ausgestellt wird.

Dieselbe Disziplin erstreckt sich über Zertifikate hinaus. Unsere CBOM Secure- Plattform führt dieselbe Zertifikatserkennung für die gesamte kryptografische Infrastruktur eines Unternehmens durch, und unser Leitfaden „CBOM: Vom Inventar zur Intelligenz “ beschreibt, wie Sie dieses Inventar in ein kontinuierliches Programm umwandeln. Da die Zertifikatsautomatisierung im CertSecure Manager CA-unabhängig ist, trägt dieselbe Linting- und Inventarisierungsdisziplin, die heute Massensperrungen verhindert, auch zur Agilität von Krypto- Teams bei, die für den Übergang nach der Quantencomputer-Ära erforderlich ist. Unser 9-phasiger PQC-Readiness -Plan und unser PQC Center of Excellence unterstützen Sie bei der Planung dieser Migration parallel zu den oben beschriebenen Maßnahmen zur Zertifikatsverwaltung.

Das Prinzip der Plattform entspricht dem, für das dieser Artikel plädiert: Die konforme Ausstellung von Zertifikaten in großem Umfang ist eine systematische Vorgehensweise, keine manuelle Prüfung. Führen Sie vor der Signierung eine Linting-Prüfung durch, automatisieren Sie die Verlängerung und kennen Sie Ihren Zertifikatsbestand, damit ein einzelnes fehlerhaftes Profil bereits beim ersten Zertifikat erkannt wird und nicht erst bei Tausenden von Zertifikaten entdeckt wird. Um den aktuellen Stand Ihrer Ausstellungspipeline zu ermitteln, sprechen Sie mit Encryption Consulting über eine Bewertung Ihrer Zertifikats- und Ausstellungs-Governance.

Entscheidungs- und Checklistentabelle nach Anwendungsfall

Anhand dieser Tabelle können Sie Ihre Situation der empfohlenen Kontrollmaßnahme zuordnen, dem Verantwortlichen und den Kriterien für ein erfolgreiches Ergebnis.

Luftüberwachung	Software Empfehlungen	Betriebsinhaber	Erwartetes Ergebnis
Neue CA oder Profil wird live geschaltet	Lint-Repräsentantenzertifikate aus dem Profil, bevor es in großem Umfang ausgestellt wird	PKI-Team	Ein Profilfehler wird beim ersten Zertifikat entdeckt, nicht erst nach der Ausstellung Tausender Zertifikate.
Öffentliche TLS-Ausgabe in großem Umfang gemäß dem 200/100/47-Tage-Zeitplan	Führen Sie vor der Veröffentlichung eine Vorabprüfung als fehlersichere Kontrollinstanz bei jeder Veröffentlichung durch.	PKI-Team / Platform-DevOps	Da kein nicht konformes Zertifikat unterzeichnet wird, beginnt die 24-Stunden-Frist für den Widerruf nicht.
Nicht-Web-Zertifikatstypen, einschließlich S/MIME- und privater PKI-Profile	Führen Sie pkilint zusammen mit zlint für eine profilbasierte Abdeckung aus.	PKI-Team	Profilspezifische Regeln, die ein webbasierter Linter allein übersehen würde, werden dennoch erfasst.
CI/CD oder automatisierte Ausgabepipelines	Linting sollte als Kontrollmechanismus zur Build-Zeit betrachtet werden, ähnlich wie Code auf Sicherheitslücken überprüft wird.	DevSecOps	Ein Zertifikat, das die Linting-Prüfung nicht besteht, führt zu einem Build-Fehler, bevor die Produktionsumgebung erreicht wird.
Vorbereitung auf Audits oder Compliance-Prüfungen	Bewahren Sie die Ergebnisse der Fusselprüfung und die Bestandsaufzeichnungen als dokumentierte Nachweise auf.	Compliance/Audit	Auditfertige Nachweise für die Einhaltung der Basisanforderungen ohne manuellen Aufwand
Notfallplanung für Massenwiderrufe	Üben Sie die Identifizierung des Geltungsbereichs, die Benachrichtigung und die Neuausstellung innerhalb von 24 Stunden.	CISO / Sicherheitsleitung	Ein Restvorfall ist eine abgeschlossene Aufgabenliste und kein öffentlicher Vorfall.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI-Team	Besitzt die Emissionspipeline, Profile und die Vorabprüfung vor der Emission.	Erzwingen Sie bei jeder Ausgabe eine ausfallsichere Lint-Prüfung und prüfen Sie jedes Profil vor der Veröffentlichung.
Sicherheits Team	Bestätigt, dass Linting-Fehler nicht umgangen werden können, und versteht den Radius der Widerrufsmöglichkeit.	Prüfen Sie die Ergebnisse der Informationsprüfung bei jeder Profiländerung und stellen Sie sicher, dass kein Ausgabepfad die Kontrollstelle überspringt.
Plattform-/DevOps-Team	Verantwortlich für die Integration von Wire Linting in CI/CD- und automatisierte Ausgabeprozesse.	Der Build schlägt fehl, wenn ein zu signierendes Zertifikat die Linting-Prüfung nicht besteht.
Compliance-/Audit-Team	Besitzt Nachweise dafür, dass die Ausstellung die Basisanforderungen und Profilregeln erfüllt.	Bewahren Sie die Aufzeichnungen über die Fusselbildung und den Lagerbestand in jedem Zyklus als revisionssichere Nachweise auf.

Was macht man als nächstes

• PKI-Teams: Bestätigen Sie, dass sowohl zlint als auch pkilint heute als Fail-Closed-Gate ausgeführt werden, und kennzeichnen Sie jedes Profil, das seit seiner letzten Änderung nicht gelintet wurde.
• Sicherheitsteams: Es muss bestätigt werden, dass kein Ausgabeweg, einschließlich Notfall- oder manueller Ausgabe, die Linting-Gateway umgehen kann.
• Plattformteams: Sicherstellen, dass CI/CD-Pipelines den Build abbrechen, wenn ein Zertifikat die Linting-Prüfung nicht besteht, und nicht nur eine Warnung protokollieren.
• Compliance-Teams: Stellen Sie sicher, dass Ihr nächstes Audit Linting- und Inventaraufzeichnungen als Beweismittel vorlegen kann und nicht nur eine Grundsatzerklärung darstellt.

Weiterführende Lektüre von Encryption Consulting

• Stärkere Sicherheit durch TLS-Zertifikate mit 47-tägiger Gültigkeit bis 2029 umfasst den gesamten Gültigkeitspfad des CA/Browser-Forums, auf den in diesem Beitrag verwiesen wird.
• CBOM: Von der Bestandsaufnahme zur intelligenten Analyse umfasst die Umwandlung kryptografischer Erkennung in ein fortlaufendes Programm, das über Zertifikate hinausgeht.
• PQC Kompetenzzentrum behandelt die Planung der Post-Quantum-Migration im Zusammenhang mit Zertifikatsverwaltungsaufgaben wie dieser.

Fazit

Zertifikate sind von Natur aus unnachgiebig, und die geltenden Regeln sehen eine Widerrufsfrist von wenigen Stunden vor. Da die Gültigkeitsdauer von Zertifikaten immer kürzer wird und das Ausstellungsvolumen bis 2026 und darüber hinaus stetig steigt, erhöht sich die Wahrscheinlichkeit, dass ein fehlerhaftes Profil in den Produktivbetrieb gelangt. Damit steigt auch das Risiko eines Massenwiderrufs, wie er bereits zu 83,000 widerrufenen Zertifikaten, Kundenklagen und einem tiefen Vertrauensverlust gegenüber einer ganzen Zertifizierungsstelle geführt hat. Die Vorabprüfung mit pkilint und zlint verhindert, dass ein fehlerhaftes Profil überhaupt erst signiert wird. Sie ist kostengünstig, automatisierbar und bietet eine Ausfallsicherung, indem sie ein nicht konformes Zertifikat blockiert, anstatt eines auszustellen, das später widerrufen werden muss.

Vor der Signierung prüfen; mehrere Linter einsetzen; jedes Profil vor der Massenausstellung prüfen; und die Prüfung nach der Ausstellung nur als Sicherheitsmaßnahme durchführen. Diese Maßnahme mit automatisiertem Lebenszyklusmanagement und einem kryptografischen Inventar kombinieren , um verbleibende Vorfälle innerhalb der Frist einzudämmen und Ausfälle zu vermeiden. Ziel ist eine Pipeline, in der fehlerhafte Profile nicht signiert werden können und die seltene Ausnahme eine begrenzte Arbeitsliste anstelle eines öffentlichen Vorfalls darstellt. Die Kosten eines Linters in der Pipeline sind gering; die Kosten der dadurch verhinderten Massensperrungen hingegen nicht.

Dieser Leitfaden dient als Erläuterung von Vorgehensweisen und Werkzeugen und wird alle sechs Monate sowie sofort aktualisiert, sobald das CA/Browser Forum eine neue Abstimmung zur Gültigkeit von Zertifikaten durchführt oder zlint oder pkilint eine größere Regeländerung veröffentlichen.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Pre-Issues Certificate Linting mit pkilint und zlint?

Die Vorabprüfung von Zertifikaten anhand von RFC 5280, den CA/Browser Forum Baseline Requirements und den entsprechenden Profilregeln wird vor der Signierung durchgeführt. Dadurch wird ein Fehler verhindert, anstatt im Nachhinein innerhalb von 24 Stunden eine Massensperrung auszulösen. Die Standardpraxis, die dies verhindert, besteht darin, bei jeder Zertifikatsausstellung sowohl zlint als auch pkilint als abschließende Sicherheitsmaßnahme auszuführen und jedes Profil vor der Ausstellung in großem Umfang zu prüfen.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig?

Ein einzelnes fehlerhaftes Profil kann sich auf alle ausgestellten Zertifikate auswirken, und Abschnitt 4.9.1.1 der Basisanforderungen sieht lediglich 24 Stunden für den Widerruf vor, sobald ein erkennbarer Fehler entdeckt wird. Der Widerruf von 83,267 Zertifikaten durch DigiCert und der Verlust des Chrome-Vertrauens von Entrust lassen sich beide auf Profil- und Validierungsfehler zurückführen, die durch die Vorabprüfung vor der Signierung erkannt werden sollen.

Welche Teams sind für die Umsetzung dieser Richtlinien verantwortlich?

PKI-Teams verantworten die Ausgabepipeline und die Profile, in denen Fehler auftreten, und sind primär für die Vorabprüfung vor der Ausgabe zuständig. DevSecOps-Teams integrieren diese Prüfung als Build-Time-Check in CI/CD-Pipelines; CISOs tragen die Konsequenzen eines Massensperrereignisses; und Compliance- und Audit-Teams verlassen sich auf die Prüfung als dokumentierten, reproduzierbaren Nachweis der Einhaltung der Basisanforderungen.

Welche Risiken erhöhen sich, wenn dies manuell gehandhabt wird?

Ohne ein automatisiertes, fehlersicheres Linting-Gate kann ein fehlerhaftes Profil massenhaft Zertifikate ausstellen, bevor es bemerkt wird. So kann ein einmaliger Konfigurationsfehler zu einer Massensperrung führen. Die manuelle Nachverfolgung erschwert zudem die schnelle Ermittlung des Umfangs eines Fehlers, was genau das logistische Problem darstellt, das die Sperrung von DigiCert im Jahr 2024 erschwert hat.

Wie reduziert Automatisierung das Risiko von Zertifikatsausfällen?

Die automatisierte Vorabprüfung blockiert nicht konforme Zertifikate, bevor sie signiert werden. So gelangen keine nicht vertrauenswürdigen Zertifikate in die Produktion und die 24-Stunden-Frist für den Widerruf beginnt gar nicht erst. In Kombination mit automatisiertem Zertifikatslebenszyklusmanagement und einem zentralen Inventar bedeutet dies außerdem, dass im Falle eines Widerrufs ein Ersatzzertifikat innerhalb von Minuten und nicht wie bei manchen DigiCert-Kunden ohne automatische Verlängerung erst nach Tagen bereitgestellt werden kann.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen?

Erfassen Sie den Prozentsatz der Emissionen, die die kombinierte Zlint- und Pkilint-Prüfung beim ersten Versuch bestehen, die Anzahl der vor jedem Go-Live geprüften Profile, die Zeit bis zur Behebung von vor der Veröffentlichung gefundenen Linting-Fehlern sowie alle nach der Veröffentlichung festgestellten Fehler, die vor der Veröffentlichung hätten erkannt werden müssen. Berichten Sie diese Daten zusammen mit der Zertifikatsbestandsabdeckung vierteljährlich.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Der Vorschlag SC-081v3 des CA/Browser Forums sieht eine schrittweise Verlängerung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate von 200 Tagen (März 2026) über 100 Tage (März 2027) auf 47 Tage (März 2029) vor. Dies entspricht einer etwa achtfachen Erhöhung der Erneuerungshäufigkeit und vervielfacht die Anzahl der Zertifikate, die jährlich denselben Profilierungsprozess durchlaufen. Aufgrund dieses Anstiegs ist die Vorabprüfung (Pre-Issuing Linting), die Profilfehler bereits beim ersten Zertifikat und nicht erst nach der Ausstellung Tausender Zertifikate erkennt, eine operative Notwendigkeit und nicht nur eine wünschenswerte Funktion.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Wenden Sie dieselbe Vorabprüfung (Pre-Issues Linting) mit zlint und pkilint einheitlich auf allen Zertifizierungsstellen, Cloud-Umgebungen und On-Premises-Installationen an, anstatt sie nur in einer Umgebung zu erzwingen und in einer anderen unkontrolliert zu lassen. Eine teilweise Einführung führt genau zu der Profil-Linting-Lücke, die die Vorabprüfung eigentlich schließen soll – beschränkt auf die jeweils priorisierte Umgebung.