Die Gültigkeitsdauer von Code-Signatur-Zertifikaten verkürzt sich auf 460 Tage.

Die Gültigkeitsdauer eines Codesignaturzertifikats gibt die maximale Anzahl an Tagen an, die ein öffentlich vertrauenswürdiges Codesignaturzertifikat gültig sein kann, bevor es erneuert werden muss. Seit dem 1. März 2026 wurde diese Frist auf 460 Tage verkürzt, im Vergleich zu den 39 Monaten, auf die sich Teams jahrelang verlassen haben. Diese Regelung stammt aus dem CA/Browser Forum Ballot CSC-31 (verabschiedet am 17. November 2025, Veröffentlichung der Code Signing Baseline Requirements v3.10.0), der Gruppe von Zertifizierungsstellen und Browserherstellern, die die Regeln für jedes öffentliche Zertifikat festlegt. Dieser Blogbeitrag erklärt die Änderungen, die Funktionsweise von Signatur und Zeitstempelung, den Speicherort für private Schlüssel und wie Sie sich optimal vorbereiten, ohne in letzter Minute in Hektik zu geraten.

Die Einhaltung der 460-Tage-Regel für Codesignaturen ist wie folgt definiert: Jedes öffentlich vertrauenswürdige Codesignaturzertifikat, das am oder nach dem 1. März 2026 ausgestellt wird, muss innerhalb seiner maximalen Gültigkeitsdauer von 460 Tagen bleiben. Dies umfasst einen getesteten Widerrufsprozess, die obligatorische Zeitstempelung gemäß RFC 3161 und die HSM-gestützte Schlüsselspeicherung. Alle Zertifikate werden zentral inventarisiert, damit ein 15-monatiger Erneuerungszyklus die manuelle Nachverfolgung nicht übersteigt.

Wichtige Erkenntnisse

• Der Wahlvorschlag CSC-31 wurde am 17. November 2025 angenommen (Code Signing Baseline Requirements v3.10.0); die 460-Tage-Gültigkeitsdauer trat am 1. März 2026 für Zertifikate in Kraft, die an oder nach diesem Datum ausgestellt wurden.
• Diese Website behandelt diese Wahl ausführlicher in Sichere Codesignatur: Reduzierte Zertifikatsgültigkeit auf 460 Tage und Die Lebensdauer von Code-Signatur-Zertifikaten wird immer kürzerund als Teil einer Architektur zur Einhaltung zweier Regime in CRA-konforme Architektur für sichere CodesignierungDort finden Sie alle Details zur Abstimmungsführung und die Checkliste für die Prüfung; diese Seite konzentriert sich auf die Bau-Pipeline und die Mechanismen zur Zeitstempelung.
• Eine bestätigte Schlüsselkompromittierung erfordert weiterhin den Entzug der Zertifizierungsstelle innerhalb von 24 Stunden, unabhängig von der Gültigkeit des Zertifikats; eine kürzere Gültigkeitsdauer verringert das maximale Expositionsfenster, ändert aber nichts an dieser Frist.
• Ein gültiger RFC 3161-Zeitstempel sorgt dafür, dass bereits ausgelieferte Software auch nach Ablauf des Signaturzertifikats noch verifizierbar ist; was jedoch die Möglichkeit einschränkt, neue Software zu signieren.

Was hat sich am 1. März 2026 geändert?

Die Regel selbst ist einfach: Code-Signatur-Zertifikate, die ab dem 1. März 2026 ausgestellt werden, dürfen eine Gültigkeitsdauer von maximal 460 Tagen, also etwa 15 Monaten, haben. Zertifikate, die vor diesem Datum ausgestellt wurden, behalten ihre ursprüngliche Gültigkeitsdauer bis zu ihrem regulären Ablaufdatum. Daher wird es vorübergehend sowohl lang- als auch kurzlebige Zertifikate geben. Die Regel gilt gleichermaßen für Organisationsvalidierungs- (OV) und Extended-Validierungs- (EV) Zertifikate, ohne Ausnahmen, und entspricht einem Muster, das die Branche bereits bei TLS-Zertifikaten angewendet hat. Die Code-Signatur zieht nun nach.

Die Argumentation aus Risikosicht ist einleuchtend. Ein Codesignaturzertifikat steht für Vertrauen, und dieses Vertrauen bleibt so lange bestehen, wie das Zertifikat gültig ist. Wird der zugehörige private Schlüssel gestohlen oder missbraucht, dauert der Schaden genau so lange an wie die Gültigkeitsdauer des Zertifikats. Ein dreijähriges Zertifikat gibt einem Angreifer drei Jahre Zeit, einen gestohlenen Schlüssel zu verwenden. Ein 460-Tage-Zertifikat halbiert dieses Zeitfenster und zwingt Unternehmen, Schlüssel in einem vorhersehbaren Rhythmus zu rotieren, anstatt sie jahrelang ungenutzt zu lassen.

Kürzere Gültigkeitsdauern drängen Teams fast zwangsläufig zur Automatisierung, da die manuelle Zertifikatsverwaltung schnell zusammenbricht, sobald die Erneuerung alle 15 Monate statt alle drei Jahre erfolgt. Dieser Wandel von einer seltenen Aufgabe zu einem routinemäßigen Betriebsprozess ist der eigentliche Kern der Regelung, mehr als die gewählte Anzahl an Tagen.

Wie Codesignierung und Zeitstempelung tatsächlich zusammenarbeiten

Wenn ein Herausgeber Software signiert, wird ein Hashwert erstellt – ein eindeutiger Fingerabdruck des Codes, der sich bereits bei der Änderung eines einzigen Bytes vollständig verändert. Dieser Hashwert wird mit dem privaten Schlüssel des Herausgebers signiert, wodurch eine digitale Signatur entsteht, die zusammen mit dem öffentlichen Zertifikat des Herausgebers an die Software angehängt wird. Beim Herunterladen der Datei berechnet das Betriebssystem des Benutzers den Hashwert neu und vergleicht ihn mithilfe des öffentlichen Schlüssels mit der Signatur. Stimmen die Werte überein und lässt sich die Zertifikatskette auf eine vertrauenswürdige Stammzertifizierungsstelle zurückführen, wird die Software als verifiziert angezeigt. Hat sich seit der Signierung etwas geändert, schlägt die Signaturprüfung fehl. Aus diesem Grund ist der private Schlüssel so wichtig und die Regeln für seine Aufbewahrung werden immer strenger.

Dies wirft eine naheliegende Frage auf: Was geschieht mit Software, die Sie vor Jahren signiert haben, sobald das zugehörige Zertifikat abläuft? Die Antwort liegt im Zeitstempel, dem wichtigsten Detail bei diesem Übergang. Beim Signieren von Code kann Ihr Tool die Signatur auch an eine Time Stamping Authority (TSA) senden, eine vertrauenswürdige Drittpartei, die gemäß dem IETF RF C 3161 Time-Stamp Protocol einen kryptografischen Nachweis über den Zeitpunkt der Signaturerstellung speichert – ein Standard, den die meisten Signaturtools bereits unterstützen.

Sobald ein Zeitstempel hinzugefügt wurde, kann das Betriebssystem bestätigen, dass die Signatur erstellt wurde, als das Zertifikat noch gültig war – selbst nach dessen Ablauf. Das Vertrauen wird zum Zeitpunkt der Signierung gesichert, nicht erst beim Öffnen der Datei. Genau das macht eine häufige Zertifikatsrotation überhaupt erst möglich.

Der Haken dabei ist, dass die Zeitstempelung nicht überall automatisch erfolgt. Einige ältere Build-Skripte überspringen sie, und manche Legacy-Tools überprüfen sie nicht korrekt. Da Zertifikate heutzutage etwa alle 15 Monate ablaufen, lohnt es sich, Ihren Signaturprozess zu überprüfen, um sicherzustellen, dass jeder Build korrekt mit einem Zeitstempel versehen wird. Die korrekte Zeitstempelung ist jedoch nur die halbe Miete; die andere Hälfte besteht darin, sicherzustellen, dass die zugehörige Pipeline mit den Zertifikaten Schritt halten kann, die nun alle 15 Monate statt alle paar Jahre erneuert werden.

Vorbereitung Ihrer Build-Pipeline

Für die meisten Teams ergeben sich aus den betrieblichen Auswirkungen einige konkrete Änderungen. Build-Systeme können nicht länger einen Zertifikatspfad fest codieren und davon ausgehen, dass dieser jahrelang funktioniert; Pipelines müssen das aktuell gültige Zertifikat dynamisch abrufen, anstatt auf eine statische Datei zu verweisen, die mitten in der Veröffentlichung veraltet. Abgeschottete Signaturumgebungen, wie sie in der industriellen Steuerungstechnik, im Gesundheitswesen und bei Regierungssoftware üblich sind, benötigen einen planbaren Zeitplan für den Import neuer Zertifikate, da sie eine automatische Erneuerung oft nicht durchführen können.

Bei mehrjährigen Zertifikatskäufen muss eine häufigere Budgetierung und Genehmigung der Erneuerung notwendig werden, und jeder, der EV- oder OV-Zertifikate verwaltet, benötigt einen Erneuerungskalender, der die Validierungszeit der Zertifizierungsstelle berücksichtigt, die einige Tage dauern kann und niemals bis zur letzten Minute aufgeschoben werden sollte.

Nichts davon ist für sich genommen schwierig. Die eigentliche Herausforderung besteht darin, dass die Signierung bisher als einmalige Einrichtungsaufgabe alle paar Jahre und nicht als kontinuierlicher Prozess behandelt wurde. Die Vorgehensweise in kurzen Schritten macht den Übergang überschaubar. Beginnen Sie mit einer vollständigen Bestandsaufnahme: Listen Sie jedes Codesignaturzertifikat auf Build-Servern, CI/CD-Pipelines, Signierungs-Workstations und in abgeschotteten Umgebungen auf und notieren Sie die ausstellende Zertifizierungsstelle, das Ausstellungsdatum, das Ablaufdatum und den Speicherort jedes privaten Schlüssels. Dies deckt in der Regel mehr Zertifikate auf, als Teams erwarten.

Als Nächstes sollten Sie die Zeitstempelung zur Pflicht machen, indem Sie Ihre Signaturskripte prüfen und sicherstellen, dass jeder Build über eine vertrauenswürdige TSA mit einem Zeitstempel versehen wird. Automatisieren Sie anschließend die Erneuerung und den Schlüsselwechsel, wo immer noch manuelle Schritte erforderlich sind, da die manuelle Erneuerung nicht praktikabel ist, sobald Zertifikate alle 15 Monate ablaufen. Legen Sie abschließend klare Richtlinien für die Schlüsselstärke, zugelassene Algorithmen, das erforderliche HSM-Zertifizierungsniveau und die Zertifikatsinhaberschaft fest und protokollieren Sie jeden Signaturvorgang, um Compliance-Prüfungen so einfach wie möglich zu gestalten.

Einige Fehler treten immer wieder auf. Hier sind ein paar Tipps, um sie zu vermeiden:

• Gehen Sie nicht davon aus, dass alle Ihre Zertifikate am selben Datum ablaufen; Sie werden eine Zeit lang eine Mischung aus Zertifikaten mit langer und kurzer Gültigkeitsdauer haben.
• Vergessen Sie nicht, dass Pipelines, die auf einer statischen Zertifikatsdatei basieren, nicht mehr funktionieren, sobald dieses Zertifikat abläuft, oft mitten in der Veröffentlichung.
• Die Zeitstempelung sollte nicht als optional betrachtet werden, da sie der wichtigste Faktor dafür ist, ob ältere signierte Software weiterhin vertrauenswürdig bleibt.
• Private Schlüssel sollten bei Verlängerungen nicht unberührt bleiben, da dies einen Großteil des Sicherheitsvorteils zunichtemacht, den eine kürzere Gültigkeitsdauer bieten soll.

Der Widerruf wird nicht einfacher, nur weil die Gültigkeitsdauer kürzer ist.

Gemäß den Anforderungen an die Code-Signatur (Abschnitt 4.9.1.1) muss eine Zertifizierungsstelle (CA) ein Zertifikat weiterhin innerhalb von 24 Stunden nach Bestätigung der Kompromittierung des privaten Schlüssels widerrufen, unabhängig davon, ob das Zertifikat einen 460-Tage-Zyklus oder den alten 39-Monats-Zyklus hat. Eine kürzere Gültigkeitsdauer begrenzt lediglich das maximale Risiko, falls eine Kompromittierung unentdeckt bleibt; sie ersetzt nicht die Fähigkeit, innerhalb einer Stunde alle von einem bestimmten Zertifikat signierten Artefakte zu identifizieren. Entwickeln Sie diese Fähigkeit präventiv, nicht erst während eines Vorfalls.

So gehandhabt, werden kürzere Zertifikatsgültigkeitsdauern nicht länger als lästige Pflicht, sondern als fester Bestandteil der Softwarebereitstellung. Und die Gewohnheiten, die Sie jetzt entwickeln, entsprechen genau den Anforderungen des nächsten, größeren kryptografischen Wandels – Ihre Bemühungen sind also nie vergeblich.

Wie dies mit Krypto-Agilität und Post-Quanten-Bereitschaft zusammenhängt

Die gleichen Fähigkeiten, die Sie für den Umgang mit 460-Tage-Codesignaturzertifikaten erwerben – insbesondere Erkennung, Automatisierung und schnelle Rotation –, sind genau das, was Ihr Unternehmen für den umfassenderen Übergang zur Post-Quanten-Kryptographie (PQC) benötigt. Das NIST hat seine ersten Post-Quanten-Standards im August 2024 finalisiert: FIPS 203 (ML-KEM) für die Schlüsselkapselung sowie FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) für digitale Signaturen. Es handelt sich hierbei um endgültige Standards, nicht um Entwürfe, und Unternehmen sollten ihre Planung bereits heute darauf ausrichten.

Die Codesignierung hat eine wichtige Frist. Die NSA-Richtlinie CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) fordert, dass Software und Firmware-Signatur Post-Quanten-Algorithmen unterstützen und bevorzugen, insbesondere die zustandsbehafteten Hash-basierten Verfahren LMS und XMSS (NIST SP 800-208). Diese Phase begann 2025, die ausschließliche Nutzung ist ab 2030 vorgeschrieben. Der Aufbau eines soliden kryptografischen Inventars und die regelmäßige Rotation dieser Verfahren während der 460-tägigen Übergangsphase verschaffen Ihrem Team einen Vorsprung und ersparen Ihnen einen Neustart.

Krypto-Agilität bezeichnet die Fähigkeit, kryptografische Algorithmen, Schlüssel und Zertifikate mit minimalen Auswirkungen auf bestehende Systeme zu ersetzen. Dadurch können Organisationen schnell auf die Abschaffung veralteter Algorithmen, sich ändernde regulatorische Anforderungen oder neue Bedrohungen reagieren, ohne ihre Signaturinfrastruktur neu gestalten zu müssen. In der Praxis bedeutet dies, dass die Migration zu neuen Standards, wie sie beispielsweise unter CNSA 2.0 oder zukünftigen Post-Quanten-Richtlinien gefordert werden, zu einer operativen Anpassung der kryptografischen Richtlinien und nicht zu einem kostspieligen Entwicklungsprojekt wird.

Es bietet zudem operative Ausfallsicherheit. Wird ein Signaturalgorithmus als veraltet eingestuft, eine Sicherheitslücke entdeckt oder ändern sich behördliche Zulassungsvoraussetzungen, können Unternehmen ohne Unterbrechung der Software-Release-Pipelines auf einen alternativen Algorithmus umsteigen. Während der Migrationsphase nach der Quantencomputer-Änderung empfiehlt sich die hybride Codesignierung. Dabei wird jedes Artefakt sowohl mit einem klassischen Algorithmus (wie ECDSA oder RSA) als auch mit einem Post-Quanten-Algorithmus (wie ML-DSA oder LMS) signiert. Dies ermöglicht es den vertrauenden Parteien, Signaturen mit beiden Verfahren zu validieren und so die Interoperabilität mit bestehenden Systemen zu erhalten. Gleichzeitig wird die kryptografische Kontinuität gewährleistet, während die Unterstützung für Post-Quanten-Verschlüsselung immer weiter verbreitet wird.

Organisationen, die ihre Infrastruktur für die Code-Signatur bereits durch automatisiertes Zertifikatslebenszyklusmanagement, regelmäßige Zertifikatsrotation, sichere Schlüsselspeicherung in hardwaregestützten Umgebungen und RFC-3161-konforme Zeitstempelung modernisiert haben, sind deutlich besser gerüstet, neue Algorithmen im Zuge der Weiterentwicklung von Standards zu übernehmen. In der Praxis lässt sich diese hohe Krypto-Agilität mit speziell entwickelten Tools und dem entsprechenden Fachwissen wesentlich leichter erreichen.

Wie Verschlüsselungsberatung helfen kann

Die Umstellung auf kürzere Gültigkeitsdauern von Codesignaturen gestaltet sich deutlich einfacher, wenn Ihre Zertifikats- und Schlüsselverwaltung bereits gut organisiert ist und nicht über verschiedene Teams und Tools verteilt ist. Encryption Consulting unterstützt Sicherheits-, PKI- und DevSecOps-Teams dabei, genau diesen Übergang zu strukturieren – beginnend mit einer klaren Übersicht darüber, wo sich jedes Zertifikat und jeder Schlüssel aktuell befindet.

Unser Team unterstützt Unternehmen beim Aufbau und der Modernisierung ihrer Public-Key-Infrastruktur. Unsere Plattform CodeSign Secure wurde speziell für die Umsetzung der in diesem Blog beschriebenen Praktiken entwickelt: HSM-gestützte Speicherung privater Schlüssel, richtlinienbasierte Genehmigungsworkflows, automatische Zeitstempelung bei jedem Signaturvorgang und detaillierte Prüfprotokolle. CodeSign Secure bietet zudem native Unterstützung für Post-Quantum-Signaturalgorithmen wie ML-DSA und LMS. Teams, die die Plattform jetzt einführen, müssen daher kein zweites Migrationsprojekt starten, wenn die Fristen für CNSA 2.0 ablaufen.

Über die Codesignierung hinaus unterstützen wir Sie bei der Verwaltung des gesamten Zertifikatslebenszyklus, der Schlüsselverwaltung und der Konformitätsabbildung gemäß Standards wie NIST und PCI DSS, damit Ihr Signaturprozess sowohl Audits als auch Angriffen standhält.

Fazit

Die Umstellung auf 460-Tage-Codesignaturzertifikate ist zwar bedeutend, aber gut zu bewältigen, wenn Sie jetzt damit beginnen. Erstellen Sie ein übersichtliches Zertifikatsverzeichnis, führen Sie standardmäßig Zeitstempel ein, rotieren Sie die privaten Schlüssel bei jeder Verlängerung und automatisieren Sie alle verbleibenden manuellen Schritte. Teams, die dies als routinemäßige Wartung betrachten, werden den Übergang kaum bemerken. Teams, die zu lange warten, werden die Auswirkungen auf ihren Release-Plan spüren, wahrscheinlich sogar mehrfach, da dies die erste von mehreren bevorstehenden Verkürzungen der Zertifikatslebensdauer ist. Wenn Sie Unterstützung bei der Vorbereitung Ihrer Codesignatur und Ihres Zertifikatslebenszyklusmanagements auf diese oder zukünftige Änderungen benötigen, ist Encryption Consulting ein guter Ansprechpartner.

Häufig gestellte Fragen

Gilt die 460-Tage-Frist auch für Zertifikate, die ich bereits besitze?

Nein. Zertifikate, die vor dem 1. März 2026 ausgestellt wurden, behalten ihre ursprüngliche Gültigkeit und ihr Ablaufdatum. Die Begrenzung gilt nur für Zertifikate, die an oder nach diesem Datum ausgestellt oder verlängert werden.

Muss ich mir noch Gedanken über den Ablauf des Zertifikats machen, wenn ich alles mit einem Zeitstempel versieht?

Für bereits ausgelieferte Software ist ein gültiger RFC-3161-Zeitstempel ausreichend, um die Verifizierbarkeit zu gewährleisten. Sie benötigen jedoch weiterhin ein gültiges, nicht abgelaufenes Zertifikat, um neue Versionen zu signieren. Die Erneuerung muss daher planmäßig erfolgen.

Verringert eine kürzere Gültigkeitsdauer die Dringlichkeit der Widerrufsplanung?

Nein. Eine bestätigte Kompromittierung des Schlüssels erfordert gemäß den Code Signing Baseline Requirements weiterhin den Widerruf innerhalb von 24 Stunden, unabhängig von der Dauer der Gültigkeitsdauer des Zertifikats.