Kategorie: Zertifikatsanträge (CSR)
Komplexität: ⭐⭐⭐ (Mittel-Hoch)
Voraussetzungen: Schlüsselpaar vorhanden
Geschätzte Zeit: 10-15 Minuten
Dieses Szenario beschreibt die Erstellung eines CSR mit mehreren Subject Alternative Names (SANs). Dies ist notwendig für Zertifikate, die mehrere Domains, Subdomains oder IP-Adressen absichern sollen.
Anwendungsfälle:
| Typ | GeneralName Tag | Beispiel | Verwendung |
|---|---|---|---|
| DNS | dNSName (2) | www.example.com | Websites, APIs |
| IP | iPAddress (7) | 192.168.1.100 | Interne Services |
| rfc822Name (1) | admin@example.com | S/MIME | |
| URI | uniformResourceIdentifier (6) | https://example.com | SAML, OIDC |
| UPN | otherName (0) | user@domain.local | Windows Auth |
using WvdS.Security.Cryptography.X509Certificates.Extensions.PQ; using var ctx = PqCryptoContext.Initialize(); using var key = ctx.GenerateKeyPair(PqAlgorithm.MlDsa65); var dn = new DnBuilder() .AddCN("example.com") // Primäre Domain .AddO("Example GmbH") .AddC("DE") .Build(); // Multi-SAN mit verschiedenen Typen var extensions = new ExtBuilder() .SubjectAlternativeName(new[] { // DNS-Namen "dns:example.com", "dns:www.example.com", "dns:api.example.com", "dns:app.example.com", "dns:*.dev.example.com", // Wildcard für Dev // IP-Adressen (für interne Zugriffe) "ip:10.0.0.100", "ip:192.168.1.50", // IPv6 "ip:2001:db8::1" }) .KeyUsage(KeyUsageFlags.DigitalSignature | KeyUsageFlags.KeyEncipherment) .ExtendedKeyUsage(ExtKeyUsage.ServerAuth) .Build(); var csr = ctx.CreateCertificateRequest(key, dn, extensions); // Alle SANs ausgeben Console.WriteLine("Subject Alternative Names:"); foreach (var san in csr.SubjectAlternativeNames) { Console.WriteLine($" - {san}"); } File.WriteAllText("multi-san.csr.pem", csr.ToPem());
var extensions = new ExtBuilder() .SubjectAlternativeName(new[] { "dns:example.com", // Root-Domain (Wildcard deckt diese nicht ab!) "dns:*.example.com", // Alle Subdomains 1. Ebene "dns:*.api.example.com", // API-Subdomains "dns:legacy.old-domain.com" // Alternative Domain }) .Build();
Wichtig: Wildcards (*.example.com) decken nur eine Ebene ab und nicht die Root-Domain selbst! Daher immer example.com UND *.example.com angeben.
var extensions = new ExtBuilder() .SubjectAlternativeName(new[] { // Kubernetes Service DNS "dns:my-service", "dns:my-service.default", "dns:my-service.default.svc", "dns:my-service.default.svc.cluster.local", // Headless Service (Pod DNS) "dns:*.my-service.default.svc.cluster.local", // Externe Ingress Domain "dns:api.example.com" }) .Build();
| Aspekt | Empfehlung | Begründung |
|---|---|---|
| Anzahl SANs | Max. 100 | Performance, Zertifikatsgröße |
| Wildcard-Ebenen | Nur 1 Ebene | RFC 6125 Einschränkung |
| IP-Adressen | Nur wenn nötig | IPs ändern sich häufiger |
| Interne Namen | Separate Zertifikate | Sicherheitstrennung |
| Beziehung | Szenario | Beschreibung |
|---|---|---|
| Nächster Schritt | 3.1 Server-Zertifikat | CSR signieren |
| Alternativ | 3.5 Wildcard-Zertifikat | Nur Wildcard |
| Grundlage | 2.1 Server-CSR | Einfacher Server-CSR |
« ← 2.2 Client-CSR | ↑ CSR-Übersicht | 2.4 CSR verarbeiten → »
Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional