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 SAN-Zertifikate). 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 Wildcard-Eintrag hat. Interessanterweise sind damit viele Dienste eher zufrieden.

*.msxfaq.net ist nicht *.*.msxfaq.net und ist nicht msxfaq.*

Beachten Sie dabei, dass ein Wildcard-Cert nur genau eine Ebene abdeckt. Weitere Subdomains funktionieren so nicht. Das fällt z.B. auf, wenn sie "Autodiscover" für mehrere Länderdomänen veröffentlichen wollen wie:

autodiscover.de.msxfaq.com
autodiscover.us.msxfaq.com
autodiscover.it.msxfaq.com
autodiscover.jp.msxfaq.com
autodiscover.uk.msxfaq.com

Ein Eintrag "*.msxfaq.com" hilft hier nicht weiter.

Aber auch umgekehrt ist es nicht möglich.

autodiscover.msxfaq.de
autodiscover.msxfaq.com
autodiscover.msxfaq.nete
autodiscover.msxfaq.org

Sie können kein Zertifikat für "msxfaq.*" bekommen.

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 SAN-Zertifikaten, 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 SAN-Zertifikate. 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

  • ActiveSync/Exchange
    Mit ActiveSync macht in der Regel der Client Probleme, da Windows Mobile 5 und älter keine Wildcard-Zertifikate unterstützen. Sie greifen also auf "Hostname" zu und sehen im Zertifikat nur den "*". Damit "passt" dies nicht und ActiveSync stoppt. Es gibt wohl Hinweise, wie man auf dem PDA die Zertifikatsprüfung komplett abschalten könnte und damit die Funktion wieder herstellt. Aber dann ist es auch sehr einfach, den Client auf eine eigene Seite umzuleiten, Man-in-the-middle-Angriffe zu fahren und müssentauglich ist es auch nicht.
    Siehe auch Mobile 6

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

  • Outlook Anywhere auf Windows XP
    Windows XP kann noch keine Wildcard-Namen prüfen und so schlägt eine Kontrolle von Outlook auf den MSSTD-Eintrag fehl. Auf Windows Vista/7 ist das Problem nicht mehr vorhanden.

Outlook on Windows Vista RTM and XP or earlier operating systems:
The Windows RPC over HTTP component used für Outlook Anywhere requires that the SAN or common name of the certificate must match the Certificate Principal Name configured für 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

  • Exchange UM
    Exchange UM unterstützt keine Wildcard-Zertifikate in Zusammenarbeit mit OCS 2007/R2
    http://technet.microsoft.com/en-us/library/dd351044.aspx
  • Lync Edge
    Da Lync die Zertifikate nicht nur für TLS verwendet, sondern sich damit die Server auch gegenseitig identifizieren, ist ein "*" im Namen hier natürlich nicht hilfreich. Seit Lync 2010 ist es aber möglich, ein Wildcard-Zertifikat auf dem Frontend zu betreiben, aber da hier auch ein Zertifikat einer internen CA eingesetzt werden kann, sehe ich keinen Sinn darin. Zudem gibt es Interoperability-Probleme mit OCS2007R2 und älter
    Auf den Edge-Server dürfen keine Wildcard Zertifikate installiert sein (not supported) und laut Microsoft bricht dann die Federation mit OCS-Gegenstellen. Das konnte ich in einem Test so aber erst mal nicht bestätigen.
  • Lync Phone Edition
    Auch die Lync-Telefone scheinen den genauen Namen des per DNS aufgelösten Hostnamens zu prüfen. Insofern sollten auch die Frontend-Server einer Lync-Installation nicht mit "Wildcard"-Zertifikaten betrieben werden.
    Siehe auch http://blog.schertz.name/2011/02/lync-phone-edition-incompatible-wildcard-certificates/
    Are wildcard certificates supported with Lync Phone Edition? (14232) http://knowledgebase-iframe.polycom.com/kb/viewContent.do?externalId=14232&sliceId=1
  • Lync Mobilty "Lyncdiscover"
    Lync Mobile unterstützt Wildcards, wenn der Eintrag im SAN-Name steht.
  • OCS 2007 Communicator Mobile
    Wildcard Zertifikate funktionieren nicht. Siehe auch Communicator Mobile
  • OCS 2007/2007R2
    Wildcards sind hier generell nicht erlaubt

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