Auf jeder SharePoint Farm mit mehreren Webanwendungen kommt man recht schnell zu einer Hostheader Konfiguration, damit die Anwender eine Webanwendung nicht über einen dedizierten Port ansteuern müssen. Weiterhin kommt man mit dem zweiten Web Front End Server sowieso nicht mehr um eine Hostheader Konfiguration herum. Ein Hostheader dient im Internet Information Service dazu die Anfrage nach der Website intranet.hansevision.de mit der richtigen Webanwendung zu beantworten und ermöglicht damit mehre Webanwendungen auf derselben IP Adresse zu betreiben. Die Konfiguration von Hostheadern für HTTP-Verbindungen gestaltet sich recht einfach. Im SharePoint wird die Webanwendung mit den gewünschten Alternativen Zugriffszuordnungen versehen und anschießend passt man via IIS Manager die Bindungen der Seite an.

image

Nun benötigen viele Umgebungen eine SSL Verschlüsselung der Seiten. Bei den früheren IIS Versionen gab die Einschränkung, dass pro IP Adresse nur eine Webanwendung mit einem SSL Zertifikat zur HTTPS Verschlüsselung gebunden werden konnte. Für die üblichen Webanwendungen Portal, MySite und den Content Type Hub wären damit schon mal drei IP Adressen notwendig. Wird eine Lastverteilung mittels Network Loadbalancing eingesetzt und die Websitesammlungen sollen mit einem WakeUP Script aufgeweckt werden, werden alleine bei einer 2 WFE Server Farm ganze 9 IP Adressen notwendig. [Anzahl der Webanwendungen (Für NLB)+ Anzahl der Webanwendungen (Für WakeUp)* Web Front End Servern]. Die nächste Rettung aus dieser Miesere ist die Nutzung eines Wildcard Zertifikat. Dabei bietet der IIS die Möglichkeit ein einziges Zertifikat mehrfach an Webanwendungen auf der gleichen IP Adresse zubinden in dem ein Hostheader angegeben werden kann. Allerdings sind Wildcard Zertifikate umstritten, da sie alle Adressen innerhalb einer Domäne Authentifizieren. Wird eines der Systeme kompromittiert müssen auf allen Servern ein neues Wildcard Zertifikat eingespielt werden und in der Zwischenzeit kann mit solch einem Zertifikat auf jedes System des Unternehmens eine erfolgreiche Man-in-the-Middle-Attacke gestartet werden. Damit bleibt der Einsatz von SAN Zertifikaten als Alternative. Subject Alternative Name Zertifikate enthalten neben dem üblichen FQDN im CN Feld noch weitere Adressen für die diese gültig sind. Damit stellen SAN Zertifikate eine gute Alternative zu Wildcard Zertifikaten da, denn sie authentifizieren nur die gewünschten Adressen und bieten gleichzeitig die Möglichkeit mehrere Webanwendungen auf einer IP Adresse mit einer HTTPS Bindung zu konfigurieren.

image

Wählt man nun ein SAN Zertifikat in den IIS Bindungen aus, ist das Feld Hostheader allerdings deaktiviert.

image

Nun gibt es zwei Wege um die Webanwendung zur Nutzung des SAN Zertifikats mit Hostheadern zu bewegen. Entweder mittels Consolenanwendung appcmd oder über einen kleinen Trick auf mit der GUI. Dazu öffnet man die MMC.exe und für das Zertifikats SnapIn im Kontext des Computerkontos hinzu. Anschließend öffnet man die Eigenschaften des SAN Zertifikat und trägt in den Anzeigenamen einen * ein.

imageimage

Nun wird in den IIS Bindungen das Feld Hostheader freigeschaltet und dort kann der gewünschte Hostheader eingetragen werden.

image

Leave a comment

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

Time limit is exhausted. Please reload the CAPTCHA.