Worum geht’s
Bevor eine CA ein Zertifikat ausstellt, schickst du ihr einen CSR (Certificate Signing Request). Ist darin etwas falsch — falscher Common Name, fehlende SAN-Einträge, zu schwacher Schlüssel —, wird das Zertifikat unbrauchbar oder unsicher. Wer einen CSR vor dem Einreichen liest und prüft, spart sich Fehlausstellungen und Re-Issues. Dieser Skill macht aus dem X.509-Wissen eine konkrete Eingangskontrolle.
Konzept
Ein CSR ist ein PKCS#10-Objekt, base64-kodiert zwischen -----BEGIN CERTIFICATE REQUEST-----
und dem passenden END-Marker (PEM). Er enthält:
- Subject (DN): Distinguished Name mit Feldern wie
CN(Common Name),O,OU,C. Für Web-Zertifikate zählt heute nicht mehr der CN, sondern die SAN. - Subject Alternative Names (SAN): die eigentlich verbindliche Liste der Hostnamen
(
DNS:-Einträge). Moderne Browser ignorieren den CN — fehlt der Host in der SAN, schlägt die Validierung fehl. - Public Key: Typ und Stärke des öffentlichen Schlüssels (z. B. RSA 2048/4096 oder ECDSA P-256). Der private Schlüssel bleibt beim Antragsteller und ist nicht im CSR.
- Signatur: Der CSR ist mit dem privaten Schlüssel selbst signiert — das beweist, dass der Antragsteller den zum öffentlichen Schlüssel passenden privaten Schlüssel besitzt (Proof of Possession).
Prüf-Maßstäbe: RSA mindestens 2048 Bit (besser 3072/4096) oder eine moderne EC-Kurve; alle benötigten Hostnamen vollständig in der SAN; korrekte Organisation, wenn die CA das verlangt.
Ein CSR bündelt diese Felder, die später ins Zertifikat wandern:
- Subject / SAN — 35%
- Public Key — 30%
- Attribute / Extensions — 20%
- Signatur — 15%
Beispiel-Fall
Aufgabe: Ein Kollege hat einen CSR für shop.firma.de erzeugt; auch www.shop.firma.de
soll abgedeckt sein. Du prüfst vor dem Einreichen.
- CSR im Decoder einlesen und Subject ansehen: Steht der CN auf
shop.firma.de? - SAN prüfen — entscheidend: Sind beide Hosts (
shop.firma.deundwww.shop.firma.de) alsDNS:enthalten? Fehlt einer, wird das Zertifikat für ihn ungültig. - Schlüssel prüfen: RSA ≥ 2048 Bit oder EC? Ein 1024-Bit-Schlüssel wäre abzulehnen.
- Tippfehler im Hostnamen ausschließen (häufigste Ursache für „funktioniert nicht”).
- Erst nach bestandener Prüfung einreichen — sonst entsteht ein Zertifikat, das nachgebessert werden muss.
Anwenden
Merke: Der private Schlüssel ist nie im CSR — nur der öffentliche und die Selbstsignatur.
- Füge einen CSR im PEM-Format ein und lies den Subject-DN (CN, O, C).
- Kontrolliere die SAN-Liste: Sind alle benötigten DNS-Hostnamen enthalten?
- Prüfe Schlüsseltyp und -länge (z. B. RSA 2048+ oder ECDSA) als Mindeststandard.
Selbsttest
Praxis-Challenge
Lass dir (z. B. mit openssl) einen CSR für zwei Hostnamen erzeugen und prüfe ihn im Decoder: Stimmen CN und SAN, ist der Schlüssel stark genug? Dokumentiere einen Befund, den du vor dem Einreichen korrigieren würdest, und begründe, warum die SAN wichtiger ist als der CN.