Wildcard Zertifikate

Bei der Beantragung von Zertifikaten war es in den Anfängen üblich, dass Sie einen Hostnamen im Zertifikat hinterlegt haben. Ein SSL-Listener, der auf IP-Adresse/Port-Kombination Verbindungen annimmt, kann immer nur genau ein Zertifikat nutzen. Denn der Client bekommt ganz am Anfang das Zertifikat präsentiert, um eine TLS-Verbindung aufzubauen. Eine "Auswahl" eines passenden Zertifikats z.B. anhand eines Hostheader ist nicht zu dem Zeitpunkt noch nicht möglich.

Das hat natürlich zum Nachteil, dass jemand, der viele Dienste per SSL unter unterschiedlichen Namen anbieten will, mehrere Zertifikate und natürlich auch IP-Adressen benötigt. Eine Lösung hierfür sind "Wildcard"-Zertifikate, die z.B. auf "*.netatwork.de" ausgestellt sind.

Wildcard Sample

Ein Beispiel ist diese Zertifikat, welches ich von meiner eigenen Firmen CA angefordert habe:

Sie können gut sehen, dass der Antragstelle "CN=" keinen absoluten Hostnamen, sondern einfach nur "*.netatwork.de" enthält. Ein solches Zertifikat kann natürlich nun überall eingesetzt werden. Es ist klar, dass sich öffentliche Zertifizierungsstellen ein Wildcard Zertifikat teurer bezahlen lassen. (Siehe auch SANZertifkate). Einige beschränken auch noch die Anzahl der Server, auf denen das Zertifikat parallel installiert werden darf.

Es gibt noch eine Abwandlung eines Wildcard-Zertifikats in Form eines SAN-Zertifikates, welches als CN einen normalen Hostnamen hat und im alternativen Antragstellername (SAN) einen Wildcardeintrag hat. Interessanterweise sind damit viele Dienste eher zufrieden.

Risiken

Nicht verschwiegen werden darf aber auch das Risiko beim Einsatz von Wildcard-Zertifikaten. Auch wenn sie sehr "einfach" und als die ideale Lösung aussehen, so sollten Sie ein Wildcard-Zertifikat samt dem privaten Schlüssel sehr genau "bewachen". Denn jeder, der diese Information aus einem Server exportieren kann oder die PFX-Datei samt Kennwort kennt, kann einen eigenen Server im gleichen Adressraum ohne ihr Wissen aufstellen und die Mitarbeiter z.B. per Mail dorthin umleiten. Würden Sie den Unterschied zwischen https://intranet.firma.tld und https:/lntranet.firma.tld erkennen ?. Der erste Buchstabe ist kein großes "i" sondern ein kleines "L". Als Betreiber dieser "falschen" Webseite könnte ich aber die Anwender zur Eingabe ihres Kennworts auffordern und da die Verbindung per SSL verschlüsselt und in der gleichen Domain ist, wird sicher keine Verdacht schöpfen. Dies dürfte auch ein Grund sein, warum es für Wildcard-Zertifikate auch keine Extended Validation gibt.

Daher sollten Sie Wildcard-Zertifikate als PFX-Datei "sichern" und auf die Server immer nur als "nicht exportierbar" einspielen. Das ist aber nicht immer ein Schutz, z.B.: gegen Clonen einer VM oder bei Systemen, die die Schlüssel einfach als Datei erwarten (Apache, VMWare Server etc.). Die dort verwendeten PEM-Dateien können von jedem berechtigen Benutzer kopiert werden.

Eine vielleicht bessere Alternative ist der Einsatz von SANZertifkaten, bei denen die Hostnamen (auch mehrere) alle im Zertifikat aufgeführt werden und damit ein Missbrauch mit anderen Hosts nicht möglich ist.

Einschränkungen

Neben der Risikoproblematik gibt es natürlich noch funktionale Einschränkungen. Nicht alle Clients "verstehen" Wildcard-Zertifikate sondern prüfen den "exakten" Namen. Die Problematik gibt es aber auch beim Einsatz von SANZertifkate. Problematisch ist aber auch, dass ein Server sich mit dem Zertifikat als "Clientzertifikat" nicht wirklich gegenüber einer Gegenstelle Identifizieren kann. Solche Themen führen zu Einschränkungen beim Einsatz mit verschiedenen Produkten

HKCU\Software\Microsoft\Activesync\Partners\[Secure] = 0

Outlook on Windows Vista RTM and XP or earlier operating systems:
The Windows RPC over HTTP component used for Outlook Anywhere requires that the SAN or common name of the certificate must match the Certificate Principal Name configured for Outlook Anywhere. Outlook 2007 and later versions use Autodiscover to obtain this Certificate Principal Name. To configure this value on your Exchange 2010 Client Access server, use the Set-OutlookProvider command with the -CertPrincipalName parameter. Set this parameter to the external host name that Outlook clients use to connect to Outlook Anywhere
Quelle: http://technet.microsoft.com/en-us/library/dd351044.aspx

Jeff Schertz hat auf seinem Blog-Eintrag http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/ noch genauer ausgeführt, unter welchen Umständen "Wildcards" möglich sind. Bei all den Sonderfällen und Einschränkungen sollten Sie bei Lync auf Wildcards einfach verzichten.

Andere Programme könnten ähnlichen Einschränkungen unterliegen. Prüfen Sie daher zuerst, ob die jeweilige Ausgabenstellung mit Wildcard-Zertifikaten zurecht kommt. Es ist nicht ausreichend, wenn sie das Zertifikat auf einen Dienst binden können. Das bedeutet nicht, dass es auch funktioniert. Sie müssen sicherstellen, dass alle Gegenstellen (auch verschiedene Versionen) damit funktionieren.

Weitere Links

Keywords:Wildcard Zertifikate