Szenario 2.3: Multi-SAN CSR erstellen

Kategorie: Zertifikatsanträge (CSR)
Komplexität: ⭐⭐⭐ (Mittel-Hoch)
Voraussetzungen: Schlüsselpaar vorhanden
Geschätzte Zeit: 10-15 Minuten

Beschreibung

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:

Multi-Domain-Zertifikate (SAN-Zertifikate)
Wildcard + explizite Domains kombiniert
Interne + externe Namen
Load Balancer mit mehreren Backends

SAN-Typen

Typ	GeneralName Tag	Beispiel	Verwendung
DNS	dNSName (2)	www.example.com	Websites, APIs
IP	iPAddress (7)	192.168.1.100	Interne Services
Email	rfc822Name (1)	admin@example.com	S/MIME
URI	uniformResourceIdentifier (6)	https://example.com	SAML, OIDC
UPN	otherName (0)	user@domain.local	Windows Auth

Code-Beispiel (C#)

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());

Wildcard + Explicit kombinieren

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.

Kubernetes / Cloud-Native

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();

Limits und Best Practices

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

Inhaltsverzeichnis