Die Lebensdauer von Code-Signatur-Zertifikaten wird immer kürzer

Code-Signaturzertifikate authentifizieren Software, bevor sie Endnutzer erreicht. Sie bestätigen, dass eine Binärdatei, ein Installationsprogramm oder ein Update von einem verifizierten Herausgeber stammt und während der Übertragung nicht verändert wurde. Jahrelang war das Betriebsmodell für diese Zertifikate einfach: Man besorgte sich ein Zertifikat mit mehrjähriger Gültigkeit, speicherte es in der Entwicklungsumgebung und verlängerte es, sobald die Ablaufbenachrichtigung erschien. Dieses Modell barg ein stilles, aber reales Risiko, denn ein 39 Monate gültiges Zertifikat bedeutet, dass ein kompromittierter privater Schlüssel für diesen gesamten Zeitraum als vertrauenswürdig gilt, sofern er nicht rechtzeitig entdeckt und widerrufen wird.

Gemäß der CA/Browser Forum-Abstimmung CSC-31 vom 17. November 2025, die in die Code Signing Baseline Requirements Version 3.10.0 aufgenommen wurde, verkürzte sich die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger Codesignaturzertifikate von 39 Monaten auf 460 Tage, also etwa 15 Monate. Alle ab dem 1. März 2026 ausgestellten Codesignaturzertifikate müssen diese Beschränkung einhalten. Zertifikate, die vor diesem Datum ausgestellt wurden, bleiben bis zu ihrem regulären Ablaufdatum gültig; bei der Verlängerung gilt jedoch die neue Gültigkeitsdauer.

Dies ist kein Einzelfall. Es folgt der gleichen Entwicklung wie bei TLS-Zertifikaten , deren Gültigkeitsdauer ab dem 15. März 2026 von 398 auf 200 Tage sank und gemäß CA/B Forum Ballot SC-081v3, der im April 2025 verabschiedet wurde, am 15. März 2027 auf 100 Tage und am 15. März 2029 auf 47 Tage weiter reduziert werden soll. Codesignierung und TLS nähern sich demselben Prinzip an: Zertifikate sollten nicht länger gültig sein als die Vertrauensbedingungen, unter denen sie ausgestellt wurden. Die Branche setzt auf Automatisierung, um dies praktisch umzusetzen.

Dieser Blogbeitrag erläutert die Änderungen, die Risiken und die Punkte, die Unternehmen vor dem nächsten Erneuerungszyklus angehen müssen.

Lebensdauer von Codesignaturzertifikaten, definiert: die maximale Zeitspanne, in der ein öffentlich vertrauenswürdiges Codesignaturzertifikat gültig bleiben kann, bevor es erneuert werden muss. Sie ist auf 460 Tage begrenzt für Zertifikate, die am oder nach dem 1. März 2026 gemäß CA/Browser Forum Ballot CSC-31 ausgestellt wurden, gegenüber der vorherigen Obergrenze von 39 Monaten. Dadurch verdreifacht sich in etwa, wie oft eine Organisation jedes Zertifikat, von dem ihre Signaturinfrastruktur abhängt, erneuern, neu bereitstellen und erneut validieren muss.

Wichtige Erkenntnisse

• Der Wahlvorschlag CSC-31 wurde mit 7 von 9 Ja-Stimmen der Zertifikatsaussteller (zwei Enthaltungen, keine Gegenstimmen) angenommen, durchlief das IPR-Verfahren und wurde am 17. November 2025 verabschiedet. Dabei wurden die Code Signing Baseline Requirements v3.10.0 veröffentlicht; die 460-Tage-Frist trat am 1. März 2026 in Kraft.
• Eine bestätigte Kompromittierung des Schlüssels erfordert weiterhin den Entzug der Zertifizierungsstelle innerhalb von 24 Stunden, unabhängig von der Gültigkeitsdauer des Zertifikats; eine kürzere Gültigkeitsdauer verringert zwar das maximale Zeitfenster für ein Sicherheitsrisiko, ändert aber nichts an dieser Frist.
• Ein gültiger RFC 3161-Zeitstempel sorgt dafür, dass bereits signierte Software auch nach Ablauf des Zertifikats verifizierbar bleibt; was jedoch erlischt, ist die Möglichkeit, neue Software zu signieren. Aus diesem Grund stoppt eine versäumte Verlängerung die Release-Pipeline am 461. Tag und nicht schrittweise.
• Diese Website deckt auch diese Abstimmung ab. Sichere Codesignatur: Reduzierte Zertifikatsgültigkeit auf 460 Tage und als Teil der Architektur zur Einhaltung des Dual-Regimes in CRA-konforme Architektur für sichere CodesignierungDer besondere Fokus dieser Seite liegt auf der operativen Einsatzbereitschaft der Signaturinfrastruktur selbst (Schlüsselspeicherung, Pipeline-Integration, Inventarisierung, Reaktion auf Vorfälle) im Rahmen des neuen Taktes.

Warum die Gültigkeitsdauer von Zertifikaten immer kürzer wird

Die Tendenz zu kürzeren Zertifikatslebensdauern ist nicht willkürlich. Sie adressiert zwei Probleme, die in öffentlichen PKIs seit Langem bestehen: die Diskrepanz zwischen der Kompromittierung eines Zertifikats und dem tatsächlichen Verlust des Vertrauens, sowie die langsame Umstellung von Organisationen auf stärkere kryptografische Standards, solange ihre bestehenden Zertifikate noch einwandfrei funktionieren.

Wenn ein privater Signaturschlüssel offengelegt wird, bleibt das zugehörige Zertifikat gültig, bis es abläuft oder widerrufen wird. Der Widerruf ist mit bekannten Zuverlässigkeitsproblemen behaftet. Zertifikatssperrlisten (CRLs) und das Online Certificate Status Protocol (OCSP) werden nicht von allen Plattformen einheitlich überprüft, und wenn eine Widerrufsprüfung fehlschlägt oder ein Timeout auftritt, werten die meisten Systeme dies als bestanden und nicht als gesperrt.

Das Ergebnis ist, dass ein kompromittiertes Zertifikat so lange ein wirksames Angriffswerkzeug bleibt, wie es als vertrauenswürdig gilt. Nach dem bisherigen Gültigkeitsmodell von 39 Monaten konnte die Kompromittierung eines einzigen Schlüssels ein Unternehmen potenziell über drei Jahre lang einem Risiko aussetzen. Mit der neuen Grenze von 460 Tagen wird der maximale Zeitraum für Angriffe deutlich reduziert.

Das zweite Problem besteht darin, dass Unternehmen gültige Zertifikate tendenziell nicht vorzeitig ersetzen, selbst wenn bessere Algorithmen verfügbar sind. Die Branche musste diese Erfahrung bei der Abschaffung von SHA-1 und dem Übergang von 1024-Bit-RSA-Schlüsseln machen. Beide Übergänge zogen sich unnötig in die Länge, da langlebige Zertifikate Unternehmen keine natürliche Frist zum Handeln boten.

Kürzere Gültigkeitsdauern ändern dies. Jede Verlängerung bietet die Möglichkeit, aktuelle Standards einzuführen. Dies ist insbesondere jetzt relevant, da das NIST im August 2024 seine ersten Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) finalisiert hat. Organisationen, die ihre Zertifikate regelmäßig verlängern, sind deutlich besser gerüstet, um quantenresistente Algorithmen einzuführen, sobald die Unterstützung durch Plattformen und Zertifizierungsstellen weiterentwickelt wird.

Kürzere Zertifikatsgültigkeitsdauern begrenzen den Schaden durch einen Schlüsselkompromittierungsfall, verringern die Abhängigkeit von nicht immer zuverlässigen Widerrufsmechanismen und halten kryptografische Standards im gesamten Ökosystem aktuell. Die Anwendung dieser Regelung auf Codesignaturzertifikate ist ein direkter Schritt hin zu mehr Sicherheit in der Software-Lieferkette . Der Wahlvorschlag CSC-31 formalisierte diesen Schritt mit einer festgelegten maximalen Gültigkeitsdauer und einem verbindlichen Inkrafttretensdatum für alle öffentlich vertrauenswürdigen Codesignaturzertifikate.

Was hat sich durch die Wahl CSC-31 tatsächlich geändert?

Die CA/B-Forum-Abstimmung CSC-31 wurde von Microsoft vorgeschlagen. Die Abstimmungsfrist endete am 13. Oktober 2025, und die Abstimmung wurde nach Abschluss der Prüfung des geistigen Eigentums am 17. November 2025 formell angenommen. Sieben von neun Zertifikatsausstellern stimmten dafür, zwei enthielten sich, und niemand stimmte dagegen. Auch die einzige Stimme eines Zertifikatsinhabers, abgegeben von Microsoft, fiel positiv aus. Die Prüfung des geistigen Eigentums endete am 17. November 2025, ohne dass Ausschlussanträge eingereicht wurden.

Die aktualisierten Anforderungen an die Code-Signatur (Version 3.10.0) wurden am 17. November 2025 veröffentlicht. Die neue Gültigkeitsdauer tritt am 1. März 2026 in Kraft. Die Anforderung gilt für alle öffentlich vertrauenswürdigen Code-Signaturzertifikate, d. h. für Zertifikate von Zertifizierungsstellen, deren Stammzertifikate in den Truststores von Betriebssystemen und Browsern hinterlegt sind. Private PKI-Systeme, die für interne Signaturprozesse verwendet werden, unterliegen nicht den Regeln des CA/B-Forums. Eine Angleichung der internen Vorgehensweise an denselben Standard ist jedoch sinnvoll.

Ein wichtiger praktischer Punkt: Die 460-Tage-Frist beginnt mit dem Ausstellungsdatum, nicht mit dem Bestelldatum. Zertifikate, die vor dem 1. März 2026 beantragt, aber erst danach ausgestellt wurden, unterliegen der neuen Beschränkung. Die meisten Zertifizierungsstellen (CAs) haben die Ausstellung von 2- und 3-jährigen Codesignaturzertifikaten Ende Februar 2026 eingestellt, um die Frist einheitlich umzusetzen. Alle ab dem 1. März 2026 ausgestellten, öffentlich vertrauenswürdigen Codesignaturzertifikate sind maximal 460 Tage gültig.

Die Einhaltung der 460-Tage-Frist ist theoretisch unkompliziert. Die schwierigere Frage ist jedoch, ob die bestehende Infrastruktur für die Vertragsunterzeichnung jemals für diesen Rhythmus ausgelegt war.

Warum die Infrastruktur für die Signatur nicht dafür ausgelegt war

Der Wechsel von einem 39-monatigen Zertifikat zu einem 460-Tage-Zertifikat klingt nach einer einfachen Änderung des Verlängerungskalenders. In der Praxis offenbart er jedoch strukturelle Probleme in den Signaturprozessen, die die meisten Organisationen eingerichtet haben.

Der erste Punkt betrifft die Schlüsselspeicherung. Die Code Signing Baseline Requirements schreiben bereits vor, dass die privaten Schlüssel aller öffentlich vertrauenswürdigen Code-Signatur-Zertifikate – sowohl der standardmäßigen Organization Validated (OV) als auch der Extended Validation (EV) – in einem Hardware-Kryptografiemodul gespeichert werden müssen, das mindestens den Federal Information Processing Standards (FIPS) 140-2 Level 2 oder den Common Criteria EAL 4+ entspricht. Da die FIPS-140-2-Validierungen am 21. September 2026 in die Liste der historischen Validierungen aufgenommen werden, sollten Organisationen, die neue Hardware beschaffen, Module mit aktiver FIPS-140-3-Validierung priorisieren , um die fortlaufende Konformität auch nach diesem Datum sicherzustellen.

Für Standard-OV-Zertifikate sind Hardware-Tokens wie USB-basierte Geräte weit verbreitet, doch sie verursachen einen erheblichen Verwaltungsaufwand. Tokens können verloren gehen, sind an bestimmte Personen gebunden und die Verlängerung erfordert eine erneute Bereitstellung der Hardware. Bei einem 460-Tage-Zyklus findet dieser Prozess jährlich statt statt alle drei Jahre statt, was deutlich mehr Aufwand und ein höheres Fehlerrisiko mit sich bringt, wenn die Verwaltung nicht ordnungsgemäß erfolgt.

Das zweite Problem ist die Pipeline-Integration. Viele Build-Systeme signieren Artefakte mit einem Zertifikat und einem Schlüssel, die manuell in einem Dateisystempfad, einer Umgebungsvariablen oder einem Eintrag im Secrets Manager hinterlegt wurden. Wird das Zertifikat ersetzt, bricht etwas in dieser Kette. Bei einem 460-Tage-Zyklus tritt dieser Fehler häufiger auf. Teams ohne durchgängige Automatisierung der Zertifikatsbereitstellung, der Generierung von Certificate Signing Requests (CSRs), der Interaktion mit der Zertifizierungsstelle und der Bereitstellung werden diesen Zeitplan nur schwer zuverlässig verwalten können.

Das dritte Problem ist die Bestandsverwaltung. Eine einzelne Organisation kann Dutzende von Codesignaturzertifikaten besitzen, die über verschiedene Produktlinien, Entwicklungsumgebungen und von externen Dienstleistern verwaltete Systeme verteilt sind. Die Teams, die diese Zertifikate vor drei Jahren besaßen, sind möglicherweise nicht mehr im Unternehmen. Ohne eine zentrale Erfassung der vorhandenen Zertifikate, ihrer Eigentümer und ihrer Ablaufdaten wird ein 460-tägiger Erneuerungszyklus unpraktikabel.

Die strukturellen Lücken in der Unterzeichnungsinfrastruktur führen nicht nur zu Reibungsverlusten bei der Erneuerung von Zertifikaten; sie werden zu kritischen Haftungsrisiken, sobald ein Zertifikat in Frage gestellt wird.

Was passiert, wenn ein Code-Signaturzertifikat kompromittiert wird?

Ein kompromittiertes Codesignaturzertifikat ist nicht nur ein Sicherheitsvorfall, sondern ein betrieblicher Notfall mit einer strikten Frist. Gemäß den Code Signing Baseline Requirements Version 3.10.0 muss eine Zertifizierungsstelle (CA) ein Codesignaturzertifikat innerhalb von 24 Stunden widerrufen, nachdem sie darüber informiert wurde, dass das Zertifikat zum Signieren von Schadsoftware verwendet wurde oder dass der private Schlüssel gestohlen oder offengelegt wurde. Dieses 24-Stunden-Fenster lässt kaum Spielraum für eine langsame oder unkoordinierte Reaktion.

Das unmittelbare Problem ist die Identifizierung. Bevor eine Zertifizierungsstelle (CA) tätig werden kann, muss das betreffende Zertifikat genau identifiziert werden: Seriennummer, ausstellende CA und aktueller Sperrstatus. Für Organisationen ohne zentrales Zertifikatsverzeichnis kann allein dieser Schritt Stunden dauern. Sind Signaturzertifikate über verschiedene Teams, Build-Umgebungen und Systeme von Auftragnehmern verteilt und kein eindeutiger Eigentümer verzeichnet, ist es unter Zeitdruck schwierig, das richtige Zertifikat zu finden.

Nach dem Widerruf kann das Zertifikat nicht mehr zur Signierung neuer Dokumente verwendet werden, und die Zertifizierungsstelle (CA) veröffentlicht den Widerruf über ihre CRL- und OCSP-Infrastruktur. Die Überprüfung des Widerrufs wird jedoch nicht auf allen Plattformen einheitlich durchgeführt. Das bedeutet, dass ein widerrufenes Zertifikat in manchen Umgebungen nach dem Widerruf noch eine Zeit lang akzeptiert werden kann – genau das Verhalten, das durch kürzere Zertifikatslebensdauern im Laufe der Zeit eingeschränkt werden soll.

Das Ersatzzertifikat muss anschließend ausgestellt und in allen Pipelines bereitgestellt werden, die vom kompromittierten Zertifikat abhängig waren. Ohne dokumentierte Pipeline-Integration und automatisierte Bereitstellung bedeutet dies einen weiteren manuellen Aufwand unter Zeitdruck. Organisationen mit einem Hardware-Sicherheitsmodul (HSM) zur Schlüsselspeicherung sind hier im Vorteil, da die Kompromittierung typischerweise auf das Zertifikat und nicht auf die zugrunde liegende Hardware beschränkt ist und die Generierung neuer Schlüssel innerhalb des HSM erfolgen kann, ohne dass physische Token teamübergreifend neu bereitgestellt werden müssen.

Die praktische Lehre ist eindeutig: Dieselben Schwachstellen, die die Verwaltung eines 460-tägigen Erneuerungszyklus erschweren – wie unvollständige Zertifikatsbestände, manuelle Signaturprozesse und softwaregespeicherte private Schlüssel –, führen auch zu langsameren und fehleranfälligeren Reaktionen auf Sicherheitsvorfälle. Die Behebung dieser Schwachstellen vor einem Sicherheitsvorfall ist deutlich kostengünstiger als der Versuch, sie während eines laufenden Vorfalls zu beheben.

Die Reaktion auf Sicherheitsvorfälle endet nicht mit dem Entzug und der Ersetzung von Zertifikaten. Unternehmen müssen auch verstehen, wie sich Zeitstempel auf das Vertrauen und die Nutzbarkeit zuvor signierter Software auswirken.

Die Frage der Zeitstempelung, die die meisten Teams übersehen

Ein Aspekt der Codesignierung, der bei kürzeren Zertifikatsgültigkeitsdauern besonders wichtig ist, ist die Zeitstempelung gemäß RFC 3161. Wenn eine Signatur einen vertrauenswürdigen Zeitstempel einer Zeitstempelstelle (Time-Stamping Authority, TSA) enthält , bleibt diese Signatur auch nach Ablauf des Zertifikats gültig.

Der Zeitstempel liefert einen kryptografischen Nachweis darüber, wann die Software signiert wurde. Dadurch bleibt die Signatur auch nach Ablauf des Codesignaturzertifikats gültig, vorausgesetzt, die Zertifikatskette der TSA ist zum Zeitpunkt der Überprüfung gültig und vertrauenswürdig. Folglich verliert Software, die vor Ablauf des Zertifikats signiert und verteilt wurde, nicht automatisch ihr Vertrauen gemäß der neuen Gültigkeitsdauer von 460 Tagen. 

Was sich ändert, ist das Signaturzertifikat selbst. Für die Signierung neuer Releases, Builds und aktualisierter Pakete ist ein gültiges, nicht abgelaufenes Zertifikat erforderlich. Sobald ein Codesignaturzertifikat abläuft, kann es nicht mehr für neue Signaturen verwendet werden, selbst wenn ältere Signaturen dieses Zertifikats weiterhin gültig sind. Die Folgen sind unmittelbar: Jede Lücke in der Zertifikatsverfügbarkeit unterbricht die Softwareauslieferung. Bei einem 460-Tage-Zyklus lässt eine versäumte Verlängerung keine dreijährige Pufferzeit zu. Sie stoppt die Softwareentwicklung am 461. Tag.

