Codesigning-CA aufbauen und härten
Warum Codesigning in eine eigene, gehärtete PKI-Hierarchie gehört — und was ein kompromittierter Signing-Key wirklich bedeutet.Codesigning-CA aufbauen — Härtung, EV-Anforderungen, Workflows
Warum Codesigning in eine eigene, gehärtete Hierarchie gehört — und warum ein kompromittierter Signing-Key kein IT-Vorfall, sondern ein Reputations-GAU ist.
Kurzfassung vorab
Codesigning ist die gefährlichste Disziplin in deiner PKI, weil ein Codesigning-Zertifikat eine einzige, mächtige Aussage macht: „Diese Software kommt von uns und ist vertrauenswürdig.“ Wer deinen Signing-Key erbeutet, signiert Malware in deinem Namen — und jedes Gerät, das deiner CA vertraut, akzeptiert sie als legitim. Deshalb meine klare Position: Codesigning gehört in eine eigene, von der normalen Unternehmens-PKI getrennte Hierarchie, der Schlüssel gehört ins HSM und verlässt es nie, jede Signatur braucht einen RFC-3161-Timestamp, und es wird nichts ohne Vier-Augen-Freigabe signiert. Eine eigene ADCS-Codesigning-CA reicht für alles, was intern läuft; öffentliche EV-Zertifikate brauchst du nur für Software, die bei fremden Kunden ohne Warnung starten muss.
Abb. 1: Codesigning gehört in eine eigene Hierarchie — bewusst getrennt von der PKI für TLS, Nutzer und S/MIME.
1. Warum eine getrennte Hierarchie
Der erste und wichtigste Designentscheid ist die Trennung. Deine normale Unternehmens-PKI ist auf Durchsatz ausgelegt: Sie stellt im Auto-Enrollment massenhaft Zertifikate für TLS, Nutzer und S/MIME aus. Diese CA ist erreichbar, sie arbeitet ständig, sie ist Teil des Tagesgeschäfts. Genau das ist das Gegenteil dessen, was du für Codesigning willst.
Eine Codesigning-CA soll selten, kontrolliert und unter strenger Aufsicht arbeiten. Wenn du Codesigning in deine bestehende Issuing CA hängst, vererbst du dem Signing-Prozess die gesamte Angriffsfläche des Tagesbetriebs — und im Kompromittierungsfall reißt ein Vorfall beide Welten mit. Eine eigene Root und eine eigene Codesigning-CA bedeuten: kein gemeinsamer Vertrauensanker, kein gemeinsames Schlüsselmaterial, getrennte Schicksale.
|
Info · Verweis Wie eine mehrstufige Architektur grundsätzlich aufgebaut wird, zeigt Spoke 1.4 zu den ein-, zwei- und dreistufigen Hierarchien. Die HSM-Auswahl, die für Codesigning besonders zählt, vertieft Spoke 3.3. |
|---|
2. Der Signatur-Workflow — und warum der Timestamp alles ist
Ein sauberer Codesigning-Prozess hat vier Stationen, und die letzte wird am häufigsten vergessen — mit teuren Folgen.
Abb. 2: Der Signatur-Workflow — der RFC-3161-Timestamp entscheidet, ob deine Signatur den Ablauf des Zertifikats überlebt.
Der Timestamp ist kein Komfort-Feature, sondern überlebenswichtig. Ohne Zeitstempel wird deine Signatur ungültig, sobald das Signing-Zertifikat abläuft — und zwar rückwirkend für jede Software, die du jemals damit signiert hast. Stell dir vor, du signierst heute ein Tool, das Zertifikat läuft in drei Jahren ab, und plötzlich verweigern alle Clients die Ausführung der seit Jahren laufenden Software. Mit einem RFC-3161-Timestamp von einer Time Stamping Authority bleibt die Signatur gültig, weil belegt ist, dass das Zertifikat zum Signaturzeitpunkt noch gültig war. Der Ablauf des Zertifikats spielt dann keine Rolle mehr.
Der Schlüssel verlässt nie das HSM
Die zweite Nicht-Verhandelbarkeit: Der Signing-Schlüssel wird im HSM erzeugt und verlässt es nie. Seit der Verschärfung der CA/Browser-Forum-Regeln 2023 ist Hardware-Schutz für Codesigning-Schlüssel bei öffentlichen Zertifikaten faktisch Pflicht — und für eine interne CA ist es schlicht gesunder Menschenverstand. Ein exportierbarer Signing-Key, der auf einer Festplatte oder in einem Build-Server liegt, ist ein Totalschaden, der nur auf den richtigen Angreifer wartet.
|
Warnung · Der GAU mit Ansage Ein exportierbarer Codesigning-Schlüssel auf einem Build-Server ist die gefährlichste Konfiguration überhaupt. Build-Server sind regelmäßig kompromittiert — sie ziehen Code aus vielen Quellen, laufen Skripte, sind ein klassisches Lateral-Movement-Ziel. Liegt der Signing-Key dort exportierbar, signiert der Angreifer beim nächsten Einbruch seine Payload mit deinem Zertifikat. Der Schlüssel gehört ins HSM, und der Build-Server ruft die Signatur über eine API ab, ohne den Schlüssel je zu sehen. |
|---|
3. Eigene CA oder öffentliche EV-Zertifikate?
Die zweite große Entscheidung ist die Vertrauensreichweite. Eine eigene Codesigning-CA wird nur dort vertraut, wo deine Root verteilt ist — also intern. Öffentliche Codesigning-Zertifikate, besonders EV-Varianten, werden weltweit vertraut und bringen SmartScreen-Reputation mit.
Abb. 3: Eigene ADCS-Codesigning-CA gegenüber öffentlichen EV-Zertifikaten — die Vertrauensreichweite ist das entscheidende Kriterium.
Die ehrliche Empfehlung
Für interne Tools, PowerShell-Skripte, Line-of-Business-Anwendungen und alles, was nur auf euren eigenen, gemanagten Geräten läuft, ist die eigene ADCS-Codesigning-CA die richtige und kostenlose Lösung. Öffentliche EV-Zertifikate, die schnell vierstellig pro Jahr kosten, brauchst du ausschließlich für Software, die bei fremden Kunden ohne SmartScreen-Warnung starten muss. Wer interne Wartungsskripte mit teuren EV-Zertifikaten signiert, verbrennt Geld ohne jeden Mehrwert — intern zählt nur, dass deine eigene CA vertraut wird.
4. Die Codesigning-CA härten
Wenn die Architekturentscheidungen stehen, kommt die Härtung. Sechs Punkte sind nicht verhandelbar, und der erste Verstoß dagegen ist meist der teuerste.
Abb. 4: Die sechs Härtungspunkte — und die Konsequenz, wenn der Signing-Key kompromittiert wird.
Mit PowerShell prüfst du die kritischen Template-Eigenschaften der Codesigning-CA — insbesondere, ob der private Schlüssel als nicht-exportierbar markiert ist und das Template auf die Code-Signing-EKU beschränkt ist:
|
PowerShell # — Codesigning-Templates auf der CA finden — Get-CATemplate | Where-Object { $_.Name -like '*CodeSign*' -or $_.Name -like '*Signing*' } | Select-Object Name
# — EKU und Exportierbarkeit prüfen — $tpl = 'CodeSigning' $base = ("CN=Certificate Templates,CN=Public Key Services,CN=Services," + "CN=Configuration,$((Get-ADRootDSE).rootDomainNamingContext)") Get-ADObject -SearchBase $base -Filter { Name -eq $tpl } ` -Properties 'pKIExtendedKeyUsage', 'msPKI-Private-Key-Flag' | Select-Object Name, @{ N='NurCodeSigningEKU'; E={ ($_.'pKIExtendedKeyUsage' -eq '1.3.6.1.5.5.7.3.3') }}, @{ N='Exportierbar'; E={ [bool]($_.'msPKI-Private-Key-Flag' -band 0x10) }}
# — Eine fertige Signatur samt Timestamp verifizieren — # (zeigt, ob signiert UND korrekt zeitgestempelt wurde) Get-AuthenticodeSignature -FilePath 'C:\Build\MeinTool.exe' | Select-Object Status, SignerCertificate, TimeStamperCertificate |
|---|
Steht „Exportierbar“ auf True, ist das ein sofortiger Handlungspunkt — ein Codesigning-Schlüssel darf nicht exportierbar sein. Und wenn beim letzten Kommando „TimeStamperCertificate“ leer bleibt, wurde ohne Zeitstempel signiert: Diese Signatur wird mit Ablauf des Zertifikats wertlos.
5. Betrieb: Freigabe, Audit und der Notfall
Im Betrieb ist Codesigning kein technisches, sondern ein Prozessthema. Die zentrale Frage lautet nicht „Wie signiere ich?“, sondern „Wer darf was unter welcher Kontrolle signieren?“. Das Vier-Augen-Prinzip vor jeder Signatur ist hier kein bürokratischer Ballast, sondern die Schranke, die verhindert, dass ein einzelner kompromittierter Account oder ein unzufriedener Mitarbeiter eigenmächtig signiert.
Genauso wichtig ist das lückenlose Audit: Wer hat wann welches Artefakt mit welchem Schlüssel signiert? Im Vorfall ist das die einzige Möglichkeit, den Schaden einzugrenzen und zu beantworten, welche Signaturen noch vertrauenswürdig sind und welche zurückgezogen werden müssen. Und du brauchst einen geprobten Notfallplan: Wie sperrst du ein kompromittiertes Signing-Zertifikat, und wie kommunizierst du das an alle, die deinen Signaturen vertrauen?
|
Praxis-Tipp · Aus dem Beratungsalltag Trenne die Rolle „darf Build erstellen“ strikt von der Rolle „darf Signatur freigeben“. Der häufigste Designfehler ist ein Build-Pipeline-Account, der automatisch signieren darf — damit hast du das Vier-Augen-Prinzip ausgehebelt und einen vollautomatischen Weg gebaut, kompromittierten Code zu signieren. Die Freigabe gehört bewusst zu einem menschlichen, dokumentierten Schritt. |
|---|
Praxis-Beispiel: Trendforge Digital GmbH
Die Trendforge Digital GmbH, ein Tech-Scaleup mit eigener Softwareentwicklung, signierte ihre internen Tools und Build-Artefakte zunächst mit einem Codesigning-Zertifikat, das exportierbar auf dem zentralen Build-Server lag. Die Pipeline signierte vollautomatisch bei jedem Build — bequem, aber ein offenes Scheunentor. Im Health-Check war das der gravierendste Befund: Ein Einbruch auf dem Build-Server hätte bedeutet, dass der Angreifer beliebige Software im Namen der Firma hätte signieren können.
Wir haben eine getrennte Codesigning-Hierarchie aufgesetzt: eigene Offline Root, eine HSM-geschützte Codesigning-CA, der Schlüssel nicht mehr exportierbar. Die Build-Pipeline ruft die Signatur jetzt über eine HSM-API ab, ohne den Schlüssel je zu sehen, und vor jeder Signatur steht eine dokumentierte Vier-Augen-Freigabe. Jede Signatur bekommt einen RFC-3161-Timestamp, jeder Vorgang wird geloggt. Für die eine Komponente, die auch bei externen Partnern ohne Warnung laufen muss, kam zusätzlich ein öffentliches EV-Zertifikat zum Einsatz — gezielt nur dort, wo die externe Vertrauensreichweite wirklich gebraucht wird.
Verwandte Themen
Häufige Fragen (FAQ)
Warum sollte Codesigning eine eigene CA bekommen?
Weil ein Codesigning-Schlüssel eine besonders mächtige Aussage trifft und ungleich strenger geschützt werden muss als ein TLS- oder Nutzerzertifikat. Eine eigene, von der Tagesbetriebs-PKI getrennte Hierarchie sorgt dafür, dass kein gemeinsamer Vertrauensanker und kein gemeinsames Schlüsselmaterial existiert — ein Vorfall in der einen Welt reißt die andere nicht mit.
Brauche ich für interne Software ein teures EV-Zertifikat?
Nein. Für alles, was nur auf euren eigenen, gemanagten Geräten läuft, reicht eine eigene ADCS-Codesigning-CA, der deine Geräte ohnehin vertrauen. Öffentliche EV-Zertifikate brauchst du nur für Software, die bei fremden Kunden ohne SmartScreen-Warnung starten muss. Interne Skripte mit EV-Zertifikaten zu signieren, ist verbranntes Geld.
Warum ist der Timestamp beim Signieren so wichtig?
Ohne RFC-3161-Timestamp wird deine Signatur ungültig, sobald das Signing-Zertifikat abläuft — rückwirkend für jede jemals damit signierte Software. Mit Zeitstempel bleibt die Signatur gültig, weil belegt ist, dass das Zertifikat zum Signaturzeitpunkt gültig war. Der Ablauf spielt dann keine Rolle mehr. Deshalb ist der Timestamp Pflicht, nicht Kür.
Muss der Codesigning-Schlüssel wirklich ins HSM?
Bei öffentlichen Codesigning-Zertifikaten ist Hardware-Schutz seit den verschärften CA/Browser-Forum-Regeln 2023 faktisch Pflicht. Bei einer internen CA ist es gesunder Menschenverstand: Ein exportierbarer Signing-Key, besonders auf einem Build-Server, ist ein Totalschaden mit Ansage. Der Schlüssel gehört ins HSM und wird nur über eine API zum Signieren genutzt.
Was passiert, wenn mein Signing-Key kompromittiert wird?
Ein Angreifer kann dann Malware mit deinem Zertifikat signieren, die von jedem Gerät, das deiner CA vertraut, als legitime Software akzeptiert wird. Das ist kein gewöhnlicher IT-Vorfall, sondern ein Reputationsschaden, weil deine Signatur ihre Glaubwürdigkeit verliert. Genau deshalb sind HSM-Schutz, Vier-Augen-Freigabe und lückenloses Audit nicht verhandelbar.
Darf meine Build-Pipeline automatisch signieren?
Davon ist dringend abzuraten. Ein Pipeline-Account mit automatischem Signierrecht hebelt das Vier-Augen-Prinzip aus und baut einen vollautomatischen Weg, kompromittierten Code zu signieren. Trenne die Rolle „Build erstellen“ strikt von der Rolle „Signatur freigeben“, und mach die Freigabe zu einem bewussten, dokumentierten menschlichen Schritt.
Nächste Schritte mit boddenberg.de
Codesigning ist der Bereich, in dem ein einziger Konfigurationsfehler — ein exportierbarer Schlüssel, eine fehlende Freigabe — aus einem Komfort-Feature ein existenzielles Risiko macht. Bevor das passiert, lohnt sich ein prüfender Blick:
ADCS-Health-Check · Standortbestimmung deiner bestehenden PKI — inklusive Prüfung, ob Codesigning sauber getrennt ist, der Signing-Schlüssel nicht exportierbar im HSM liegt und Timestamps gesetzt werden.
Architektur- oder Redesign-Workshop · Vom Ist-Zustand zur Zielarchitektur — hier fokussiert auf den Aufbau einer getrennten, gehärteten Codesigning-Hierarchie mit sauberem Freigabe-Workflow.
Implementierungs- oder Migrationsbegleitung · Beratung und technische Unterstützung beim Umsetzen — von der HSM-Integration bis zum Vier-Augen-Signaturprozess mit lückenlosem Audit.
|
Passend zum Thema Die HSM-Auswahl, die für eine Codesigning-CA besonders zählt, vergleicht Spoke 3.3 — von YubiHSM bis Thales und Utimaco. Mehr zum großen Bild rund um PKI in Microsoft-Umgebungen steht im in Arbeit befindlichen Buch „PKI und Zertifikate in modernen Microsoft-Umgebungen“. |
|---|
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund