In den letzten Jahren hat sich die Art und Weise, wie wir CSR (Certificate Signing Request) erzeugen, grundlegend verändert.
Noch vor einigen Jahren war ein CSR eines der unproblematischsten Elemente des Zertifikatausstellungsprozesses – eine einfache Textdatei, in der man die Domain und optional Unternehmensdaten eingeben, einen Schlüssel generieren musste – und das war’s.
Heute, im Jahr 2025, ist der CSR ein kritischer Punkt im Zertifizierungsprozess – ein Element, das die Sicherheit der gesamten PKI-Infrastruktur direkt beeinflusst und in der Praxis darüber entscheidet, ob ein Zertifikat ausgestellt wird oder nicht.

Denn geändert haben sich:

• die CA/B-Forum-Standards,
• die kryptografischen Algorithmen,
• die Art der Datenvalidierung,
• die Anforderungen moderner Browser,
• die Gültigkeitszeiträume von Zertifikaten,
• und sogar die Art und Weise, wie CSR-Daten von Automatisierungssystemen, Load Balancern und CT-Logs interpretiert werden.

Als Ergebnis ist CSR Hardening zu einer Pflicht geworden – nicht zu einer Option.

CSR im Jahr 2025: Vom einfachen Formular zum Sicherheitselement.

Die größte Veränderung besteht darin, sich von simplen, historischen Regeln zu verabschieden und zu einem Modell überzugehen, in dem ein CSR kryptografische, prozedurale und Compliance-Standards erfüllen muss. Viele Administratoren erinnern sich noch an die Zeiten, in denen es genügte: „CN eingeben, Enter drücken und fertig.“ Heute sind die Anforderungen unvergleichlich strenger.

Es genügt einer der folgenden Fehler, damit eine CA den CSR ablehnt oder das Zertifikat einfach nicht korrekt funktioniert:

• fehlender SAN-Eintrag,
• veralteter Algorithmus,
• ungeeignete Schlüssellänge,
• Vorhandensein des OU-Feldes,
• Unternehmensdaten stimmen nicht mit dem Register überein,
• CSR mit einer veralteten OpenSSL-Version erstellt (z. B. 1.0.2),
• falsch konfigurierte Extensions.

Jeder dieser Punkte kann den Validierungsprozess stoppen – selbst wenn das Zertifikat korrekt bestellt und bezahlt wurde.

Das Herzstück des CSR Hardening ist die Kryptografie – und dort haben sich die größten Veränderungen vollzogen.

Im Jahr 2025 entfernt sich die Zertifikatswelt zunehmend von RSA 2048. Es ist weiterhin zulässig, aber seine Nutzung in neuen Projekten gilt inzwischen als konservativ und nicht als moderne Best Practice. RSA 3072 wird immer häufiger als Mindeststandard angesehen, während RSA 4096 in sicherheitskritischen Sektoren eingesetzt wird. Doch RSA ist nicht die Zukunft. Der moderne Standard – sowohl bei Zertifikaten als auch bei CSR – heißt ECDSA.

Warum?
Weil ECDSA deutlich kürzere Schlüssel (P-256, P-384), geringere CPU-Belastung, schnellere Handshakes und – mit Blick auf die Post-Quantum-Kryptografie – eine wesentlich bessere Vorbereitung auf hybride Signaturmodelle bietet.

Das bedeutet jedoch nicht, dass ECDSA bedenkenlos eingeführt werden kann. Viele Geräte, Anwendungen, eingebettete Systeme und IoT-Plattformen unterstützen ECDSA noch immer nicht vollständig. In solchen Umgebungen bewährt sich das Dual-Cert-Modell, bei dem beide Algorithmen parallel unterstützt werden.

SAN ist zum Fundament geworden – CN hat heute nur noch historische Bedeutung.

Die größte strukturelle Veränderung bei CSR ist der Übergang zu einem Modell, in dem der CN-Feldwert seine Bedeutung verloren hat. Früher genügte ein CN=domain.de. Heute prüfen Browser ausschließlich das Feld SAN (Subject Alternative Name).

Fehlender SAN-Eintrag bedeutet:

• das Zertifikat kann ausgestellt werden,
• aber Chrome, Firefox, Safari und Edge werden es als ungültig einstufen.

Dies ist die häufigste Fehlerquelle – besonders in Hosting-Panels, die SAN nicht erzwingen oder es fehlerhaft implementieren.

Sicherheit des privaten Schlüssels – das am häufigsten vernachlässigte Element.

In Gesprächen mit Administratoren geht es oft darum, welche Felder im CSR eingetragen werden sollen. Viel seltener: wie der private Schlüssel abgesichert werden sollte. Dabei ist gerade der private Schlüssel das kritischste Element: Sein Diebstahl bedeutet vollständige Übernahme der Domain-Identität.

Aus unserer Praxis sehen wir häufig Fehler wie:

• Schlüssel im Hosting-Panel generiert (unklare Entropie),
• Schlüssel im public_html/private_html-Verzeichnis gespeichert,
• Dateirechte 644 oder 664,
• Schlüssel zwischen Servern kopiert,
• Schlüssel per FTP verteilt,
• Schlüssel per E-Mail versendet (!).

In modernen Sicherheitsarchitekturen sollte der private Schlüssel lokal generiert, mit Rechten 600 gespeichert und idealerweise über Prozessisolierung (separate PHP-FPM-Pools, getrennte Linux-Benutzer) oder sogar über ein HSM geschützt werden.

Case Studies – reale Probleme durch fehlerhafte CSR.

1. Großer E-Commerce-Shop – 7 Stunden Ausfall durch fehlenden SAN.

Eine Agentur, die mehrere große Onlineshops betreut, erneuerte ein DV-Zertifikat über ein Hosting, das CSR automatisch erzeugt. Das Panel zeigte SAN an, fügte es aber tatsächlich nicht ein. Die CA lehnte den CSR mehrfach ab.

Erst nach Analyse des CSR wurde klar:

• SAN fehlte vollständig,
• OU wurde automatisch eingefügt,
• Signaturalgorithmus war SHA-1 (!),
• Schlüssel war nur 2048 Bit und über den Browser generiert.

Nach Erstellung eines korrekten CSR war das Zertifikat in drei Minuten ausgestellt – aber der Shop hatte bereits signifikante Umsatzeinbußen.

2. OV-Zertifikat vier Tage blockiert wegen abgekürztem Firmennamen.

Ein SaaS-Unternehmen wartete vier Tage auf ein OV-Zertifikat.
Der Grund: eine scheinbar kleine Abweichung:

CSR: „TechCloud Systems“
Handelsregister: „TechCloud Systems Spółka z ograniczoną odpowiedzialnością“

Für die CA ist das keine Kleinigkeit – es ist ein vollständiger Datenfehler. Der CSR wurde abgelehnt und der Validierungsprozess neu gestartet.

3. Zu aggressive ECDSA-Einführung – 18 % der Nutzer ohne Zugang.

Ein MedTech-Startup migrierte vollständig auf ECDSA. Technisch perfekt – schnelle Handshakes, geringere CPU-Last. Praktisch jedoch unterstützten 18 % der IoT-Geräte der Patienten kein ECDSA. Erst ein Dual-Cert-Setup (RSA + ECDSA) stellte die Kompatibilität wieder her.

Schlüsselelemente eines korrekten CSR im Jahr 2025:

• SAN ist obligatorisch,
• OU darf nicht enthalten sein,
• RSA 3072 oder ECDSA P-256/P-384,
• OpenSSL 3.x für künftige Kompatibilität,
• Firmendaten müssen dem Register 1:1 entsprechen,
• privater Schlüssel lokal generiert und abgesichert.

CSR HARDENING 2025 ist das Fundament zukunftssicherer Sicherheit.

Mit kürzer werdenden Zertifikatslaufzeiten und dem Übergang zu automatisierten Modellen (ACME, kurzlebige Zertifikate, PQC-Hybride) werden CAs und Browser immer weniger tolerant gegenüber Fehlern. Zertifikate sind der „Treibstoff“ moderner Infrastrukturen – aber der CSR ist das Sicherheitsventil, das fehlerfrei funktionieren muss.

Unternehmen, die CSR Hardening jetzt implementieren, bereiten sich auf:

• Algorithmuswechsel,
• verkürzte Erneuerungszyklen,
• Automatisierung,
• Post-Quantum-TLS,
• vollständige CA/B-Forum-Konformität

vor.

Wer an alten Verfahren festhält, wird alle 90 Tage denselben Albtraum erleben: abgelehnter CSR, fehlerhaftes Zertifikat und plötzlich „Warum funktioniert SSL nicht?“.

PQC und die Zukunft von CSR – was die Post-Quantum-Kryptografie verändern wird.

Obwohl die meisten Administratoren CSR noch immer im Kontext von RSA oder ECDSA betrachten, findet im Hintergrund eine viel größere Veränderung statt: die Vorbereitung der Zertifikatsinfrastruktur auf Post-Quantum-Kryptografie (PQC). Das NIST hat die ersten quantenresistenten Algorithmen standardisiert – darunter CRYSTALS-Kyber (KEM) und Dilithium (digitale Signatur). Dies bedeutet, dass das gesamte TLS-Ökosystem – Server, Browser, CAs, Load Balancer – sich grundlegend weiterentwickeln muss. Anders als beim Übergang von SHA-1 auf SHA-256 betrifft die Änderung diesmal die Struktur der Schlüssel und Signaturen selbst – einschließlich CSR.