Diese praktischen Gegebenheiten machen eines deutlich: Organisationen benötigen Signatur-Workflows, die für die kontinuierliche Zertifikatserneuerung und nicht nur für den gelegentlichen Zertifikatsaustausch ausgelegt sind.

Was muss sich bei den Signaturprozessen ändern?

Die Einhaltung der 460-Tage-Grenze ist nur der Anfang. Um einen Workflow zu entwickeln, der auch die nächste Reduzierung übersteht – die angesichts der bereits geplanten mehrjährigen Reduzierung von TLS-Zertifikaten wahrscheinlich ist –, sind strukturelle Änderungen erforderlich.

1. Erstellen Sie ein vollständiges Zertifikatsverzeichnis. Wissen Sie, wie viele Codesignaturzertifikate existieren, wo sie eingesetzt werden, welche Pipelines davon abhängen und wem jedes einzelne gehört? Für Organisationen, die noch das alte 39-Monats-Modell verwenden, ist diese Bestandsaufnahme oft nicht in nutzbarer Form vorhanden und die Voraussetzung für alle weiteren Punkte auf dieser Liste.
2. Signaturschlüssel in Hardware auslagern. Private Schlüssel auf Dateisystemen, Entwicklerrechnern oder Build-Servern müssen in ein HSM verschoben werden, das die Mindestanforderungen von FIPS 140-2 Level 2 erfüllt (für Neubeschaffungen wird FIPS 140-3 angestrebt, da die Validierungen nach FIPS 140-2 am 21. September 2026 in die Liste der historischen Zertifizierungen aufgenommen werden).
3. Automatisieren Sie den Erneuerungsprozess. Die Generierung von CSRs, die Einreichung von CA-Dokumenten, die Ausstellung und die Bereitstellung sollten über einen wiederholbaren, nachvollziehbaren Workflow erfolgen, wobei ACME zum Einsatz kommen sollte, sofern CA-Unterstützung verfügbar ist, anstatt eines manuellen Prozesses, der erst Tage vor Ablauf der Gültigkeit begonnen wird.
4. Die Bestätigung, dass die Zeitstempelung in der Pipeline nicht verhandelbar ist, ist unerlässlich. Ein fehlender RFC 3161-Zeitstempel ist als Signaturfehler und nicht als Warnung zu behandeln, da er dafür sorgt, dass bereits ausgelieferte Software nach Ablauf des Signaturzertifikats verifizierbar bleibt.
5. Üben Sie die Abfolge von Kompromiss und Reaktion, bevor Sie sie benötigen. Stellen Sie sicher, dass Sie innerhalb der Stunde, in der ein Kompromittierungsverdacht besteht, jedes mit einem bestimmten Zertifikat signierte Artefakt identifizieren können, da die 24-Stunden-Frist der Zertifizierungsstelle für den Widerruf nicht darauf wartet, dass Sie diese Fähigkeit unter Druck aufbauen.
6. Planen Sie für die nächste Reduzierung, nicht nur für diese. Codesignaturzertifikate befinden sich auf dem gleichen Entwicklungspfad wie TLS-Zertifikate. Eine auf Automatisierung ausgerichtete Infrastruktur fängt die nächste Reduzierung auf; eine Kalendererinnerung hingegen nicht.

Für viele Organisationen erfordert der Aufbau dieses Reifegrades im operativen Bereich spezialisiertes Fachwissen, geeignete Werkzeuge und eine schrittweise Implementierungsstrategie. Hier kann Encryption Consulting helfen.

Codesignierung vs. TLS: Die gleiche Entwicklung

Art des Zertifikats	vorherige Gültigkeit	Aktuelle Gültigkeit	Geplante zukünftige Reduzierung
Codesignatur	39 Monate	460 Tage (ab dem 1. März 2026, Wahlzettel CSC-31)	Bisher sind noch keine Termine festgelegt, aber die Entwicklung deutet darauf hin, dass weitere folgen werden.
TLS	398 Tage	200 Tage (ab dem 15. März 2026, Wahlzettel SC-081v3)	100 Tage (15. März 2027), 47 Tage (15. März 2029)

Wie Verschlüsselungsberatung helfen kann

CodeSign Secure ist die Enterprise-Codesignatur-Managementplattform von Encryption Consulting, die entwickelt wurde, um die von verschiedenen Branchen benötigten Infrastrukturkontrollen bereitzustellen.

HSM-gestütztes Schlüsselmanagement

CodeSign Secure speichert alle privaten Signaturschlüssel in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen (HSMs) und ist mit Thales Luna, Entrust nShield, Utimaco, Securosys sowie Cloud-HSMs von AWS und Azure kompatibel. Die Schlüsselisolation pro Produkt wird auf HSM-Partitionsebene gewährleistet: Jede Produktlinie erhält einen eigenen, dedizierten Schlüssel, der in der Hardware generiert und niemals exportiert wird.

Unterzeichnungsbeschlussfähigkeit und RBAC der M-of-N

Das rollenbasierte Zugriffskontrollmodell der Plattform erzwingt die Genehmigungsanforderungen (M-von-N) für die Signierung von Produktions-Firmware. Keine einzelne Person kann einen Signiervorgang initiieren und genehmigen. Signieranfragen, Genehmigungen und Ablehnungen werden protokolliert. Die RBAC-Konfiguration selbst ist auditierbar und versionskontrolliert und stellt somit die dokumentierte Signierrichtlinie bereit, die für CRA-Konformitätsbewertungen erforderlich ist.

Unveränderliche Audit-Protokollierung

Jeder Signaturvorgang in CodeSign Secure erzeugt einen unveränderlichen Protokolleintrag, der den Artefakt-Hash, die Schlüsselkennung, das verwendete Zertifikat, die genehmigende Identität und den RFC-3161-Zeitstempel erfasst. Die Protokolle werden zentral und getrennt von der Signaturinfrastruktur gespeichert.

Unterstützung für plattformübergreifende Firmware-Formate

CodeSign Secure unterstützt die Signierung von Firmware-Artefakten in allen Formaten, die ein vielfältiges Produktportfolio erfordert: .bin, .img, .hex, .fw, .dfu und .efi. Damit wird die Anforderung der CRA nach einheitlichen Kontrollen über alle Produktlinien hinweg erfüllt, ohne dass die Signaturinfrastruktur für jede Plattform neu aufgebaut werden muss.

Unterstützung für Post-Quanten-Kryptographie

CodeSign Secure v3.02 unterstützt produktionsreife ML-DSA (FIPS 204, Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) und SLH-DSA (FIPS 205) als abtrennbare Signaturen neben klassischen Algorithmen. Für Hersteller von Produkten mit mehr als fünfjährigen CRA-Supportverpflichtungen bietet die PQC-Signatur heute Schutz vor der HNDL-Bedrohung, bevor ein kryptografisch relevanter Quantencomputer (CRQC) verfügbar ist.

CI/CD-Pipeline-Integration

CodeSign Secure lässt sich über API- und Befehlszeilenschnittstellen in Azure DevOps , Jenkins , GitLab CI und andere gängige Pipeline-Plattformen integrieren. Die Signierung der Firmware ist ein kontrollierter, richtlinienkonformer Schritt in der Build-Pipeline und kein manueller Vorgang.

Organisationen, die den 460-tägigen Übergangsprozess durchlaufen – sei es die Bewertung ihres aktuellen Zertifikatsbestands, die Migration von Schlüsseln auf Hardware oder die Einrichtung automatisierter Erneuerungsprozesse – können sich für eine praxisnahe Beratung an Encryption Consulting wenden. Das Team arbeitet direkt mit den Organisationen zusammen, um Schwachstellen in ihrer Signaturinfrastruktur zu identifizieren und einen praktikablen Weg zu entwickeln, bevor der nächste Erneuerungszyklus Druck erzeugt.

