Codesignaturzertifikate

Einführung

Die Codesignierung ist der Prozess, bei dem eine Software, die über das Internet verbreitet werden soll, mit einer digitalen Signatur versehen wird. Sie dient der Überprüfung der Authentizität der Software, d. h. der Herkunft vom ursprünglichen Entwickler, und stellt sicher, dass der Code während der Übertragung nicht von Angreifern manipuliert wurde, beispielsweise durch das Einfügen von Schadcode oder Malware. Die für die Codesignierung verwendete digitale Signatur ist in einem digitalen Zertifikat, dem sogenannten Codesignierungszertifikat, enthalten.

Kurzantwort: Was ist ein Code-Signaturzertifikat?

Ein Codesignaturzertifikat ist ein digitales X.509-Zertifikat, das von einer Zertifizierungsstelle ausgestellt wird und von Softwareherstellern verwendet wird, um ihren Code vor der Veröffentlichung digital zu signieren. Es beweist die Herkunft der Software und bestätigt, dass der Code seit der Signierung nicht verändert wurde. Es gibt selbstsignierte Zertifikate, Zertifikate mit Standardvalidierung (SV) und Zertifikate mit erweiterter Validierung (EV). Durch einen Zeitstempel bleiben sie auch nach Ablauf des Zertifikats gültig, und durch den Widerruf werden kompromittierte Schlüssel ungültig.

Executive Summary

Code-Signatur-Zertifikate ermöglichen Softwareherstellern den Nachweis von Authentizität und Integrität gegenüber Endnutzern, Browsern und Betriebssystemen. Dieser Beitrag erläutert die Unterschiede zwischen Code-Signatur-Zertifikaten und SSL-Zertifikaten anhand des X.509-Schlüsselverwendungsfelds, die herstellerspezifischen Implementierungen (Authenticode, Apple, Java, Adobe AIR), die drei Zertifikatstypen (selbstsigniert, Standardvalidierung und erweiterte Validierung), wie die Zeitstempelung die Vertrauenswürdigkeit signierten Codes auch nach Ablauf des Zertifikats gewährleistet und wie der Zertifikatswiderruf Nutzer schützt, wenn ein privater Schlüssel kompromittiert wurde. Darüber hinaus bietet der Beitrag ein praktisches Glossar und eine Checkliste für die Verwaltung von Code-Signatur-Zertifikaten in großem Umfang und zeigt deren Bedeutung für das umfassendere Zertifikatslebenszyklusmanagement auf.

Für wen sind Code-Signatur-Zertifikate relevant?

Code-Signatur-Zertifikate berühren Software-Release-Engineering, Sicherheitsarchitektur, Plattformbetrieb und Compliance. Im Folgenden wird erläutert, welche Aufgaben die einzelnen Rollen haben.

PKI-Administratoren

Verfolgen Sie den Validierungstyp und das Ablaufdatum jedes Code-Signatur-Zertifikats und stellen Sie sicher, dass jeder signierten Version ein Zeitstempel hinzugefügt wird, damit abgelaufene Zertifikate bereits installierte Software nicht beschädigen.

Sicherheitsarchitekten

Der Schutz privater Schlüssel für Signaturschlüssel sollte auf der Validierungsebene des Zertifikats basieren. Für EV-Codesignaturzertifikate ist ein HSM-gestützter Speicher erforderlich, und dies wird auch für die Standardvalidierung empfohlen.

Plattformteams

Integrieren Sie die Codesignierung in die Build- und Release-Pipeline für jede verwendete Plattform – Windows Authenticode, Apple, Java und Adobe AIR –, damit kein Artefakt unsigniert ausgeliefert wird.

Compliance-Teams

Stellen Sie sicher, dass EV-Codesignaturzertifikate überall dort verwendet werden, wo dies erforderlich ist, und dass die dahinterliegenden privaten Schlüssel den Anforderungen von FIPS 140 Level-2 oder einem gleichwertigen Hardware-Schutz für Prüfungszwecke entsprechen.

