Multi-Domain SSL-Zertifikate

Wer selbst Webserver betreibt, die verschlüsselte Bereiche anbieten sollen, kennt sicherlich das folgende Problem:
HTTPS benötigt pro virtuellem Webserver eine eigene IP-Adresse, weil die Verschlüsselung aktiv wird, bevor der Mechanismus greift, der die Unterscheidung von Name Based Virtual Hosts ermöglicht.

Dieses Problem führt dazu, dass man meistens die Wahl zwischen mehr oder weniger schönen Alternativen hat. Da ich in Projekten immer wieder damit konfrontiert bin – und auch privat des Öfteren danach gefragt werde – möchte ich beschreiben, welche Möglichkeiten man mittlerweile hat, um elegant und ohne irritierende Warnmeldungen damit umzugehen.

Die einfachste Möglichkeit, besteht darin, alle verschlüsselten Dienste unter einem Host anzubieten. Manch einer erinnert sich sicherlich an ssl.kundenserver.de. Solche Proxy-Lösungen haben aber den Nachteil, dass nach dem Proxy alles unverschlüsselt weitergeht. Das will man nicht wirklich. Diese „Lösung“ ist prädestiniert für Angriffe zwischen dem Proxy und dem virtuellen Webserver.

Die zweite Alternative sind Wildcard-Zertifikate für eine Domain. Die haben aber zwei Nachteile. Erstens müssen alle Angebote, die verschlüsselt funktionieren sollen, unter der gleichen Domain laufen. Und Zweitens sind die Wildcards nicht rekursiv: man kann mit einem Wildcard-Zertifikat für *.meinedomain.tld also www.meinedomain.tld und www2.meinedomain.tld unterstützen, nicht aber www1.www.meinedomain.tld.

Letzteres Problem führt direkt zur dritten Alternative, nämlich dem Akzeptieren von Warnungen des Browsers, dass der Hostname in der URL und die CN im Zertifikat nicht übereinstimmen. Hier funktioniert zwar die Verschlüsselung, die Warnung ist aber lästig und verunsichert viele Benutzer.

Erfreulicherweise bietet X509 V3 verschiedene Erweiterungen, unter anderem mit SubjectAltName eine Möglichkeit, sowohl die Warnungen zu vermeiden, als auch mehrere virtuelle Hosts mit unterschiedlichen Domains unter einer IP-Adresse mit SSL zu betreiben. Eine ausführliche Spezifikation ist im RFC 3280 zu finden.

Die Anwendung von SAN mit OpenSSL funktioniert recht einfach. Zunächst muss im Abschnitt req der Konfiguration eine Option ergänzt werden, die sich req_extensions nennt.

[ req ]
distinguished_name = req_dn
req_extensions = v3_req

Diese Option erhält als Parameter den Namen eines weiteren Abschnitts in der Konfiguration.
In diesem Abschnitt kann man nun wahlweise mehrere Einträge der Option subjectAltName unterbringen oder auf einen zusätzlichen Abschnitt verweisen. In der OpenSSL-Dokumentation ist erklärt, wie die Konfiguration mit mehreren Einträgen von subjectAltName funktioniert, daher zeige ich in meinem Beispiel, wie sie mit einem zusätzlichen Abschnitt funktioniert.

[ v3_req ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = gerritbeine.de
DNS.2 = *.gerritbeine.de
IP.1 = 87.230.15.104

Man hat mit SAN die Möglichkeit, sowohl Hostnamen als auch IPv4- und IPv6-Adressen anzugeben. Wildcards sind für Domains ebenso möglich, wie E-Mail-Adressen. SAN untersützt auch andere identifizierbare Objekte, was allerdings für Webhosting weitestegehend irrelevant ist.

Zusätzlich zu dieser Variante mit den Subject Alternative Names gibt es auch die Möglichkeit, mehrere Einträge für das Attribut commonName vorzunehmen:

[ req_dn ]
0.commonName = "gerritbeine.de"
emailAddress = "hostmaster@gerritbeine.de"
1.commonName = "*.gerritbeine.de"

Beide Lösungen funktionieren, haben aber zwei Nachteile: Erstens macht man mit einem Multi-Domain-Zertifikat publik, welche virtuellen Webserver gemeinsam auf einem Host laufen. Manchmal möchte man das nicht, dann stellt die Verwendung von mehreren IP-Adressen tatsächlich die einzige Möglichkeit dar. Zweitens erzwingt die Erweiterung um eine Domain eine neue Signatur durch die CA. Je nachdem, wie diese CA arbeitet gibt es einen lästigen Revoke-Prozess, der manchmal Geld, in jedem Fall aber Zeit kostet.

Ein günstiger Anbieter, der SAN unterstützt, ist StartSSL.

Quellen:

0 Kommentare bei „Multi-Domain SSL-Zertifikate

  1. > Zweitens erzwingt die Erweiterung um eine Domain eine neue Signatur durch die CA. Je nachdem, wie diese CA arbeitet gibt es einen lästigen Revoke-Prozess, der manchmal Geld, in jedem Fall aber Zeit kostet.

    Kommt meines Erachtens darauf an, ob das Zertifikat um die ursprüngliche Anzahl an enthaltenen SANs erweitert wird. Kauft man z.B. ein Multi-Domain Zertifikat von Geotrust mit 5 enthaltenen Hostnamen und verwendet bei der ersten Ausstellung nur drei davon, kann man jederzeit zwei weitere hinzufügen. Ohne Kosten und mit minimalem Zeitaufwand.

    Zwei weitere Punkte: Multi-Domain SSL-Zertifikate sind meist günstiger als Wildcard Zertifikate – und es gibt sie auch mit erweiterter Validierung (grüne Adressleiste, bei Web-Shops o.ä. durchaus interessant).

    In unserer Firma haben wir ein GeoTrust SAN mit EV gekauft (nicht teuer, hier: https://www.sslpoint.com/de/multidomain-ssl-zertifikate/ ) – dieses funktioniert einwandfrei. Grüne Leiste für den Webshop und die SANs für unseren Mailserver + Webmail.

    LG
    Peter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.