Fazit

Die Abstimmung des CA/B Forums (CSC-31) markiert einen grundlegenden Wandel im Umgang mit öffentlich vertrauenswürdigen Code-Signaturzertifikaten. Die bisherige Gültigkeitsdauer von 39 Monaten, auf der die meisten Teams ihre Arbeitsabläufe aufgebaut hatten, entfällt. Organisationen, die sich noch nicht angepasst haben, stehen demnächst vor ihrer ersten Verlängerung um 460 Tage. Die dann getroffenen Infrastrukturentscheidungen werden darüber entscheiden, ob zukünftige Kürzungen zu Störungen führen oder reibungslos verlaufen.

Organisationen, die in dieser Situation erfolgreich sind, beschränken sich nicht darauf, eine Kalendererinnerung hinzuzufügen und weiterzumachen. Sie verstehen die 460-Tage-Grenze als klares Signal: Die Branche tendiert branchenweit zu kürzeren Zertifikatslaufzeiten, TLS-Zertifikate unterliegen bereits einem bestätigten mehrjährigen Reduzierungsplan, und auch die Codesignierung befindet sich auf diesem Weg. Der Aufbau einer automatisierten, auditierbaren Signaturinfrastruktur bedeutet, dass diese bei der nächsten Reduzierung nicht erneut aufgebaut werden muss.

Das CA/B-Forum verfolgt konsequent seine Strategie. Die Gültigkeitsdauer von Zertifikaten wird sich weiter verkürzen, und manuelle Erneuerungsprozesse werden zunehmend schwieriger aufrechtzuerhalten sein. Organisationen, die heute in Erkennung, hardwaregestützte Schlüsselspeicherung und automatisiertes Zertifikatslebenszyklusmanagement investieren, erfüllen nicht nur eine aktuelle Anforderung. Sie schaffen die Grundlage, die sie auch bei zukünftigen Verkürzungen der Zertifikatsgültigkeit tragen wird.

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 Gültigkeit bis zu ihrem ursprünglichen Ablaufdatum. Die Obergrenze gilt für Zertifikate, die an oder nach diesem Datum ausgestellt oder verlängert werden, und zwar ab dem Ausstellungsdatum, nicht ab dem Bestelldatum.

Muss für private, interne PKI die 460-Tage-Grenze eingehalten werden?

Nein. Die Regeln des CA/Browser-Forums gelten nur für öffentlich vertrauenswürdige Zertifikate, also solche, die von Zertifizierungsstellen ausgestellt werden, deren Stammzertifizierungsstellen in den Vertrauensspeichern von Betriebssystem und Browser eingebettet sind. Private PKI für interne Signierungszwecke unterliegen dieser Regelung nicht, obwohl die Angleichung der internen Vorgehensweise an denselben Standard eine sinnvolle Vorsichtsmaßnahme darstellt.

Was passiert mit bereits ausgelieferter Software, wenn das Signaturzertifikat abläuft?

Nichts, sofern die Signatur einen gültigen RFC-3161-Zeitstempel enthält. Software, die vor Ablauf des Zertifikats signiert und verteilt wurde, behält ihre Vertrauenswürdigkeit; lediglich die Möglichkeit, mit diesem abgelaufenen Zertifikat neue Software zu signieren, ist nicht mehr gegeben.

Wird die Gültigkeit von TLS-Zertifikaten weiter abnehmen?

Ja, gemäß einem bestätigten Zeitplan: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029 (gemäß Wahlzettel SC-081v3). Für die Kodierung gibt es noch keinen bestätigten Plan für eine weitere Reduzierung, sie folgt aber nun dem gleichen allgemeinen Trend.