☁ Heike Ritter ☁

Microsoft Technical Evangelist ☁ Public Cloud

Mehrere gesicherte Sites in einer Web Rolle in Windows Azure

Mehrere gesicherte Sites in einer Web Rolle in Windows Azure

  • Comments 1
  • Likes

Dieser Blogpost beschreibt die Konfiguration von mehreren gesicherten Web Site  in einer Windows Azure Web Rolle bei Verwendung von Host Headern und einem SSL Zertifikat mit hinzugefügtem SAN (Subject Alternative Name) Attribut. Das Sites Element innerhalb der Service Definition Datei (ServiceDefinition.csdef) kann dazu verwendet werden, um die Unterstützung für mehrere Web Sites und Web Anwendungen innerhalb einer Web Rolle zu konfigurieren, und diese Sites mit SSL abzusichern.

On-Premise ist es relativ einfach und straightforward mehrere Sites im IIS zu verwalten. Über die IIS Konfigurationseinstellungen können Host Header definiert und zu bestimmten Virtuellen Verzeichnissen umgeleitet werden. Auch können mehrere SSL Zertifikate installiert und dazu verwendet werden, die Sites zu sichern.

In Windows Azure sieht das Ganze etwas anders aus, da Web Rollen mit Paketdateien arbeiten, welche die gewünschte Konfiguration ebenfalls beinhalten sollten. Alle manuellen Änderungen in einer Remote Desktop Verbindung (RDP) an einem Image sind nicht persistent und gehen verloren, wenn ein Image das nächste Mal neu gestartet wird. Änderungen sollten ausschließlich über die Service Configuration Datei gemacht werden oder die RoleEntryPoint::OnStart Methode. Aus diesem Grund gehen viele den Weg über mehrere Web Rollen, was aber nicht unbedingt notwendig ist und vor allem das dynamische Skalieren erschwert.

Windows Azure aber auch bietet eine Möglichkeit, Host Header während der Bereitstellung zu konfigurieren.

In diesem Beispiel möchten wir zwei Sites mit SSL absichern, www.WebSiteEins.de und www.WebSiteZwei.de.

Über das Visual Studio zwei Websites zu einer Web Rolle hinzufügen.
Wie das gemacht wird, ist in diesem Artikel Schritt-für-Schritt beschrieben:
http://msdn.microsoft.com/de-de/library/windowsazure/gg433110.aspx

In der Datei ServiceDefinition.csdef folgende Änderungen eingeben und dabei auf das physikalische Verzeichnis wie auf den Host Header jeder Site achten. hostHeader beinhaltet den Websitenamen und physicalDirectory den physikalischen Pfad der Websitedateien.

<Sites>
      <Site name="sample1" physicalDirectory="..\WebSiteEins">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.WebSiteEins.com" />
        </Bindings>
      </Site>
      <Site name="sample2" physicalDirectory="..\WebSiteZwei">
        <Bindings>
         <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.WebSiteZwei.com" />
       </Bindings>
    </Site>
</Sites> 

Ich habe auf meiner Testmaschine die Hostsdatei modifiziert und beide URL’s auf Localhost 127.0.0.1 gesetzt und das Ganze dann im Compute Emulator
verifiziert.

Um SSL zu aktivieren, müssen folgende Einstellungen konfiguriert werden

 <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="https" port="443" certificate="Certificate1" />
</Endpoints>
<Certificates>
      <Certificate name="Certificate1" storeLocation="LocalMachine" storeName="My" />
</Certificates>

Hinweis: Durch das Hinzufügen des Zertifikats wird das Element <Certificates> bereits eingefügt.

Wie bereits oben erwähnt, muss das Zertifikat über das SAN Attribut verfügen, welches es ermöglicht, auf einen Host mit einem anderen DNS Namen zuzugreifen als dem eigentlichen Computernamen.
Eine Anleitung wie das bei einer Windows Zertifizierungsstelle funktioniert, gibt es hier: http://support.microsoft.com/kb/931351

Nun einen neuen Endpunkt erstellen und an ein SSL Zertifikat binden, welches beide Sites autorisieren kann.

Abbildung meines Zertifkats:

Das Package auf Windows Azure veröffentlichen, mit dem dazugehörigen Zertifikat und passendem CNAME Mapping für die Host Header Site.

Nach diesen Schritten sind nun beide Sites in nur einer Web Rolle via SSL erreichbar.


Mein Dank für diesen Blogpost geht an meinen Kollegen Mukul Kumar Gupta.

Happy ☁-ing!

Heike

Comments
  • Hallo Heike,

    danke für Ihren interessanten Blogbeitrag!

    Ich habe mich vor einiger Zeit auch einmal damit beschäftigt. Für Multi Tenant Cloud Applications (eine WebRole mit einer Site) ist die SAN-Möglichkeit leider nicht geeignet. Beispiel: jeder Tenant soll über eine eigene Subdomain via HTTPS auf die Azure SaaS Webanwendung gelangen. In diesem Fall kann man ja schlecht bei jedem neuen Tenant das "SAN-Zertifikat" aktualisieren. Das wäre nicht wirklich praktikabel. Die TLS-Erweiterung "Server Name Indication" (SNI) hat für diese Problematik eigentlich schon längst eine Lösung geschaffen. Leider unterstützen die IIS, anders als beispielsweise Apache, SNI (noch) nicht. Ab den IIS 8 gibt es endlich auch Unterstützung für SNI. Jetzt bleibt nur noch abzuwarten, wann Windows Server 8 als Guest OS in Azure bereitgestellt wird. Ich kann es kaum erwarten.

    Grüße aus Hannover,

    Tobias

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment