Der richtige Zeitpunkt zur Erstellung eines CSR: Ein Leitfaden für intelligenteres Zertifikatsmanagement

Wer beruflich Zertifikate verwaltet, hat unzählige Zertifikatsignierungsanfragen (CSRs) erstellt – wahrscheinlich ohne groß über den Zeitpunkt nachzudenken. Eine CSR gehört zu den Routineaufgaben: Man benötigt ein Zertifikat, erstellt eine Anfrage, reicht sie bei einer Zertifizierungsstelle (CA) ein und fertig. Doch genau dieser Moment der CSR-Erstellung bietet die beste Gelegenheit, die Unternehmensrichtlinien durchzusetzen. Schlüssellänge, Signaturalgorithmus und die in jedem Zertifikat enthaltenen Identitätsfelder werden bereits festgelegt, bevor die CA die Anfrage überhaupt zu Gesicht bekommt.

Wenn Timing und Details stimmen, entsprechen Ihre Zertifikate den Richtlinien und bestehen Audits problemlos. Liegen sie falsch, erben Sie ein Gewirr aus inkonsistenten Schlüsseln, nicht übereinstimmenden Algorithmen und Zertifikaten, die im ungünstigsten Moment stillschweigend die Validierung verweigern. Anstatt die CSR- Generierung also nur als lästige Pflicht zu betrachten, lohnt es sich, genau zu wissen, wann Sie eine benötigen und welche Best Practices jeweils gelten. Genau darum geht es in diesem Leitfaden.

Was ist ein CSR?

Bevor wir uns mit dem Zeitpunkt befassen, ist es wichtig, genau zu definieren, was ein CSR (Certificate Signing Request) ist, da sich das „Wann“ aus dem „Was“ ergibt. Ein CSR umschließt eine Anfrage mit einem öffentlichen Schlüssel, der üblicherweise gleichzeitig mit einem neuen Schlüsselpaar erstellt wird. Er kann aber genauso gut aus einem bereits vorhandenen privaten Schlüssel erstellt werden (der Unterschied zwischen einer „Neuschlüsselung“ und einer einfachen „Erneuerung“). In jedem Fall ist der öffentliche Schlüssel zusammen mit Ihren Identitätsdaten, dem Common Name (CN), allen Subject Alternative Names (SANs) und Organisationsfeldern wie Firma, Ort und Land in der Anfrage enthalten. Der private Schlüssel verlässt Ihr System niemals. Die Anfrage wird anschließend mit diesem privaten Schlüssel signiert. Dadurch weisen Sie der Zertifizierungsstelle (CA) nach, dass Sie tatsächlich im Besitz des Schlüssels sind, dessen Zertifizierung Sie beantragen.

Diese Signatur wird oft übersehen, doch sie verhindert, dass ein Angreifer einen kopierten öffentlichen Schlüssel entwendet und ein Zertifikat anfordert, auf das er keinen Anspruch hat. Da der private Schlüssel stets auf Ihrem Rechner verbleibt, ist es von enormer Bedeutung , wo und wie Sie die CSR generieren .

In der Praxis erfolgt der Rest in zwei Schritten. Zunächst haben Sie nach der Generierung der Anfrage die Möglichkeit, den Inhalt zu korrigieren: SANs verdienen besondere Aufmerksamkeit, da moderne Browser und Clients diese anstelle des Common Name verwenden. Eine Anfrage mit falschen oder fehlenden SANs kann einen produktiven Dienst lahmlegen, selbst wenn ansonsten alles einwandfrei funktioniert. Dies ist Ihre einzige Chance, sicherzustellen, dass die Anfrage zugelassene Algorithmen verwendet und den Konventionen Ihrer übrigen Infrastruktur entspricht. Im zweiten Schritt übernimmt die Zertifizierungsstelle (CA): Sie prüft die Details, signiert die Anfrage und stellt ein Zertifikat aus, das Ihren öffentlichen Schlüssel mit der von Ihnen angegebenen Identität verknüpft. Eine fehlerhafte Anfrage, ein veralteter Algorithmus oder ein leeres Feld führen entweder zur Ablehnung oder, schlimmer noch, zur Ausstellung eines Zertifikats, das Ihre Sicherheits- und Compliance-Vorgaben nicht erfüllt. Sobald Sie das Zertifikat erhalten haben, stellen Sie es bereit und schützen Sie den zugehörigen privaten Schlüssel. Das Zertifikat selbst ist öffentlich, der private Schlüssel jedoch das Geheimnis, das geschützt werden muss. Testen Sie das Schlüsselpaar anschließend anhand Ihrer Richtlinien, bevor es live geht.

Wenn Sie einen neuen Kundendienstmitarbeiter benötigen

Ein neuer CSR entsteht nie planmäßig, sondern wird durch konkrete Ereignisse erfordert. Diese Ereignisse lassen sich grob in drei Kategorien einteilen, und die Kenntnis der jeweiligen Kategorie verrät sofort, ob ein neues Schlüsselpaar ansteht.

Die Erschaffung einer neuen Identität

Dies ist die Familie, die den meisten Menschen als erstes in den Sinn kommt. Der deutlichste Fall ist die Einrichtung eines komplett neuen Dienstes, eines Webservers, eines VPN-Gateways, einer internen API oder eines Load Balancers, bei dem kein bestehendes Schlüsselpaar vorhanden ist, das übernommen werden könnte – man beginnt also bei null. Die Anforderung eines öffentlichen TLS-Zertifikats von einer Zertifizierungsstelle wie DigiCert oder Let's Encrypt dient als Ausgangspunkt für die CSR-Anforderung. Protokollieren Sie jede neue Anforderung sofort nach ihrer Erstellung in Ihrem Inventar, damit Sie später nicht von der Gültigkeitsdauer überrascht werden.

Zwei weniger offensichtliche Mitglieder derselben Familie sind Geräte und Pipelines. Vernetzte Hardware erstellt üblicherweise während der Herstellung oder Bereitstellung selbst einen CSR (Certificate Signing Request) und generiert so vom ersten Start an eine eigene Identität. Ein vernetzter medizinischer Sensor muss beispielsweise einen CSR vorlegen und ein Identitätszertifikat einholen, bevor er überhaupt in ein Krankenhausnetzwerk eingebunden wird. DevOps-Pipelines befinden sich am anderen Ende der Lebensdauerskala und nutzen Protokolle wie ACME ( Automated Certificate Management Environment ) und EST (Enrollment over Secure Transport), um selbstständig CSRs und kurzlebige Zertifikate zu erstellen. Unabhängig davon, ob das Zertifikat fünf Jahre oder fünf Minuten gültig ist und ob es von einem Menschen oder einem Kubernetes-Controller angefordert wird, bleibt die Regel unverändert: Keine neue Identität ohne zugehörigen CSR.

Aktualisierung von Schlüsseln und Härtungsalgorithmen

Die zweite Kategorie betrifft Zertifikate, die zwar bereits existieren, aber nicht unverändert weitergeführt werden sollten. Kurz vor Ablauf eines Zertifikats wird es entweder außer Betrieb genommen oder erneuert. Eine sinnvolle Vorgehensweise ist, den Schlüssel gleichzeitig zu aktualisieren, anstatt den alten wiederzuverwenden. Eine Erneuerung mit einem neuen Schlüsselpaar erfordert zwangsläufig einen neuen CSR (Certificate Signing Request). Die Wiederverwendung desselben Schlüssels erhöht lediglich das Risiko, falls dieser kompromittiert wird. Neuer CSR, neuer privater Schlüssel – das ist der Sinn der Rotation. Und wenn ein Schlüssel bei einem Sicherheitsvorfall auftaucht, sollte nicht bis zum Ablaufdatum gewartet werden; alle betroffenen Dokumente sollten sofort neu ausgestellt werden – das ist die kryptografische Entsprechung zum Austauschen der Schlösser, nachdem man seine Schlüssel verloren hat.

Rotation betrifft jedoch nicht nur den Kalender. Algorithmen veralten mit fortschreitender Kryptoanalyse und sinkenden Kosten für Rechenleistung. Was vor zehn Jahren noch sicher schien, wirkt heute unsicher. Die Übertragung eines Zertifikats auf einen stärkeren Algorithmus oder einen längeren Schlüssel ändert den öffentlichen Schlüssel, was ein neues Zertifikatsanforderungsschreiben (CSR) für das aktualisierte Zertifikat erfordert. Dies wird mit der Abschaffung schwacher Algorithmen immer häufiger vorkommen. Ein Beispiel hierfür ist die Post-Quanten-Kryptographie (PQC). Die Bedrohung ist spezifisch: Ein ausreichend leistungsfähiger Quantencomputer, der Shors Algorithmus ausführt, würde die heutigen Public-Key-Algorithmen RSA , ECDSA und Diffie-Hellman, die den Schlüsselaustausch und Signaturen sichern, knacken. Symmetrische Verschlüsselungsverfahren wie AES und moderne Hash-Funktionen werden hingegen nur geschwächt und bleiben mit größeren Parametern wie AES-256 sicher. Und PQC ist nicht länger Theorie: Das NIST finalisierte im August 2024 seine ersten drei Post-Quanten-Standards ( FIPS 203 /ML-KEM für die Schlüsselerzeugung sowie FIPS 204/ML-DSA und FIPS 205/SLH-DSA für Signaturen), sodass quantenresistente Algorithmen bereits heute eingesetzt werden können. In Verbindung mit dem Risiko, Daten erst zu erfassen und später zu entschlüsseln – also Daten, die heute erfasst werden, könnten entschlüsselt werden, sobald die Hardware ausgereift ist –, ist eine frühzeitige Bestandsaufnahme und Migration deutlich schonender als das Abwarten, bis man dazu gezwungen wird.

Vertrauen nach Veränderungen wiederherstellen

Die dritte Kategorie wird von Teams oft übersehen, bis sie unmittelbar bevorsteht: die Änderung der Vertrauensgrundlage selbst. Wechselt man von einer Zertifizierungsstelle zu einer anderen oder migriert die PKI von On-Premises in die Cloud, verschiebt sich die Hierarchie unter jedem Zertifikat. Jedes unter der alten Hierarchie ausgestellte Zertifikat muss neu beantragt werden, um das Vertrauen wiederherzustellen – das bedeutet jeweils eine CSR (Certificate Signing Request). Die größte Gefahr besteht darin, den Überblick über die vorhandenen Zertifikate zu verlieren. Daher sollten vor einer Migration dieser Größenordnung alle bestehenden Zertifikate erfasst und anschließend so schnell wie möglich neu ausgestellt werden. Die Neuausstellung sollte dabei automatisiert erfolgen, anstatt dass jemand mühsam Tabellenkalkulationen manuell durchgeht.

Wo die CSR-Generierung tendenziell schiefgeht

Da ein Kundendienstmitarbeiter so viele Informationen für die Wirtschaftsprüfer bereithält, können kleine Fehler weitreichende Folgen haben. Einige wiederkehrende Probleme sollten daher beachtet werden.

Fehlende oder fehlerhafte SANs stehen weit oben auf der Liste. Da Clients ihre Zertifikate mittlerweile anhand der SANs validieren, kann eine Anfrage, die diese auslässt oder die falschen SANs angibt, zu Ausfällen führen, deren Diagnose extrem aufwendig ist. Die automatisierte CSR-Erstellung über eine Zertifikatsverwaltungsplattform beseitigt Tippfehler und sorgt für einheitliche Vorlagen, sodass die korrekten Namen stets vorhanden sind.

Hinzu kommt die Vielzahl inkonsistenter, nicht standardisierter PKI-Systeme. Verschiedene Teams generieren CSRs auf ihre eigene Weise, manche Tools verwenden standardmäßig veraltete Algorithmen, und plötzlich fallen Ihre Zertifikate ohne ersichtlichen Grund bei Compliance-Audits durch. Standardisierte Vorlagen beheben dieses Problem, indem sie sicherstellen, dass alle Zertifikate mit denselben genehmigten Algorithmen, Namenskonventionen und Organisationsdetails anfordern. Dadurch werden Audits schneller und kostengünstiger.

Unsichere Schlüsselspeicherung ist ein stiller Killer. Sobald ein privater Schlüssel auf einem gemeinsam genutzten Build-System erstellt oder aus Bequemlichkeit zwischen verschiedenen Rechnern hin und her übertragen wird, geben Sie die Kontrolle darüber effektiv an jeden ab, der Zugriff auf diese Systeme hat. Schlüssel sollten in dem System erstellt und gespeichert werden, das sie verwendet, idealerweise geschützt durch ein Hardware-Sicherheitsmodul (HSM), einen Schlüsseltresor oder eine sichere Umgebung. Betrachten Sie 2048-Bit-RSA eher als Mindeststandard denn als Ziel: Laut NIST- Richtlinien ist diese Sicherheitsstufe nur bis etwa Ende des Jahrzehnts ausreichend. Für alles, was längerfristig genutzt werden soll, ist 3072-Bit-RSA oder ein elliptischer Kurvenschlüssel wie P-256 die bessere Wahl. Der CSR selbst benötigt keine solche Geheimhaltung, da er nur den öffentlichen Schlüssel und Ihre Subjektdaten enthält; der private Schlüssel ist das zu schützende Gut.

Letztendlich ist die manuelle CSR-Generierung einfach nicht skalierbar. Ohne Automatisierung werden Verlängerungsanträge zu spät erstellt, und die Teams geraten in Panik, um vor Ablauf der alten Zertifikate Ersatzzertifikate bereitzustellen – genau die Art von Hektik, die zu Ausfällen führt. Die Erfassung jedes Zertifikats und seines Ablaufdatums auf einer automatisierten Plattform sowie die Verwendung von Protokollen wie ACME oder EST zur Generierung von CSRs in großem Umfang beseitigen diese Panik.

Wo CSR in einem ausgereiften Zertifikatsprogramm seinen Platz hat

Man könnte meinen, ein Zertifikatsanforderungsbericht (CSR) sei eine einmalige Angelegenheit, doch er steht am Anfang eines nie endenden Lebenszyklus. Jedes Zertifikat muss beantragt, ausgestellt, in einem Verzeichnis erfasst, an den jeweiligen Einsatzorten bereitgestellt, vor Ablauf verlängert und schließlich außer Betrieb genommen werden. Die meisten Unternehmen verwalten Zehntausende, manchmal sogar weit mehr Zertifikate. Falsch verwaltete Zertifikate sind eine Hauptursache für Ausfälle und Sicherheitslücken, und die Kosten summieren sich schnell.

Die Generierung von Zertifikatssperrlisten (CSRs) ist deshalb so wichtig, weil sie den frühesten und einfachsten Weg bietet, Governance-Richtlinien durchzusetzen. Schlüssellänge, Algorithmus und Identitätsfelder werden bereits vor der Zertifikatserstellung festgelegt. Eine korrekte CSR erhöht die Wahrscheinlichkeit, dass das resultierende Zertifikat Audits besteht und im Produktivbetrieb einwandfrei funktioniert. Discovery und Inventory zeigen den vorhandenen Bestand an; CSRs bilden den Ausgangspunkt für alle Neuerungen. Ausgereifte Systeme machen die CSR-Erstellung zu einem automatisierten, richtlinienbasierten Schritt, der nahtlos in Ausstellung, Bereitstellung, Verlängerung und Widerruf integriert ist – anstatt zu einer manuellen Aufgabe, die jedes Team eigenständig erledigt.

Wie könnte eine Verschlüsselungsberatung helfen?

CertSecure Manager von Encryption Consulting ist eine herstellerneutrale Lösung für das Zertifikatslebenszyklusmanagement, die Erkennung, Automatisierung, Registrierung, Richtliniendurchsetzung und Integrationen zentral vereint. Die CSR-Generierung wird standardisiert und automatisiert, sodass jede Anfrage die korrekten Algorithmen, SANs und Identitätsfelder enthält. Dadurch werden Inkonsistenzen vermieden, die häufig zu Problemen bei Audits führen. Durch die Automatisierung von Verlängerungen werden Ausfälle aufgrund unbemerkt ablaufender Zertifikate verhindert. Die rollenbasierte Zugriffskontrolle stellt sicher, dass private Schlüssel und Anfragen nur von autorisierten Personen eingesehen werden können. Ob Sie öffentliche oder private Zertifizierungsstellen oder beides verwalten – CertSecure Manager bietet Ihnen eine einheitliche, skalierbare Plattform für konsistente Zertifikatsprozesse vom ersten CSR bis zum endgültigen Widerruf.

Weitere Informationen zu CertSecure Manager finden Sie hier :

Weitere Informationen zu unseren Produkten und Dienstleistungen finden Sie unter: Hier

Fazit

Die Erstellung einer CSR ist zwar nicht der glamouröseste Teil Ihrer Arbeit, aber einer der wichtigsten. Sobald Sie diese Anfrage stellen, entscheiden Sie, ob ein Zertifikat Ihren Sicherheitsrichtlinien entspricht oder sich stillschweigend davon entfernt. Zu wissen, wann eine neue CSR wirklich erforderlich ist (z. B. für neue Dienste, Schlüsselerneuerungen, Algorithmus-Upgrades, CA-Migrationen, DevOps- Workloads und die Gerätebereitstellung), bedeutet, dass Sie den Lebenszyklus proaktiv gestalten, anstatt nur darauf zu reagieren.

Organisationen, die dies erfolgreich handhaben, erstellen CSRs nicht manuell und hoffen auf das Beste. Sie haben die CSR-Generierung zu einem standardisierten, automatisierten und richtlinienbasierten Prozess gemacht, unterstützt durch sichere Schlüsselverwaltung, konsistente Vorlagen und vollständige Transparenz über jedes ihrer Zertifikate. Angesichts immer kürzerer Zertifikatslebensdauern und der zunehmenden Migration zu Post-Quanten-Algorithmen gewinnt diese Vorgehensweise immer mehr an Bedeutung. Behandeln Sie den einfachen CSR als den Richtlinien-Checkpoint, der er ist, und Ihre übrige Zertifikatsverwaltung wird deutlich einfacher.