01-05-2024, 14:29
Um IIS so zu konfigurieren, dass HTTPS für spezielle Webanwendungen durchgesetzt wird, begleite ich dich durch die Schritte, die ich normalerweise befolge. Es ist nicht so schwer, und sobald du dich daran gewöhnt hast, wird es zur zweiten Natur. Also, schnapp dir eine Tasse Kaffee oder dein Lieblingsgetränk, und lass uns das gemeinsam durchgehen.
Zunächst solltest du sicherstellen, dass du das SSL-Zertifikat auf deinem Server installiert hast. Du kannst dein Zertifikat von verschiedenen Zertifizierungsstellen beziehen, oder wenn du in einem eher entwicklungsorientierten Setup arbeitest, kannst du ein selbstsigniertes Zertifikat erstellen. Das mache ich oft zum Testen - es ist schnell, und obwohl es von Browsern nicht sofort vertrauenswürdig ist, ist es in einer kontrollierten Umgebung perfekt. Du kannst eines direkt aus IIS generieren; geh einfach im IIS-Manager zum Server, suche die Option "Serverzertifikate" und erstelle ein neues selbstsigniertes Zertifikat.
Sobald du das Zertifikat hast, musst du es an die spezifische Site binden, die du sichern möchtest. Wähle einfach deine Webanwendung im IIS-Manager aus, und auf der rechten Seite siehst du die Option "Bindings". Klicke darauf und füge eine HTTPS-Bindung hinzu. Du solltest ein Dropdown-Menü für das SSL-Zertifikat sehen, in dem du das Zertifikat auswählen kannst, das du zuvor installiert hast. So kannst du genau auswählen, welches du verwendest, was ziemlich praktisch ist. Vergiss nicht, auf "OK" zu klicken, sobald alles ausgefüllt ist.
Jetzt, wo du HTTPS konfiguriert hast, ist dein nächster Schritt, es durchzusetzen. Hier könnte es etwas knifflig werden, wenn du mit URL-Umschreibungen nicht vertraut bist. IIS hat ein URL-Rewrite-Modul, das diese Aufgabe etwas handlicher macht. Wenn du dieses Modul noch nicht installiert hast, solltest du es dir unbedingt gleich besorgen. Es ist kostenlos und auf der Microsoft-Website zu finden. Nach der Einrichtung des Moduls solltest du IIS-Manager neu starten, um sicherzustellen, dass es die neue Ergänzung erkennt.
Nachdem du das Modul installiert hast, gehe zurück zu der Site, die du konfigurieren möchtest. Du wirst eine Option für URL-Umschreibung in der Funktionsansicht sehen. Wenn du darauf klickst, möchtest du eine neue Regel erstellen. In der Regel bevorzuge ich die Option "Leere Regel", aber du kannst "Umleitung zu HTTPS" verwenden, wenn du sie siehst, da sie für einfache Szenarien praktisch ist.
In der Regelkonfiguration gib deiner Regel einen beschreibenden Namen. Du solltest etwas wählen, das du später leicht identifizieren kannst. Zum Beispiel macht es für mich Sinn, sie "Umleitung zu HTTPS" zu nennen. Dann arbeitest du mit Bedingungen. In diesem Teil gibst du an, dass die Regel gilt, wenn die Anfrage über HTTP gestellt wird. Du kannst die Bedingung so einstellen, dass sie "{HTTPS}" überprüft und angibt, dass sie nicht gleich "ON" sein soll. Auf diese Weise wird die Regel aktiviert, wenn jemand versucht, auf deine Anwendung über HTTP zuzugreifen.
Als Nächstes konfigurierst du die Aktion. Setze den Aktionstyp auf "Umleitung". Im URL-Feld solltest du das passende Muster für die Umleitung eingeben. Du möchtest etwas wie "https://{HTTP_HOST}/{R:1}" verwenden. So wird die Anfrage an den gleichen Host umgeleitet und der Pfad bleibt erhalten. Du kannst den Umleitungstyp als "Permanent (301)" festlegen, denn das sagt Browsern und Suchmaschinen, dass die Seite dauerhaft zu HTTPS verschoben wurde.
Nachdem du diese Regel gespeichert hast, solltest du sie testen. Öffne ein Browserfenster und versuche, auf deine Anwendung über HTTP zuzugreifen. Du solltest automatisch zur HTTPS-Version umgeleitet werden. Wenn es funktioniert, bist du auf dem richtigen Weg! Es gibt nichts Schlimmeres, als das Gefühl zu haben, stundenlang an etwas zu arbeiten, nur um festzustellen, dass es nicht richtig konfiguriert ist.
Wenn alles reibungslos funktioniert, möchtest du vielleicht einige zusätzliche Anpassungen in Betracht ziehen. Zum Beispiel kann die Durchsetzung von HTTP Strict Transport Security vorteilhaft sein. Dies teilt den Browsern mit, dass sie nur für einen definierten Zeitraum über HTTPS mit deiner Site interagieren sollen. Du kannst das über die web.config-Datei konfigurieren, die sich im Stammverzeichnis deiner Webanwendung befindet. Du kannst einen neuen Antwortheader wie folgt hinzufügen:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
</customHeaders>
</httpProtocol>
</system.webServer>
Diese Zeile besagt den Browsern, dass sie im nächsten Jahr nur über HTTPS mit deiner Site verbunden werden sollen. Es ist eine hervorragende Möglichkeit, eine zusätzliche Sicherheitsebene hinzuzufügen.
Ein weiterer Punkt, den du überprüfen solltest, ist die Leistung deiner Site nach der Aktivierung von HTTPS. Manchmal kann es aufgrund der sicheren Verbindung zu einem leichten Rückgang der Ladezeiten kommen. Du könntest in Betracht ziehen, HTTP/2 zu implementieren, wenn dein Server und deine Clients es unterstützen, da es helfen kann, die Leistung zu verbessern, ohne die Sicherheit zu gefährden. Du kannst HTTP/2 auf deinem IIS-Server aktivieren, indem du sicherstellst, dass du die richtige Windows-Version hast, und es ist sehr einfach. Suche einfach nach der Konfigurationsoption in den Windows-Funktionen.
Vergiss auch den gemischten Inhalt nicht. Weißt du, was ich meine? Das ist der Fall, wenn einige Elemente auf deiner Site weiterhin über HTTP geladen werden, wie Bilder, Skripte oder Stylesheets. Es ist wichtig, diese Links zu reparieren, um ein sauberes HTTPS-Erlebnis zu gewährleisten. Browser kennzeichnen diese Probleme normalerweise, und wenn du sie ignorierst, kann das zu einer frustrierenden Erfahrung für die Benutzer führen.
Ich überprüfe auch gerne die Sicherheitsheader meiner Site, nachdem ich solche Änderungen vorgenommen habe. Tools wie Mozillas Observatory oder SecurityHeaders.com sind dafür großartig. Sie können dir helfen, etwaige Lücken zu erkennen, die du vielleicht nicht bemerkt hast. Ich erinnere mich, dass ich beim ersten Mal, als ich diese Tools verwendete, überrascht war, wie viel ich über gute Websicherheitspraktiken gelernt habe. Es hat mir wirklich die Augen für Dinge geöffnet, die ich vorher nicht einmal in Betracht gezogen hatte.
Wenn du in einer Produktionsumgebung arbeitest, ist es immer eine kluge Idee, diese Konfigurationen zuerst in einem Staging-Setup zu testen. Du möchtest sicherstellen, dass alles korrekt funktioniert, bevor du den Wechsel in der Live-Umgebung vornimmst. Manchmal können kleine Konfigurationen zu unerwarteten Problemen führen, wenn sie nicht sorgfältig behandelt werden.
Und vergiss nicht - die Kommunikation mit deinem Team ist entscheidend. Wenn du andere Entwickler leitest oder sogar nur mit nicht-technischen Stakeholdern zusammenarbeitest, stelle sicher, dass alle über die Bedeutung der Verwendung von HTTPS informiert sind. Oft haben die Leute Missverständnisse oder Fragen, warum Sicherheitsmaßnahmen wichtig sind, und es hilft, diesen Dialog zu führen.
Also, sobald du alles zum Laufen gebracht hast und mit der Art und Weise, wie deine Site unter HTTPS funktioniert, zufrieden bist, nimm dir einen Moment Zeit, um über die laufende Wartung nachzudenken. Überprüfe regelmäßig deine Zertifikate, um sicherzustellen, dass sie aktuell sind, und denke daran, Erinnerungen festzulegen, wann sie ablaufen werden. Das Automatisieren dieser Erinnerung kann dich vor einigen hektischen Last-Minute-Fixes bewahren.
Insgesamt mag es zunächst überwältigend erscheinen, aber wenn du es aufschlüsselst, ist die Konfiguration von IIS zur Durchsetzung von HTTPS einfach. Sobald du es ein paar Mal gemacht hast, wirst du viel sicherer fühlen, und schließlich wird es einfach Teil deiner Routine werden. Du wirst dich daran gewöhnen, von Anfang an über Sicherheit nachzudenken und zu verstehen, wie sie in das größere Bild der Webentwicklung und -operationen passt.
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Windows-Server-Backup-Lösung eingerichtet? In diesem Beitrag erkläre ich, wie man Windows-Server richtig sichert.
Zunächst solltest du sicherstellen, dass du das SSL-Zertifikat auf deinem Server installiert hast. Du kannst dein Zertifikat von verschiedenen Zertifizierungsstellen beziehen, oder wenn du in einem eher entwicklungsorientierten Setup arbeitest, kannst du ein selbstsigniertes Zertifikat erstellen. Das mache ich oft zum Testen - es ist schnell, und obwohl es von Browsern nicht sofort vertrauenswürdig ist, ist es in einer kontrollierten Umgebung perfekt. Du kannst eines direkt aus IIS generieren; geh einfach im IIS-Manager zum Server, suche die Option "Serverzertifikate" und erstelle ein neues selbstsigniertes Zertifikat.
Sobald du das Zertifikat hast, musst du es an die spezifische Site binden, die du sichern möchtest. Wähle einfach deine Webanwendung im IIS-Manager aus, und auf der rechten Seite siehst du die Option "Bindings". Klicke darauf und füge eine HTTPS-Bindung hinzu. Du solltest ein Dropdown-Menü für das SSL-Zertifikat sehen, in dem du das Zertifikat auswählen kannst, das du zuvor installiert hast. So kannst du genau auswählen, welches du verwendest, was ziemlich praktisch ist. Vergiss nicht, auf "OK" zu klicken, sobald alles ausgefüllt ist.
Jetzt, wo du HTTPS konfiguriert hast, ist dein nächster Schritt, es durchzusetzen. Hier könnte es etwas knifflig werden, wenn du mit URL-Umschreibungen nicht vertraut bist. IIS hat ein URL-Rewrite-Modul, das diese Aufgabe etwas handlicher macht. Wenn du dieses Modul noch nicht installiert hast, solltest du es dir unbedingt gleich besorgen. Es ist kostenlos und auf der Microsoft-Website zu finden. Nach der Einrichtung des Moduls solltest du IIS-Manager neu starten, um sicherzustellen, dass es die neue Ergänzung erkennt.
Nachdem du das Modul installiert hast, gehe zurück zu der Site, die du konfigurieren möchtest. Du wirst eine Option für URL-Umschreibung in der Funktionsansicht sehen. Wenn du darauf klickst, möchtest du eine neue Regel erstellen. In der Regel bevorzuge ich die Option "Leere Regel", aber du kannst "Umleitung zu HTTPS" verwenden, wenn du sie siehst, da sie für einfache Szenarien praktisch ist.
In der Regelkonfiguration gib deiner Regel einen beschreibenden Namen. Du solltest etwas wählen, das du später leicht identifizieren kannst. Zum Beispiel macht es für mich Sinn, sie "Umleitung zu HTTPS" zu nennen. Dann arbeitest du mit Bedingungen. In diesem Teil gibst du an, dass die Regel gilt, wenn die Anfrage über HTTP gestellt wird. Du kannst die Bedingung so einstellen, dass sie "{HTTPS}" überprüft und angibt, dass sie nicht gleich "ON" sein soll. Auf diese Weise wird die Regel aktiviert, wenn jemand versucht, auf deine Anwendung über HTTP zuzugreifen.
Als Nächstes konfigurierst du die Aktion. Setze den Aktionstyp auf "Umleitung". Im URL-Feld solltest du das passende Muster für die Umleitung eingeben. Du möchtest etwas wie "https://{HTTP_HOST}/{R:1}" verwenden. So wird die Anfrage an den gleichen Host umgeleitet und der Pfad bleibt erhalten. Du kannst den Umleitungstyp als "Permanent (301)" festlegen, denn das sagt Browsern und Suchmaschinen, dass die Seite dauerhaft zu HTTPS verschoben wurde.
Nachdem du diese Regel gespeichert hast, solltest du sie testen. Öffne ein Browserfenster und versuche, auf deine Anwendung über HTTP zuzugreifen. Du solltest automatisch zur HTTPS-Version umgeleitet werden. Wenn es funktioniert, bist du auf dem richtigen Weg! Es gibt nichts Schlimmeres, als das Gefühl zu haben, stundenlang an etwas zu arbeiten, nur um festzustellen, dass es nicht richtig konfiguriert ist.
Wenn alles reibungslos funktioniert, möchtest du vielleicht einige zusätzliche Anpassungen in Betracht ziehen. Zum Beispiel kann die Durchsetzung von HTTP Strict Transport Security vorteilhaft sein. Dies teilt den Browsern mit, dass sie nur für einen definierten Zeitraum über HTTPS mit deiner Site interagieren sollen. Du kannst das über die web.config-Datei konfigurieren, die sich im Stammverzeichnis deiner Webanwendung befindet. Du kannst einen neuen Antwortheader wie folgt hinzufügen:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
</customHeaders>
</httpProtocol>
</system.webServer>
Diese Zeile besagt den Browsern, dass sie im nächsten Jahr nur über HTTPS mit deiner Site verbunden werden sollen. Es ist eine hervorragende Möglichkeit, eine zusätzliche Sicherheitsebene hinzuzufügen.
Ein weiterer Punkt, den du überprüfen solltest, ist die Leistung deiner Site nach der Aktivierung von HTTPS. Manchmal kann es aufgrund der sicheren Verbindung zu einem leichten Rückgang der Ladezeiten kommen. Du könntest in Betracht ziehen, HTTP/2 zu implementieren, wenn dein Server und deine Clients es unterstützen, da es helfen kann, die Leistung zu verbessern, ohne die Sicherheit zu gefährden. Du kannst HTTP/2 auf deinem IIS-Server aktivieren, indem du sicherstellst, dass du die richtige Windows-Version hast, und es ist sehr einfach. Suche einfach nach der Konfigurationsoption in den Windows-Funktionen.
Vergiss auch den gemischten Inhalt nicht. Weißt du, was ich meine? Das ist der Fall, wenn einige Elemente auf deiner Site weiterhin über HTTP geladen werden, wie Bilder, Skripte oder Stylesheets. Es ist wichtig, diese Links zu reparieren, um ein sauberes HTTPS-Erlebnis zu gewährleisten. Browser kennzeichnen diese Probleme normalerweise, und wenn du sie ignorierst, kann das zu einer frustrierenden Erfahrung für die Benutzer führen.
Ich überprüfe auch gerne die Sicherheitsheader meiner Site, nachdem ich solche Änderungen vorgenommen habe. Tools wie Mozillas Observatory oder SecurityHeaders.com sind dafür großartig. Sie können dir helfen, etwaige Lücken zu erkennen, die du vielleicht nicht bemerkt hast. Ich erinnere mich, dass ich beim ersten Mal, als ich diese Tools verwendete, überrascht war, wie viel ich über gute Websicherheitspraktiken gelernt habe. Es hat mir wirklich die Augen für Dinge geöffnet, die ich vorher nicht einmal in Betracht gezogen hatte.
Wenn du in einer Produktionsumgebung arbeitest, ist es immer eine kluge Idee, diese Konfigurationen zuerst in einem Staging-Setup zu testen. Du möchtest sicherstellen, dass alles korrekt funktioniert, bevor du den Wechsel in der Live-Umgebung vornimmst. Manchmal können kleine Konfigurationen zu unerwarteten Problemen führen, wenn sie nicht sorgfältig behandelt werden.
Und vergiss nicht - die Kommunikation mit deinem Team ist entscheidend. Wenn du andere Entwickler leitest oder sogar nur mit nicht-technischen Stakeholdern zusammenarbeitest, stelle sicher, dass alle über die Bedeutung der Verwendung von HTTPS informiert sind. Oft haben die Leute Missverständnisse oder Fragen, warum Sicherheitsmaßnahmen wichtig sind, und es hilft, diesen Dialog zu führen.
Also, sobald du alles zum Laufen gebracht hast und mit der Art und Weise, wie deine Site unter HTTPS funktioniert, zufrieden bist, nimm dir einen Moment Zeit, um über die laufende Wartung nachzudenken. Überprüfe regelmäßig deine Zertifikate, um sicherzustellen, dass sie aktuell sind, und denke daran, Erinnerungen festzulegen, wann sie ablaufen werden. Das Automatisieren dieser Erinnerung kann dich vor einigen hektischen Last-Minute-Fixes bewahren.
Insgesamt mag es zunächst überwältigend erscheinen, aber wenn du es aufschlüsselst, ist die Konfiguration von IIS zur Durchsetzung von HTTPS einfach. Sobald du es ein paar Mal gemacht hast, wirst du viel sicherer fühlen, und schließlich wird es einfach Teil deiner Routine werden. Du wirst dich daran gewöhnen, von Anfang an über Sicherheit nachzudenken und zu verstehen, wie sie in das größere Bild der Webentwicklung und -operationen passt.
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Windows-Server-Backup-Lösung eingerichtet? In diesem Beitrag erkläre ich, wie man Windows-Server richtig sichert.