CISOS

Behandeln Sie einen kompromittierten Codesignaturschlüssel als einen Vorfall in der Lieferkette, da Angreifer, die einen solchen Schlüssel erlangen, Schadsoftware signieren können, die für jeden nachgelagerten Benutzer legitim erscheint, und veranlassen Sie sofortige Widerrufsprozesse genau für dieses Szenario.

Warum das wichtig ist: Daten und Fristen

Laut der DigiCert Trust Pulse-Umfrage (2. Juli 2025) erlebte fast die Hälfte aller Unternehmen im vergangenen Jahr einen Zertifikatsausfall. 18.5 % der betroffenen Organisationen meldeten Verluste von über 250,000 US-Dollar, wobei 37.5 % dieser Vorfälle direkt auf abgelaufene Zertifikate zurückzuführen waren. Ein abgelaufenes Codesignaturzertifikat ohne Zeitstempel kann unbemerkt alle zuvor verteilten Builds unbrauchbar machen, wodurch dieses Risiko für das Release-Management von direkter Relevanz ist.

Der vom CA/Browser Forum am 11. April 2025 verabschiedete Wahlvorschlag SC-081v3 sieht eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate vor: ab dem 15. März 2026 auf 200 Tage, ab dem 15. März 2027 auf 100 Tage und ab dem 15. März 2029 auf 47 Tage. Obwohl sich dieser Zeitplan auf TLS/SSL-Zertifikate und nicht direkt auf Codesignaturzertifikate bezieht, signalisiert er den branchenweiten Trend zu kürzeren Gültigkeitsdauern und einer stärkeren Zertifikatsautomatisierung, den Codesignaturprogramme berücksichtigen sollten.

Das NIST finalisierte am 13. August 2024 seine Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). Code-Signaturzertifikate basieren auf denselben Public-Key-Signaturalgorithmen, die diese Standards letztendlich ersetzen werden. Daher vermeidet die Integration von Krypto-Agilität in die Signaturinfrastruktur bereits jetzt eine spätere, aufwändige Migration.

Codesignaturzertifikate

Wie alle digitalen Zertifikate basieren auch Codesignaturzertifikate auf dem X.509-Standard und müssen von einer vertrauenswürdigen dritten Partei, beispielsweise einer Zertifizierungsstelle (CA), signiert werden . Codesignaturzertifikate sind jedoch nicht mit anderen Zertifikaten wie SSL- Zertifikaten austauschbar. Der Hauptgrund dafür ist, dass gemäß der X.509-Spezifikation jedes digitale Zertifikat ein Feld „Schlüsselverwendung“ enthält, das den Verwendungszweck des Zertifikats angibt und bei dessen Erstellung ausgefüllt wird. Zusätzliche Informationen zur Verwendung des Zertifikats können in der Erweiterung „Erweiterte Schlüsselverwendung“ enthalten sein. Die X.509-Spezifikation schreibt vor, dass ein Zertifikat nur für seinen vorgesehenen Zweck verwendet werden darf. Beispielsweise ist bei einem SSL-Zertifikat das Feld „Schlüsselverwendung“ auf „Digitale Signatur“ gesetzt, während es bei einem Codesignaturzertifikat auf „Codesignierung“ eingestellt ist.

Während X.509 die Spezifikation für das Zertifikatsformat bereitstellt, variieren die Technologieimplementierungen zur Zertifikatsgenerierung je nach Anbieter. Authenticode beispielsweise ist eine Code-Signing-Technologie von Microsoft, die Entwicklern hilft, Anwendungen für das Windows-Betriebssystem zu signieren. Authenticode-Zertifikate werden zum Signieren von Dateien mit Erweiterungen wie .exe, .dll, .ocx, .cab und .xpi verwendet. Ebenso werden Apple-Code-Signing-Zertifikate zum Signieren von Anwendungen für iOS, Java-Code-Signing-Zertifikate zum Signieren von JAR-Dateien für die Java Runtime Environment (JRE) und Adobe AIR-Zertifikate zum Signieren von .air- oder .airi-Dateien verwendet.

Die Beantragung eines Codesignaturzertifikats ähnelt der anderer digitaler Zertifikate. Jede Organisation, die Software über das Internet veröffentlichen möchte, beantragt ein Codesignaturzertifikat bei einer Zertifizierungsstelle (CA) und übermittelt dazu ihren öffentlichen Schlüssel sowie weitere Organisationsinformationen. Wie bei jedem digitalen Zertifikat muss das öffentliche und private Schlüsselpaar separat generiert werden. Die CA validiert den antragstellenden Entwickler (die Organisation), signiert das Zertifikat als Validierungsnachweis und stellt es dem Entwickler bzw. Softwareherausgeber aus. Das von der CA ausgestellte Zertifikat enthält Informationen wie die Identität des Herausgebers, dessen öffentlichen Schlüssel, die Gültigkeitsdauer, die digitale Signatur der CA und weitere Details.

Arten von Code Signing-Zertifikaten

Selbstsignierte Zertifikate

Softwarehersteller können eigene, selbstsignierte Zertifikate erstellen. In diesem Fall wird jedoch während der Softwareinstallation bei der Signaturprüfung eine Warnung ausgegeben, dass die Software von einem unbekannten Hersteller stammt. Selbstsignierte Zertifikate eignen sich für Tests und die lokale Entwicklung von Software, bevor diese allgemein zugänglich gemacht wird. Sie sollten jedoch nicht für Produktivsoftware verwendet werden, die an Endbenutzer verteilt wird.

Für die öffentliche Softwareverteilung sind von Zertifizierungsstellen ausgestellte Zertifikate die beste Option. Es gibt zwei Arten von von Zertifizierungsstellen ausgestellten Codesignaturzertifikaten, die sich nach der Art der Validierung unterscheiden.

Standardvalidierungszertifikate

Dies ist der Standardtyp des Code Signing-Zertifikats und beinhaltet grundlegende Validierungen des Herausgebers oder Entwicklers durch die Zertifizierungsstelle. Um ein Standard-Code Signing-Zertifikat zu erhalten, müssen Softwareherausgeber einige grundlegende Anforderungen erfüllen, wie z. B. Mindestschlüssellänge, maximale Gültigkeitsdauer und Zeitstempel für digitale Signaturen.

Extended Validation (EV)-Zertifikate

EV-Codesignaturzertifikate erfordern die strengsten Validierungs- und Prüfungsmaßnahmen des Softwareherstellers durch die Zertifizierungsstelle und werden üblicherweise auf einem Hardware-Token ausgestellt, um zusätzliche Sicherheit zu gewährleisten. Um ein EV-Zertifikat zu erhalten, müssen Softwarehersteller neben den grundlegenden Anforderungen für Standardzertifikate deutlich strengere Vorgaben erfüllen – beispielsweise die Speicherung privater Schlüssel in einem Hardware-Sicherheitsmodul (HSM) , das den FIPS-140-Standard (Federal Information Processing Standards) Level-2 oder einen gleichwertigen Standard erfüllt .

Ablauf des Zertifikats und Zeitstempel

Wie jedes digitale Zertifikat verlieren auch Code-Signing-Zertifikate nach Ablauf ihrer Gültigkeitsdauer ihre Gültigkeit. Nach Ablauf ist die Signatur nicht mehr validiert, und die Software lässt sich möglicherweise nicht mehr ordnungsgemäß installieren oder ausführen, obwohl mit der Software selbst alles in Ordnung ist. Dieses Problem wird durch die Zeitstempelung gelöst, bei der der Code zum Zeitpunkt der Signierung der Datei mit einem Zeitstempel versehen wird. Dies geschieht in der Regel durch eine vertrauenswürdige dritte Partei, die sogenannte Time Stamp Authority (TSA), um die Gültigkeit und Authentizität des Zeitstempels zu bestätigen. Der Zeitstempel stellt sicher, dass die Software auch nach Ablauf des Code-Signing-Zertifikats weiterhin ausgeführt wird, sodass der Herausgeber Zeit hat, das Zertifikat zu erneuern.