Hybride Zertifikate, die zwei Algorithmen enthalten, werden bald Standard:

• einen klassischen (ECDSA oder RSA),
• einen quantenresistenten (Kyber).

Was bedeutet das für CSR?

Der zentrale Punkt lautet: CSR müssen mit Bibliotheken erzeugt werden, die hybride Strukturen unterstützen.
OpenSSL 1.x wird niemals PQC-fähig sein – vollständige Unterstützung beginnt erst mit OpenSSL 3.x.

Zukünftige CSRs werden enthalten:

1. zwei Schlüsselparameter-Sets – klassisch und quantenresistent,
2. erweiterte KeyUsage-Definitionen für PQC-Signaturen,
3. neue KEM-Strukturen (Key Encapsulation Mechanism),
4. deutlich größere CSR-Header aufgrund der PQC-Schlüsselgrößen.

Das ist keine Theorie – CAs testen PQC bereits aktiv, und Unternehmen wie Google, DigiCert und Cloudflare führen PQC-Experimente in der Produktion durch. Die CSR der Zukunft wird kein einfaches „req“-File mehr sein, sondern ein multi-algorithmischer Container, der klassische ECDSA- und PQC-Strukturen kombiniert. Daher lautet die wichtigste Regel für zukunftssicheres CSR Hardening: Erstelle CSRs immer mit modernen OpenSSL-Versionen – sonst wirst du sie 2026–2028 ohnehin neu erstellen müssen.

Die häufigsten CSR-Mythen, die reale Probleme verursachen.

Trotz massiver Veränderungen der TLS-Standards halten sich viele veraltete CSR-Mythen hartnäckig – vor allem, weil viele Online-Anleitungen 10-15 Jahre alt sind. Diese Mythen führen zu Fehlern, abgelehnten Zertifikaten und Sicherheitsvorfällen.
Sie müssen endgültig ausgeräumt werden.

Mythos 1: „Der CN ist das wichtigste Feld im CSR.“

Falsch. Der CN ist ein historisches Feld. Seit 2017 ignorieren Browser den CN im Rahmen der Domainvalidierung. SAN ist das einzige relevante Feld.

Mythos 2: „RSA 2048 ist sicher und ausreichend.“

War es – im Jahr 2012. Im Jahr 2025 ist RSA 2048 nur noch das Minimum, nicht die Empfehlung.

Mythos 3: „OU kann man drinlassen, es ist nur informativ.“

OU ist deprecated, wird nicht validiert und führt häufig zu Ablehnungen bei OV/EV.

Mythos 4: „CSR kann man einfach im Hosting-Panel erzeugen.“

Nein. Viele Panels:

• erzwingen RSA 2048 trotz anderer Auswahl,
• lassen SAN weg,
• verwenden veraltetes OpenSSL,
• fügen OU automatisch ein,
• nutzen noch SHA-1 (!).

Mythos 5: „Der private Schlüssel ist nicht so wichtig, entscheidend ist doch das Zertifikat“.

Das ist der gefährlichste Mythos. Ein Zertifikat kann in 2–5 Minuten ersetzt werden. Der private Schlüssel ist jedoch ein einzigartiges Element – sein Verlust bedeutet die vollständige Kompromittierung der Domain-Identität.

Mythos 6: „CSR kann zusammen mit dem Schlüssel zwischen Servern übertragen werden“.

Technisch ist es möglich, aber es ist absolut verboten. Der Schlüssel sollte nur an einem einzigen Ort existieren. In der Praxis entstehen viele Sicherheitsvorfälle genau dadurch, dass Schlüssel zwischen Umgebungen, Testsystemen, Staging-Servern, Entwicklerrechnern oder sogar Cloud-Backups kopiert werden.

Mythos 7: „CSR hat keinen Einfluss auf TLS-Kompatibilität und Geräteunterstützung“.

Doch – und zwar erheblich. Wenn du im CSR ECDSA erzwingst, funktioniert ein ECDSA-Zertifikat auf älteren Geräten nicht. Entscheidest du dich für RSA 4096, werden einige Embedded-Systeme oder ältere Browser den Handshake ablehnen. Der CSR beeinflusst direkt, ob deine Website für bestimmte Nutzer erreichbar ist.

Mythos 8: „CSR hat nichts mit PQC zu tun“.

Doch – denn der CSR definiert das Format und die Struktur des Schlüssels, der jetzt und in Zukunft verwendet wird. Wenn du heute CSRs mit Tools erzeugst, die moderne kryptografische Bibliotheken nicht unterstützen, wirst du die gesamte Migration in naher Zukunft wiederholen müssen.

Wenn Sie Fragen zu SSL-Zertifikaten oder Cybersecurity-Lösungen haben, kontaktieren Sie unseren Vertrieb.