IISExpress und SSL–configuring web https for ASP.NET failed

Visual Studio 2012 ist super. Es nimmt dem Webdeveloper viel Arbeit ab, indem standardmäßig der integrierte Webserver IISExpress verwendet wird. Beim Erstellen einer App generiert VS eine URL mit http://localhost und einer zufälligen Portnummer aus dem Pool. Soweit so gut. Nur was tun, wenn ein Webprojekt mit einer https-URL kommt – und sich IISExpress partout weigert, diese Adresse zu finden?

Mir ist es so ergangen. Man öffnet nichts ahnend ein Projekt aus dem TFS und Visual Studio beschwert sich schon beim Öffnen: “Configuring Web https://… for ASP.NET 4.5 failed. You must manually configure this site for ASP.NET 4.5 in order for the site to run correctly.”. Die Solution öffnet brav, nur ist sie nicht lauffähig.

Nein, bitte nicht! Manuell Konfigurieren ist zwar leicht möglich (siehe Scott Hanselman´s Blog: Working with SSL at Development Time is easier with IISExpress und am Blogbeitrag Ende), aber…das kann doch nicht sein, oder?

Die Properties des Webprojekts zeigen die URL und die SSL URL, in diesem Beispiel https://localhost:44303:

Wenn man nun die WebApp startet, beschwert sich Visual Studio sofort:

Klar, das Verhalten erscheint mit der Fehlermeldung beim Öffnen der WebApp logisch. Nur, wie bringe ich IISExpress dazu, mit HTTPS zu arbeiten?

Grundsätzlich entspricht IISExpress dem “großen” IIS, jedoch nur als lokaler “persönlicher” (und integrierter) Webserver. Seit Visual Studio 2010 SP1 kann IISExpress SSL verwenden (der Vorgänger Cassini konnte das noch nicht) und auf localhost Ports größer 44300 verwenden. So können Webseiten mit SSL getestet werden (jedoch nicht mit dem Standard-Port 443).

Visual Studio - und auch die freie WebMatrix - bringen eigene self-signed certificates mit. IISExpress kann somit problemlos mit HTTPS umgehen und kümmert sich automatisch um alle erforderlichen Konfigurationen. Das kann man leicht ausprobieren, wenn man ein neues Webprojekt anlegt und dort den Schalter SSL Enabled = True setzt und die https-URL in den Project Properties einträgt und startet.

Hier die Probe mit einem nigel-nagel-neuen Web:

Run zum Testen, danach SSL Enabled auf True setzen. Damit wird automatisch die SSL URL eingetragen. Beim Starten folgt natürlich noch http://localhost:49791/. Das können wir leicht ändern, indem wir einfach die https-Adresse in den Project-Eigenschaften hinterlegen: https://localhost:44301/

…und das Web mit F5 starten: VS öffnet den Browser mit der https-Adresse. Der Benutzer muss natürlich dem ausgestellten Zertifikat vertrauen und die Verwendung für diese Session zulassen:

Beim “Laden dieser Website fortsetzen” folgt dann die App. Natürlich traut der Browser dem selbst ausgestellten Zertifikat nicht – aber für unsere Development-Zwecke ist diese Lösung perfekt.

Soweit so gut – IISExpress mit HTTPS funktioniert einwandfrei mit neuen WebApps. Zurück zu unserem Projekt das nicht funktioniert…

Zuerst bemüht man zumeist die Suchmaschine seiner Wahl um herauszufinden, was das Problem ist.
Die Lösung ist aber zum Glück wirklich … einfach!

So sieht die Konfiguration zuvor aus:

Wir stellen SSL Enabled auf False: Das klappt natürlich nicht, denn die SSL-Adresse ist ja im Project hinterlegt:

Also vor dem Umstellen die http-Adresse eintragen, Projekt speichern und dann SSL Enabled = False setzen.
Nun das Projekt testweise starten – es sollte alles (mit http) klappen.

Nun wird SSL Enabled wieder auf True gesetzt.

und die (neue) SSL URL wieder in den Project Properties hinterlegt:

…und das Web zum Testen neu gestartet – diesmal mit funktionierendem https.

Eine Alternative hierzu ist, die Bindings manuell einzutragen und zwar im Pfad C:\Users\<Kontoname>\Documents\IISExpress\config. Hier liegen drei IISExpress .config-Dateien:

In applicationhost.config merkt sich IISExpress die Projekte und deren Websettings für das Hosting. Natürlich können die Bindings für die Webprojekte auch hier manuell angepasst werden:

…bzw. Webprojekt-Bindings auch bereinigt werden, was manchmal auch ganz gut ist.

Und natürlich kann auch die .csproj Datei direkt bearbeitet werden, wo die Projekt-Adressen gespeichert sind:

<IISExpressSSLPort>44303</IISExpressSSLPort>
<IISUrl>https://localhost:44303/</IISUrl>

Wenn http- und https-Port gleich sind, beschwert sich Visual Studio. In diesem Fall einfach unterschiedliche Ports verwenden.

Die Lösung ist also einfach – aber zu Beginn gar nicht so naheliegend:

Wenn das Binding-Problem besteht, zuerst SSL wie oben ausschalten und danach wieder einschalten!
Dann sollte es mit https auch mit bestehenden (und hartnäckigen Projekten) klappen.