Widerruf des Zertifikats

Wie wir in früheren Artikeln gesehen haben, hängt die Stärke von Public-Key-Infrastrukturen (PKI) maßgeblich von der Verwaltung und Sicherung der privaten Schlüssel ab. Wird der private Schlüssel eines digitalen Zertifikats kompromittiert, muss das Zertifikat ungültig gemacht oder von der ausstellenden Zertifizierungsstelle (CA) widerrufen werden. Der Zertifikatswiderruf ist im Falle eines Sicherheitsvorfalls von entscheidender Bedeutung: Er stellt sicher, dass Endnutzer gewarnt werden, dass dem Zertifikat nicht mehr vertraut werden kann, und schreckt so vom Herunterladen, Installieren und weiteren Verwenden der Software ab. Der Zertifikatswiderruf erfolgt durch Eintragung des widerrufenen Zertifikats in eine Zertifikatssperrliste (CRL) oder durch Aktualisierung des Zertifikatsstatus mithilfe des Online Certificate Status Protocol (OCSP). Weitere Details zu CRLs und OCSP werden in einem späteren Artikel behandelt.

Glossar für Code-Signatur-Zertifikate

Kurze, leicht verständliche Definitionen der in diesem Beitrag verwendeten Begriffe.

Bedingungen	Definition
Code Signing Certificate	Ein X.509-Digitalzertifikat dient dazu, Software mit einer digitalen Signatur zu versehen und so die Identität des Herausgebers und die Integrität des Codes nachzuweisen.
Schlüsselverwendungsfeld	Ein X.509-Feld, das ein Zertifikat auf seinen vorgesehenen Zweck beschränkt; es ist für Codesignaturzertifikate auf „Code Signing“ und für SSL-Zertifikate auf „Digital Signature“ eingestellt.
Authenticode	Die Codesignaturtechnologie von Microsoft zum Signieren von Windows-Executables, DLLs und Installationsdateien.
Zeitstempelbehörde (TSA)	Eine vertrauenswürdige Drittpartei, die dem signierten Code einen überprüfbaren Zeitstempel hinzufügt und so die Signatur auch nach Ablauf des Zertifikats selbst gültig hält.
Zertifikat für erweiterte Validierung (EV)	Ein Code-Signaturzertifikat, das einer strengsten Überprüfung des Herausgebers bedarf und typischerweise auf einem Hardware-Token oder HSM ausgestellt wird, um maximalen Schlüsselschutz zu gewährleisten.
Zertifikatsperrliste (CRL)	Eine von einer Zertifizierungsstelle veröffentlichte Liste, in der Zertifikate aufgeführt sind, die vor ihrem planmäßigen Ablaufdatum widerrufen wurden.

Checkliste für die Ausstellung von Code-Signaturzertifikaten

Anhand dieser Checkliste können Sie häufige Probleme bei der Codesignierung ihren geschäftlichen Auswirkungen und der Zuständigkeit zuordnen.

Problem	Auswirkungen auf das Geschäft	Empfohlene Maßnahme	Eigentümer
Das Signaturzertifikat erlischt ohne Zeitstempel.	Zuvor verbreitete Software besteht die Signaturprüfung nicht und kann sich daher nicht mehr installieren oder ausführen lassen.	Jede unterzeichnete Freigabe wird mit einem Zeitstempel versehen und das Ablaufdatum der Zertifikate proaktiv überwacht.	PKI-Administrator
Signaturschlüssel ohne Hardwareschutz gespeichert	Ein kompromittierter Schlüssel ermöglicht es einem Angreifer, Schadsoftware zu signieren, die scheinbar von einem vertrauenswürdigen Herausgeber stammt.	Signaturschlüssel hinter einem HSM verlagern, obligatorisch für EV-Zertifikate und empfohlen für alle	Sicherheitsarchitekt
Selbstsigniertes Zertifikat, das in der Produktion verwendet wird	Endnutzer sehen eine Warnung „Unbekannter Herausgeber“, was das Vertrauen und die Akzeptanz beeinträchtigt.	Selbstsignierte Zertifikate sollten auf Entwicklung und Tests beschränkt werden; für Release-Builds sind von einer Zertifizierungsstelle ausgestellte Zertifikate erforderlich.	Plattform-Team
Kompromittierter Schlüssel nicht umgehend widerrufen	Angreifer signieren weiterhin Schadcode, den Endbenutzer als legitimen Code einstufen.	Richten Sie umgehend einen Vorfallprozess ein, um kompromittierte Zertifikate über CRL/OCSP zu widerrufen.	KKV
Der Validierungsgrad stimmte nicht mit den Vertriebsanforderungen überein.	Die Software erfüllt die Vertrauensanforderungen von Drittanbieterplattformen oder Betriebssystemen nicht und blockiert dadurch ihre Verbreitung.	Bestätigen Sie, dass EV-Zertifikate überall dort verwendet werden, wo Plattform- oder Compliance-Richtlinien dies erfordern.	Compliance-Team

Zertifikatslebenszyklusmanagement und PKI-Modernisierung

Code-Signaturzertifikate erfordern dieselbe Sorgfalt bei der Ermittlung, Ausstellung und Erneuerung wie alle anderen Bestandteile eines PKI-Modernisierungsprogramms . CertSecure Manager automatisiert die Ermittlung, Ausstellung und Erneuerung von Zertifikaten, einschließlich der automatischen Zeitstempelung und Ablaufverfolgung, sodass kein Signaturzertifikat unbemerkt abläuft.

Organisationen, die Zertifikate in großem Umfang ausstellen, ohne die Infrastruktur vollständig intern zu betreiben, können auf PKI-as-a-Service als verwaltete, Cloud-basierte Zertifizierungsstelle zurückgreifen. Die Erstellung eines Maschinenidentitätsinventars und die Zertifikatserkennung mit CBOM Secure helfen, alle bereits in Build- und Release-Pipelines verwendeten Signaturzertifikate zu ermitteln. Eine PQC-Readiness -Bewertung stellt sicher, dass Ihre Signaturinfrastruktur einen Migrationspfad hin zu kryptografischer Agilität und Post-Quanten-Signaturalgorithmen aufweist. Das PQC Center of Excellence von Encryption Consulting bietet Unterstützung bei der Planung dieser Migration.

Weitere Informationen darüber, warum die Zertifikatsautomatisierung in der gesamten IT-Umgebung wichtig ist, finden Sie in unseren Artikeln im Schulungszentrum zu den Phasen im Lebenszyklus eines Zertifikats und zur Vermeidung von Zertifikatsausfällen . Spezielle Inhalte zum Thema Codesignierung finden Sie unter: Codesignierung: Die 5 wichtigsten Vorteile , Codesignierung: Die 5 besten Vorgehensweisen , Codesignierung: Mögliche Risiken , Architektur der Codesignierung und Zeitstempelung von Codesignierungszertifikaten – Bedeutung.

Erfolgsmessung und laufende Audits

Verfolgen Sie den Anteil der Code-Signaturzertifikate mit aktiviertem Zeitstempel, den Anteil der durch hardwaregestütztes Schlüsselmanagement geschützten Signaturschlüssel und die Geschwindigkeit, mit der ein kompromittiertes Zertifikat nach seiner Erkennung widerrufen werden kann. Überprüfen Sie regelmäßig, vierteljährlich, die Bestände an Signaturzertifikaten und die Ablaufübersichten, um Richtlinien wie Validierungsanforderungen und Empfehlungen von Zertifizierungsstellen/Browser-Foren zu berücksichtigen. Prüfen Sie außerdem kontinuierlich den Zertifikatsablauf, damit Signaturzertifikate niemals unbemerkt mitten im Release-Zyklus ablaufen.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis zum Thema Code-Signaturzertifikate?

Ein Code-Signaturzertifikat beweist die Authentizität und Integrität von Software mittels einer digitalen X.509-Signatur. Es ist auf einen Zeitstempel angewiesen, um nach Ablauf der Gültigkeit vertrauenswürdig zu bleiben, und auf den Widerruf, um einem kompromittierten Schlüssel nicht mehr zu vertrauen.

Warum ist das für PKI-Teams in Unternehmen wichtig?

PKI-Teams müssen für jeden Signierungsanwendungsfall die richtige Validierungsstufe auswählen und sicherstellen, dass jede Freigabe mit einem Zeitstempel versehen wird, da ein ungestempeltes Zertifikat, das abläuft, bereits installierte Software im gesamten System unbrauchbar machen kann.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Verwaltung von Codesignaturzertifikaten erhöht das Risiko, unsignierte oder ungestempelte Builds auszuliefern, Signaturschlüssel ohne Hardwareschutz zu speichern und den Ablauf eines Zertifikats zu verpassen, was zu Funktionsstörungen der verteilten Software führt.

Welche Teams sollten für diese Änderung verantwortlich sein?

Sicherheitsarchitekten entwerfen Schlüsselschutz für Signaturschlüssel, Plattformteams integrieren die Signatur in Build-Pipelines, PKI-Administratoren überwachen Zertifikatvalidierungstypen und Ablaufdaten, und Compliance-Teams bestätigen die EV-Nutzung, wo dies erforderlich ist.

Wie hängt das mit dem Zertifikatslebenszyklusmanagement zusammen?

Für Code-Signaturzertifikate gelten die gleichen Regeln für Erkennung, Ausstellung, Verlängerung und Widerruf wie für alle anderen Zertifikatstypen; die Einbeziehung in ein einheitliches Zertifikatslebenszyklusmanagementprogramm verhindert, dass ein Signaturzertifikat übersehen wird.

Wie sollten Organisationen ihren Erfolg messen?

Verfolgen Sie den Prozentsatz der Signaturzertifikate mit aktivierter Zeitstempelung, den Prozentsatz der Signaturschlüssel mit hardwaregestütztem Schutz und wie schnell ein kompromittiertes Zertifikat nach seiner Erkennung widerrufen werden kann.

Was sollte regelmäßig geprüft oder überwacht werden?

Überprüfen Sie regelmäßig das Verzeichnis der Code-Signaturzertifikate und das Ablauf-Dashboard, stellen Sie sicher, dass jeder Version ein Zeitstempel hinzugefügt wird, und vergewissern Sie sich, dass die Signaturschlüssel in einem hardwaregestützten Speicher verbleiben.

Welche Auswirkungen hat dieses Thema auf Cloud-, Hybrid- oder Multi-CA-PKI?

Organisationen, die Code über mehrere Plattformen und Zertifizierungsstellen hinweg signieren, benötigen eine zentrale Übersicht über jedes verwendete Signaturzertifikat, da ein Zertifikat einer nicht nachverfolgten Zertifizierungsstelle genauso gut unbemerkt mitten im Release-Zyklus ablaufen kann.

Welche häufigen Fehler sollten Teams vermeiden?

Zu den häufigsten Fehlern gehören die Auslieferung von Produktionssoftware mit einem selbstsignierten Zertifikat, das Auslassen der Zeitstempelung, die Speicherung von Signaturschlüsseln ohne Hardwareschutz und die Verzögerung des Widerrufs nach einer Schlüsselkompromittierung.

Was sollte vierteljährlich aktualisiert werden?

Überprüfen Sie die Anforderungen an die Validierungsebene im Hinblick auf die aktuelle Plattform und die Compliance-Richtlinien, stellen Sie sicher, dass die Signaturzertifikate weiterhin den aktuellen CA/Browser Forum-Richtlinien entsprechen, und vergewissern Sie sich erneut, dass die Schlüsselschutzmethoden auch bei steigendem Signaturvolumen noch angemessen sind.