CSR (Certificate Signing Request) verständlich erklärt

Ein CSR (Certificate Signing Request, zu Deutsch: Zertifikatsanforderung) ist eine verschlüsselte Textdatei, die von einem Webmaster auf seinem Server generiert wird, um ein SSL/TLS-Zertifikat bei einer Zertifizierungsstelle (Certificate Authority, kurz CA, wie Let’s Encrypt, DigiCert oder Sectigo) zu beantragen.

Die Erstellung eines CSRs ist der erste und wichtigste Schritt im Prozess der Absicherung einer Website mittels HTTPS. Ohne einen validen CSR kann keine Zertifizierungsstelle ein digitales Zertifikat ausstellen, das von Webbrowsern als vertrauenswürdig eingestuft wird.

---

Wie der Zertifizierungsprozess funktioniert (PKI)

Der gesamte SSL-Prozess basiert auf der Public-Key-Infrastruktur (PKI) und asymmetrischer Kryptografie (Verwendung eines Schlüsselpaares).

[ Ihr Webserver ] ──(Generiert)──> [ Private Key ] (Bleibt auf dem Server)
        │
        ├────────────────────────> [ Public Key ]  ──┐
        │                                           ├─> [ CSR-Datei ] ──> [ Zertifizierungsstelle (CA) ]
        └───────(Identitätsdaten hinzufügen)────────┘

Der Ablauf im Detail:

1. Schlüsselpaar generieren: Auf dem Webserver wird ein privater Schlüssel (Private Key) und ein dazugehöriger öffentlicher Schlüssel (Public Key) erzeugt.
2. Identitätsdaten hinzufügen: Der Webmaster gibt Identitätsdaten an (z. B. den Domainnamen und das Land).
3. CSR erstellen: Der Server bündelt den öffentlichen Schlüssel und die Identitätsdaten in einer Datei (dem CSR) und signiert diesen Block mit dem privaten Schlüssel, um die Echtheit zu belegen.
4. Einreichung bei der CA: Der Webmaster sendet den CSR (niemals den privaten Schlüssel!) an die Zertifizierungsstelle.
5. Validierung & Ausstellung: Die CA prüft, ob dem Antragsteller die Domain wirklich gehört (z. B. über einen DNS-TXT-Eintrag). Nach erfolgreicher Prüfung signiert die CA den öffentlichen Schlüssel und sendet das fertige SSL-Zertifikat zurück.
6. Installation: Das Zertifikat wird zusammen mit dem privaten Schlüssel auf dem Webserver installiert.

---

Welche Angaben enthält ein CSR?

Ein CSR wird im standardisierten PEM-Format ausgegeben, das durch die Zeilen -----BEGIN CERTIFICATE REQUEST----- und -----END CERTIFICATE REQUEST----- gekennzeichnet ist. Dahinter verbirgt sich eine Base64-codierte ASN.1-Struktur mit folgenden Informationen:

• Common Name (CN): Der vollqualifizierte Domainname (FQDN), für den das Zertifikat gelten soll (z. B. allerate.com oder für Wildcard-Zertifikate *.allerate.com).
• Subject Alternative Names (SAN): Weitere alternative Domains, die ebenfalls durch dieses Zertifikat geschützt werden sollen.
• Organization (O): Der offizielle rechtliche Name des Unternehmens (wichtig bei Extended Validation (EV) und Organization Validation (OV) Zertifikaten).
• Organizational Unit (OU): Die Abteilung im Unternehmen (z. B. „IT-Security“).
• Locality (L): Die Stadt oder Gemeinde (z. B. „Zürich“).
• State or Province (S): Das Bundesland oder der Kanton (z. B. „Zürich“).
• Country (C): Der zweistellige Ländercode nach ISO 3166-1 (z. B. „CH“ für die Schweiz).
• Public Key: Der öffentliche Schlüssel, der zur Verschlüsselung der Datenverbindung verwendet wird.

---

Best Practices bei der CSR-Erstellung

• Mindestens RSA 2048 Bit verwenden: Verwenden Sie für die Schlüsselgenerierung eine Schlüssellänge von mindestens 2048 Bit (besser 4096 Bit) oder wechseln Sie auf die modernere ECDSA-Verschlüsselung (Elliptic Curve Cryptography), die bei kürzeren Schlüssellängen eine höhere Sicherheit und bessere Performance bietet.
• Private Key streng schützen: Wer Zugriff auf Ihren privaten Schlüssel hat, kann den Datenverkehr Ihrer Website entschlüsseln und manipulieren (Man-in-the-Middle-Angriff). Stellen Sie sicher, dass der private Schlüssel nur für den Webserver-Prozess (Nginx/Apache) lesbar ist (Rechte 600 unter Linux).
• Sonderzeichen vermeiden: Vermeiden Sie Umlaute (ä, ö, ü) oder spezielle Sonderzeichen in den Adressfeldern des CSR, da ältere Systeme oder Zertifizierungsstellen diese bei der Verarbeitung fehlerhaft interpretieren können.

---

CSR mit OpenSSL erstellen: ein Beispiel

Auf der Kommandozeile erzeugt ein einziger OpenSSL-Befehl gleichzeitig den privaten Schlüssel und den passenden CSR:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout allerate.key \
  -out allerate.csr \
  -subj "/C=CH/ST=Zürich/L=Zürich/O=Allerate/CN=allerate.com"

Das Ergebnis sind zwei Dateien: allerate.key (der private Schlüssel – bleibt geheim auf dem Server) und allerate.csr (die Anforderungsdatei – wird an die CA gesendet). Den Inhalt eines fertigen CSR prüfen Sie mit openssl req -in allerate.csr -noout -text, um vor dem Einreichen zu kontrollieren, ob Common Name und SAN-Einträge korrekt sind.

---

RSA vs. ECDSA: welcher Schlüsseltyp?

Bei der Schlüsselerzeugung stehen zwei gängige Verfahren zur Wahl. Die folgende Tabelle stellt sie gegenüber:

Eigenschaft	RSA	ECDSA
Typische Schlüssellänge	2048–4096 Bit	256–384 Bit
Sicherheitsniveau bei kurzer Länge	mittel	hoch
Rechenaufwand (TLS-Handshake)	höher	geringer
Kompatibilität mit Altsystemen	sehr hoch	gut, aber nicht universell
Empfehlung	breite Kompatibilität nötig	moderne Stacks, beste Performance

Faustregel: ECDSA mit P-256 bietet bei deutlich kürzeren Schlüsseln dieselbe Sicherheit wie RSA-3072 und entlastet den Server beim Verbindungsaufbau – ein spürbarer Vorteil für die Web-Performance. RSA bleibt sinnvoll, wenn sehr alte Clients bedient werden müssen. In beiden Fällen sichert das ausgestellte Zertifikat die Verbindung ab, die Sie zusätzlich per HSTS erzwingen sollten.

---

Validierungsstufen im Vergleich

Die Identitätsprüfung der CA bestimmt, wie schnell und mit welchem Aufwand ein Zertifikat ausgestellt wird:

Stufe	Prüfung	Dauer	Typischer Einsatz
DV (Domain Validation)	nur Domain-Kontrolle	Minuten	Blogs, kleine Websites, APIs
OV (Organization Validation)	Unternehmen + Domain	Tage	Firmen-Websites
EV (Extended Validation)	strenge rechtliche Prüfung	Tage–Wochen	Banken, Behörden

Für die allermeisten Projekte – inklusive E-Commerce – genügt heute ein kostenloses DV-Zertifikat von Let’s Encrypt, das sich vollautomatisch erneuern lässt. EV-Zertifikate bringen seit dem Wegfall der grünen Adressleiste im Browser kaum noch sichtbaren Mehrwert.

---

Typische CSR-Fehler und ihre Folgen

Fehler	Folge	Lösung
Umlaute in O/L/ST-Feldern	CA lehnt CSR ab	nur ASCII-Zeichen verwenden
Falscher Common Name	Browser-Warnung «Name stimmt nicht»	FQDN exakt angeben
www-Variante vergessen	nur eine Domain abgesichert	beide als SAN aufnehmen
Privaten Schlüssel verloren	Zertifikat unbrauchbar	CSR + Key neu erzeugen
Schlüssel < 2048 Bit	CA verweigert Ausstellung	mindestens RSA-2048 wählen

Der häufigste Stolperstein ist der vergessene www-Eintrag: Wer nur allerate.com als Common Name angibt, erhält bei www.allerate.com eine Zertifikatswarnung. Nehmen Sie deshalb beide Schreibweisen als SAN auf.

---

Praxisbeispiel: Zertifikat für eine neue Domain

Ein Unternehmen sichert seine neue Website ab:

• Falsch: Der Administrator erzeugt einen CSR nur mit CN=allerate.com, ohne SAN. Das Zertifikat wird ausgestellt, doch Besucher von www.allerate.com sehen eine Sicherheitswarnung und springen ab.
• Richtig: Der CSR enthält CN=allerate.com plus die SAN-Einträge allerate.com und www.allerate.com. Beide Schreibweisen sind abgesichert, und per 301-Weiterleitung wird zusätzlich eine kanonische Variante erzwungen.

Die Lehre: Ein CSR ist schnell erstellt, aber Common Name und SAN müssen exakt zu allen tatsächlich genutzten Hostnamen passen – sonst entstehen Vertrauenswarnungen, die Besucher kosten.

[!TIP] Die Erstellung eines CSRs über die Kommandozeile (z. B. mit OpenSSL) ist kompliziert und erfordert genaue Syntaxkenntnisse. Nutzen Sie den CSR Generator auf balou.tools, um Ihren privaten Schlüssel und die CSR-Anforderungsdatei schnell, fehlerfrei und sicher offline in Ihrem Browser erstellen zu lassen.