Warum diesen Analysator verwenden?
Validieren Sie, was auf Ihrem Zertifikat erscheinen wird, bevor Sie es an eine Zertifizierungsstelle (CA) senden. Erkennen Sie einen fehlenden SAN, einen schwachen Schlüssel, einen veralteten Algorithmus oder eine fragwürdige IDN-Kodierung. Sparen Sie Zeit beim Onboarding oder der Verlängerung, indem Sie die nützlichen Felder sofort lesen.
Was ist ein CSR?
Ein Certificate Signing Request ist eine Textdatei im PEM-Format, die Folgendes enthält:
- Ihren öffentlichen Schlüssel (RSA oder EC)
- Identitätsinformationen: Subjekt (CN, O, OU, L, ST, C) und SANs
- Eine Signatur, die mit Ihrem privaten Schlüssel erstellt wurde, um den Besitz nachzuweisen
Der CSR wird an eine CA (Let's Encrypt, DigiCert, GlobalSign, Sectigo...) gesendet, die das Zertifikat ausstellt, wenn die Validierung erfolgreich ist (DV, OV oder EV).
Wann einen CSR generieren?
| Anwendungsfall | Beschreibung |
|---|---|
| Neues Zertifikat | Erstellen eines TLS-Zertifikats für Webserver, API, MTA |
| Verlängerung | Verlängerung eines bestehenden Zertifikats mit einem neuen Schlüsselpaar |
| SANs hinzufügen | Hinzufügen einer neuen Subdomain oder FQDN zum Zertifikat |
| RSA zu EC-Migration | Wechsel zu EC-Schlüssel für bessere Leistung |
| Standardisierung | Harmonisierung von Feldern über eine heterogene Infrastruktur |
Was sollte ein guter CSR enthalten?
Erforderliche Felder
- SAN (Subject Alternative Names): Liste aller abgedeckten Namen, einschließlich der nackten Domain bei Bedarf. Ohne SANs lehnen viele CAs ab.
- Öffentlicher Schlüssel: RSA 2048 Bit Minimum (idealerweise 3072) oder EC P-256/P-384
- Signatur: SHA-256 empfohlen (SHA-1 abgelehnt)
Optionale Felder
- Subject CN: oft von modernen CAs ignoriert, aber aus Kompatibilitätsgründen behalten
- O, OU, L, ST, C: nützlich für OV/EV, unnötig für DV
- Key Usage / Extended Key Usage: je nach Ihren spezifischen Anforderungen
Wichtig: Ein CN allein reicht nicht mehr aus. SANs sind für die meisten CAs obligatorisch.
OpenSSL-Beispiele
RSA 3072 CSR mit SANs
san.cnf-Datei:
[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.beispiel.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.beispiel.com
DNS.2 = beispiel.com
Befehl:
openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf
EC P-256 CSR mit SANs
openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf
Internationalisierte Domainnamen (IDN)
Verwenden Sie Punycode (xn--...) in SANs, um Kodierungsüberraschungen zu vermeiden.
Häufige Fehler
| Fehler | Auswirkung | Lösung |
|---|---|---|
| Fehlende SANs | Zertifikat deckt weniger Namen ab als erwartet | Alle Domains im [alt]-Abschnitt hinzufügen |
| RSA 1024 oder SHA-1 | Wahrscheinliche Ablehnung durch CA | RSA 2048+ und SHA-256 verwenden |
| Privater Schlüssel exponiert | Sicherheitskompromittierung | Niemals privaten Schlüssel online einfügen |
| Falsche IDN-Kodierung | Domain nicht erkannt | Exakten Punycode verwenden |
| Wildcard ohne nackte Domain | *.beispiel.com deckt nicht beispiel.com ab | Beide in SANs hinzufügen |
Best Practices
- Schlüsselpaar serverseitig generieren und privaten Schlüssel von jedem gemeinsam genutzten System fernhalten
- EC P-256/P-384 oder RSA 3072+ bevorzugen für neue Bereitstellungen
- SAN-Liste begrenzen auf das, was tatsächlich benötigt wird
- Protokoll führen: Datum, Subjekt, SANs, Schlüsselgröße, verantwortliche Person
- CSR nach der Generierung testen, um Hin und Her mit der CA zu vermeiden
Datenschutz
Ihr CSR wird nur zur Dekodierung und Anzeige an die CaptainDNS-API gesendet. Inhalte werden nicht gespeichert. Kein Feld wird im Klartext protokolliert. Nur anonyme technische Metriken werden aufgezeichnet (Verarbeitungszeit, Größe, Schlüsseltyp, Algorithmus) zur Verfügbarkeitsüberwachung.