Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
von Keith Newman und Robert McMurray
Berücksichtigen Sie in dieser Phase des Erstellens Ihrer Website die Sicherheitsanforderungen Ihrer ASP.NET Anwendung. In den folgenden Abschnitten werden die in IIS 8 verfügbaren Anwendungssicherheitseinstellungen beschrieben:
4.1. Isolieren von Webanwendungen
Eine der effektivsten Methoden zur Verbesserung der Sicherheit für Ihre Webanwendung besteht darin, sie von anderen Anwendungen auf Ihrem Webserver zu isolieren. Ein Anwendungspool verfügt über einen eigenen Arbeitsprozess, der Anforderungen verarbeitet und Anwendungscode ausführt. Der Arbeitsprozess verfügt über einen Sicherheitsbezeichner (SID). Und jeder Anwendungspool verfügt über eine eindeutige Anwendungspoolidentität. Wenn Sie eine Webanwendung erstellen, wird standardmäßig auch ein neuer Anwendungspool mit demselben Namen wie die Anwendung erstellt. Wenn Sie Webanwendungen in separaten Anwendungspools speichern, können Sie sie voneinander isolieren.
Die Webanwendungsisolation umfasst Folgendes:
- Standortisolation: Trennen Sie verschiedene Anwendungen in verschiedene Standorte mit unterschiedlichen Anwendungspools.
- Prinzip der geringsten Rechte: Führen Sie Ihren Arbeitsprozess als niedrig privilegierte Identität (virtuelle Anwendungspool-Identität) aus, die pro Website eindeutig ist.
- Temporäre Isolation: Richten Sie einen separaten ASP.NET temporären Ordner pro Website ein, und gewähren Sie nur Zugriff auf die entsprechende Prozessidentität.
- Inhaltsisolation: Stellen Sie sicher, dass Sie eine ACL (Zugriffssteuerungsliste) für jeden Websitestamm festlegen, um nur zugriff auf die entsprechende Prozessidentität zuzulassen.
Tipp
Es empfiehlt sich, Ihre Website- und Webanwendungsinhalte auf einem anderen Laufwerk als Ihrem Systemlaufwerk (C:) zu hosten.
4.2. .NET Trust Levels
Eine Anwendungsvertrauensstufe bestimmt die Berechtigungen, die die ASP.NET Richtlinie für die Codezugriffssicherheit (Code Access Security, CAS) gewährt. CAS definiert zwei Vertrauenskategorien: voll vertrauenswürdig und teilweise vertrauenswürdig. Eine Anwendung mit voll vertrauenswürdigen Berechtigungen kann auf alle Ressourcentypen auf einem Server zugreifen und privilegierte Vorgänge ausführen. Anwendungen mit voller Vertrauenswürdigkeit sind nur von den Sicherheitseinstellungen des Betriebssystems betroffen.
Teilweise vertrauenswürdige Webanwendungen sind Anwendungen, die nicht voll vertrauenswürdig sind und über einen eingeschränkten Satz von Codezugriffsberechtigungen verfügen. Daher sind teilweise vertrauenswürdige Anwendungen in ihrer Fähigkeit eingeschränkt, auf gesicherte Ressourcen zuzugreifen und andere privilegierte Vorgänge auszuführen. Bestimmte Berechtigungen werden teilweise vertrauenswürdigen Anwendungen verweigert, sodass Ressourcen, die diese Berechtigungen erfordern, nicht direkt darauf zugreifen können. Andere Berechtigungen werden eingeschränkt gewährt, sodass Ressourcen, auf die diese Berechtigungen erforderlich sind, möglicherweise zugänglich sind, aber auf begrenzte Weise. Beispielsweise gewährt die Berechtigung "Eingeschränkter Dateizugriff" der Anwendung Zugang zum Dateisystem, jedoch nur in Verzeichnissen unterhalb des virtuellen Verzeichnisstamms der Anwendung.
Durch die Konfiguration einer Webanwendung oder eines Webdiensts für eine teilweise Vertrauensstellung können Sie die Fähigkeit der Anwendung einschränken, auf wichtige Systemressourcen oder Ressourcen zuzugreifen, die zu anderen Webanwendungen gehören. Indem Sie nur die Berechtigungen erteilen, die die Anwendung benötigt und nicht mehr, können Sie am wenigsten privilegierte Webanwendungen erstellen und potenzielle Schäden einschränken, wenn die Webanwendung durch einen Codeeinfügungsangriff kompromittiert wird.
In der folgenden Liste sind die Einschränkungen aufgeführt, die den einzelnen Vertrauensstufen zugeordnet sind:
- Voll vertrauenswürdige Anwendungen haben uneingeschränkten Zugriff auf alle Ressourcentypen und können privilegierte Vorgänge ausführen.
- Anwendungen mit hoher, mittlerer, niedriger oder minimaler Vertrauensebene können keinen nicht verwalteten Code oder verwaltete Komponenten aufrufen, nicht in das Ereignisprotokoll schreiben, nicht auf Message Queuing-Warteschlangen zugreifen oder nicht auf OLE DB-Datenquellen zugreifen.
- Besonders vertrauenswürdige Anwendungen haben uneingeschränkten Zugriff auf das Dateisystem.
- Mittlere vertrauenswürdige Anwendungen haben eingeschränkten Dateisystemzugriff und können nur auf Dateien in ihrer eigenen Anwendungsverzeichnishierarchie zugreifen.
- Anwendungen mit niedriger oder minimaler Vertrauensebene können nicht auf SQL Server-Datenbanken zugreifen.
- Minimal vertrauenswürdige Anwendungen können nicht auf Ressourcen zugreifen.
4.3. .NET-Authentifizierung
Die Authentifizierung hilft Ihnen, die Identität von Clients zu bestätigen, die Zugriff auf Ihre Websites und Anwendungen anfordern. Wenn die Authentifizierung aktiviert ist, verwendet IIS 8 die vom Benutzer bereitgestellten Kontoanmeldeinformationen, um zu bestimmen, welche Berechtigungen der Benutzer gewährt hat und auf welche Ressourcen der Benutzer zugreifen kann.
In diesem Abschnitt werden die Authentifizierungsmodi beschrieben, die für ASP.NET Anwendungen spezifisch sind.
ASP.NET Formularauthentifizierung
Die Formularauthentifizierung verwendet clientseitige Umleitung, um nicht authentifizierte Benutzer an ein HTML-Formular weiterzuleiten, in dem sie ihre Anmeldeinformationen eingeben können, die normalerweise ein Benutzername und ein Kennwort sind. Nachdem die Anmeldeinformationen überprüft wurden, werden Die Benutzer auf die Seite umgeleitet, die sie ursprünglich angefordert haben. Die Formularauthentifizierung verwendet häufig Cookies, um Benutzeranmeldeinformationen zwischen dem Server und dem Clientbrowser zu übergeben.
In den folgenden Abschnitten wird beschrieben, was Sie wissen müssen, um das Hinzufügen von Formularauthentifizierung zu Ihrer Website zu planen:
Grundlagen der Formularauthentifizierung
ASP.NET Formularbasierte Authentifizierung eignet sich gut für Websites oder Anwendungen auf öffentlichen Webservern, die viele Anforderungen erhalten. Mit diesem Authentifizierungsmodus können Sie die Clientregistrierung und Authentifizierung auf Anwendungsebene verwalten, anstatt sich auf die vom Betriebssystem bereitgestellten Authentifizierungsmechanismen zu verlassen.
Von Bedeutung
Da die Formularauthentifizierung den Benutzernamen und das Kennwort als Nur-Text an den Webserver sendet, verwenden Sie die SSL-Verschlüsselung (Secure Sockets Layer) für die Anmeldeseite und für alle anderen Seiten in Ihrer Anwendung mit Ausnahme der Startseite. Informationen zu SSL finden Sie unter 4.5. TLS/SSL-Kommunikation.
Die Formularauthentifizierung ermöglicht Benutzern die Anmeldung mithilfe von Identitäten aus einer ASP.NET Mitgliedschaftsdatenbank. Diese Authentifizierungsmethode verwendet die Umleitung zu einer HTML-Anmeldeseite, um die Identität des Benutzers zu bestätigen. Sie können die Formularauthentifizierung auf Standort- oder Anwendungsebene konfigurieren.
Die Formularauthentifizierung ist aus den folgenden Gründen praktisch:
- Sie ermöglicht entweder einen benutzerdefinierten Datenspeicher, z. B. eine SQL Server-Datenbank oder Active Directory, für die Authentifizierung zu verwenden.
- Sie lässt sich problemlos in eine Web-Benutzeroberfläche integrieren.
- Clients können jeden beliebigen Browser verwenden.
Wenn Sie Mitgliedschaftsrollen für die Autorisierung verwenden möchten, verwenden Sie die Formularauthentifizierung oder eine ähnliche benutzerdefinierte Authentifizierungsmethode.
Von Bedeutung
Wenn Sie die Formularauthentifizierung auswählen, können Sie keine der abfragebasierten Authentifizierungsmethoden gleichzeitig verwenden.
Standardmäßig ist die Anmelde-URL für die Formularauthentifizierung Login.aspx. Sie können eine eindeutige Anmeldeseite für Kunden erstellen, die eine Website oder Anwendung besuchen. Beispielsweise möchten Sie möglicherweise bestimmte Informationen von Besuchern sammeln oder eine Mitgliedschaft für ausgewählte Seiten auf der Website oder für ausgewählte Anwendungen anbieten.
Der Standardtimeoutwert für die Formularauthentifizierung beträgt 30 Minuten. Erwägen Sie, den Timeoutwert in einen kürzeren Zeitraum zu ändern, um die Sitzungsdauer zu verkürzen und die Wahrscheinlichkeit von Cookie-Wiederholungsangriffen zu verringern.
Authentifizierungscookies
Authentifizierungscookies werden als Token verwendet, um sicherzustellen, dass ein Client Zugriff auf einige oder alle Seiten einer Anwendung hat. Im Gegensatz dazu enthalten Personalisierungscookies benutzerspezifische Einstellungen, die die Benutzererfahrung auf einer bestimmten Website oder Anwendung bestimmen.
Wichtig: Da Authentifizierungscookies zusammen mit jeder Anforderung zwischen Client und Server übergeben werden, sichern Sie immer Authentifizierungscookies mit Secure Sockets Layer (SSL). Informationen zu SSL finden Sie unter 4.5. TLS/SSL-Kommunikation.
Cookies sind eine effizientere Möglichkeit, Besucher auf einer Website nachzuverfolgen als Abfragezeichenfolgen, da sie keine Umleitung erfordern. Sie sind jedoch browserabhängig, und einige Browser unterstützen ihre Verwendung nicht. Darüber hinaus ist die Verwendung der cookiebasierten Authentifizierung nicht immer wirksam, da einige Benutzer die Cookie-Unterstützung in ihren Browsern deaktivieren.
Standardmäßig lautet der Cookiename für ASP.NET Anwendungen . ASPXAUTH. Sie können jedoch stattdessen einen eindeutigen Cookienamen und Pfad für jede Anwendung verwenden. Auf diese Weise kann verhindert werden, dass Benutzer, die für eine Anwendung authentifiziert werden, für andere Anwendungen auf einem Webserver authentifiziert werden.
Sie können einen der folgenden Cookiemodi für Ihre Website oder Anwendung auswählen:
| Modus | Beschreibung |
|---|---|
| Cookies verwenden | Cookies werden unabhängig vom Gerät immer verwendet. |
| Cookies nicht verwenden | Cookies werden nicht verwendet. |
| Automatische Erkennung | Cookies werden verwendet, wenn das Geräteprofil Cookies unterstützt. Andernfalls werden keine Cookies verwendet. Bei Desktopbrowsern, die bekannt sind, Cookies zu unterstützen, ASP.NET überprüft, ob Cookies aktiviert sind. Diese Einstellung ist die Standardeinstellung. |
| Geräteprofil verwenden | Cookies werden verwendet, wenn das Geräteprofil Cookies unterstützt. Andernfalls werden keine Cookies verwendet. ASP.NET überprüft nicht, ob Cookies auf Geräten aktiviert sind, die Cookies unterstützen. Diese Einstellung ist die Standardeinstellung für IIS 8. |
Der Cookie-Schutzmodus definiert die Funktion, die ein Formularauthentifizierungscookies für eine bestimmte Anwendung ausführt. In der folgenden Tabelle sind die Cookieschutzmodi aufgeführt, die Sie definieren können:
| Modus | Beschreibung |
|---|---|
| Verschlüsselung und Validierung | Gibt an, dass die Anwendung sowohl die Datenüberprüfung als auch die Verschlüsselung verwendet, um das Cookie zu schützen. Diese Option verwendet den konfigurierten Datenüberprüfungsalgorithmus (basierend auf dem Computerschlüssel). Wenn Triple-DES (3DES) verfügbar ist und der Schlüssel lang genug ist (48 Bytes oder mehr 3DES wird für die Verschlüsselung verwendet. Diese Einstellung ist der Standardwert (und empfohlen). |
| Nichts | Gibt an, dass sowohl Verschlüsselung als auch Validierung für Websites deaktiviert sind, die Cookies nur für die Personalisierung verwenden und schwächere Sicherheitsanforderungen aufweisen. Wir empfehlen Nicht, Cookies auf diese Weise zu verwenden; Dies ist jedoch die am wenigsten ressourcenintensive Möglichkeit, die Personalisierung mithilfe von .NET Framework zu ermöglichen. |
| Verschlüsselung | Gibt an, dass das Cookie mithilfe von Triple-DES oder DES verschlüsselt wird, die Datenüberprüfung wird jedoch nicht für das Cookie ausgeführt. Cookies, die auf diese Weise verwendet werden, können Klartextangriffen unterliegen. |
| Überprüfung | Gibt an, dass ein Überprüfungsschema überprüft, ob der Inhalt eines verschlüsselten Cookies während der Übertragung nicht geändert wurde. |
Von Bedeutung
Aus Sicherheitsgründen sollten Sie die Verschlüsselungs- und Validierungscookies voneinander trennen. Der Diebstahl von Verschlüsselungscookies wäre ein größeres Sicherheitsrisiko als der Diebstahl von Validierungscookies.
Wenn eine Anwendung Objekte enthält, die Clients häufig anfordern, verbessern Sie die Anwendungsleistung, indem Sie diese Objekte zwischenspeichern. Wenn der Benutzer vor dem Timeout des Authentifizierungscookies auf das zwischengespeicherte Objekt zugreift, bleibt das Objekt im Cache, und der Timer wird zurückgesetzt. Wenn der Benutzer jedoch während dieser Zeit nicht auf das zwischengespeicherte Objekt zugreift, entfernt IIS 8 das zwischengespeicherte Objekt aus dem Cache.
Erwägen Sie die Aktivierung dieser Einstellung unter den folgenden Umständen:
- Sie verfügen über einen begrenzten Arbeitsspeicher, der für die Zwischenspeicherung verfügbar ist.
- Sie müssen viele Objekte zwischenspeichern, da mit dieser Einstellung nur die am häufigsten angeforderten Objekte im Cache verbleiben können.
Hinweis
Sie geben die Anzahl der Minuten an, bevor ein Authentifizierungscookie (Ablauf in Minuten) abläuft.
ASP.NET Identitätswechselauthentifizierung
Verwenden Sie ASP.NET Identitätswechsel, wenn Sie Ihre ASP.NET Anwendung unter einem Sicherheitskontext ausführen möchten, der sich vom Standardsicherheitskontext für ASP.NET Anwendungen unterscheidet.
Wenn Sie den Identitätswechsel für eine ASP.NET-Anwendung aktivieren, kann diese Anwendung in einem von zwei verschiedenen Kontexten ausgeführt werden: entweder als von IIS 8 authentifizierter Benutzer oder als beliebiges Konto, das Sie eingerichtet haben. Wenn Sie beispielsweise die anonyme Authentifizierung verwenden und die ASP.NET Anwendung als authentifizierten Benutzer ausführen möchten, würde die Anwendung unter einem Konto ausgeführt, das für anonyme Benutzer eingerichtet ist (in der Regel IUSR). Wenn Sie sich für die Ausführung der Anwendung unter einem beliebigen Konto entschieden haben, würde sie unter dem für dieses Konto eingerichteten Sicherheitskontext ausgeführt.
Standardmäßig ist ASP.NET-Identitätswechsel deaktiviert. Wenn Sie den Identitätswechsel aktivieren, wird Ihre ASP.NET-Anwendung unter dem Sicherheitskontext des Benutzers ausgeführt, der von IIS 8 authentifiziert wurde.
4.4. Computerschlüsseleinstellungen
Computerschlüssel schützen Formularauthentifizierungs-Cookiedaten und Ansichtsstatusdaten auf Seitenebene. Sie überprüfen auch die Identifizierung des Sitzungszustands außerhalb des Prozesses. ASP.NET verwendet die folgenden Arten von Computerschlüsseln:
- Ein Überprüfungsschlüssel berechnet einen Nachrichtenauthentifizierungscode (MAC), um die Integrität der Daten zu bestätigen. Dieser Schlüssel wird entweder an das Formularauthentifizierungs-Cookie oder den Viewstate für eine bestimmte Seite angefügt.
- Ein Entschlüsselungsschlüssel wird verwendet, um Formularauthentifizierungstickets und den Ansichtszustand zu verschlüsseln und zu entschlüsseln.
MIT IIS 8 können Sie Validierungs- und Verschlüsselungseinstellungen konfigurieren und Computerschlüssel für die Verwendung mit ASP.NET Anwendungsdiensten generieren, z. B. Ansichtszustand, Formularauthentifizierung, Mitgliedschaft, Rollen und anonyme Identifizierung.
Bevor Sie Computerschlüssel für Ihre Anwendung generieren, treffen Sie die folgenden Entwurfsentscheidungen:
- Entscheiden Sie, welche Überprüfungsmethode verwendet werden soll: AES, MD5, SHA1 (Standard), TripleDES, HMACSHA256, HMACSHA384 oder HMACSHA512.
- Entscheiden Sie, welche Verschlüsselungsmethode verwendet werden soll: Auto (Standard), AES, TripleDES oder DES.
- Entscheiden Sie, ob der Überprüfungsschlüssel zur Laufzeit automatisch generiert werden soll.
- Entscheiden Sie, ob für jede Anwendung ein eindeutiger Überprüfungsschlüssel generiert werden soll.
- Entscheiden Sie, ob der Entschlüsselungsschlüssel zur Laufzeit automatisch generiert werden soll.
- Entscheiden Sie, ob für jede Anwendung ein eindeutiger Entschlüsselungsschlüssel generiert werden soll.
4.5. TLS/SSL-Kommunikation
Transport Layer Security (TLS) und sein Vorgänger,Secure Sockets Layer (SSL) sind Protokolle, die Kommunikationssicherheit Für Ihre Website bereitstellen. Sie können TLS/SSL verwenden, um Server und Clients zu authentifizieren und dann zum Verschlüsseln von Nachrichten zwischen den authentifizierten Parteien zu verwenden.
Im Authentifizierungsprozess sendet ein TLS/SSL-Client eine Nachricht an einen TLS/SSL-Server, und der Server antwortet mit den Informationen, die der Server selbst authentifizieren muss. Der Client und der Server führen einen zusätzlichen Austausch von Sitzungsschlüsseln durch, und das Authentifizierungsdialogfeld wird beendet. Nach Abschluss der Authentifizierung kann die SSL-gesicherte Kommunikation zwischen dem Server und dem Client beginnen, indem die symmetrischen Verschlüsselungsschlüssel verwendet werden, die während des Authentifizierungsprozesses eingerichtet werden.
Gehen Sie wie folgt vor, um TSL/SSL für Ihre Website zu konfigurieren:
- Holen Sie sich ein Serverzertifikat von einer Zertifizierungsstelle. Siehe Serverzertifikate.
- Fügen Sie der Website SSL-Bindung hinzu. Siehe SSL-Bindung.
- Legen Sie IIS so fest, dass SSL auf der Website erforderlich ist. Siehe "SSL für Ihre Website anfordern".
- Erwägen Sie die Verwendung von Clientzertifikaten für Ihre Website. Siehe Clientzertifikate.
Serverzertifikate
Sie können ein Serverzertifikat von einer Zertifizierungsstelle (CA) abrufen. Das Abrufen eines Serverzertifikats von einer Zertifizierungsstelle ist ein Schritt beim Konfigurieren von Secure Sockets Layer (SSL) oder Transport Layer Security (TLS). Sie können Serverzertifikate von einer Drittanbieterzertifizierungsstelle abrufen. Eine Zertifizierungsstelle eines Drittanbieters erfordert möglicherweise, dass Sie einen Identitätsnachweis angeben, bevor ein Zertifikat ausgestellt wird. Sie können auch eigene Serverzertifikate mithilfe einer Onlinezertifizierungsstelle ausstellen, z. B. Microsoft-Zertifikatdienste.
Digitale Zertifikate sind elektronische Dateien, die wie ein Onlinekennwort funktionieren, um die Identität eines Benutzers oder eines Computers zu überprüfen. Sie werden verwendet, um den SSL-verschlüsselten Kanal zu erstellen, der für die Clientkommunikation verwendet wird. Ein Zertifikat ist eine digitale Erklärung, die von einer Zertifizierungsstelle ausgestellt wird, die die Identität des Zertifikatinhabers bestätigt und es den Parteien ermöglicht, unter Verwendung von Verschlüsselung sicher zu kommunizieren.
Digitale Zertifikate haben die folgenden Aufgaben:
- Sie bestätigen, dass ihre Inhaber–Menschen, sowie Websites und sogar Netzwerkressourcen wie Router, wirklich das sind, was sie vorgeben zu sein.
- Sie schützen Daten, die online vor Diebstahl oder Manipulation ausgetauscht werden.
Digitale Zertifikate werden von einer vertrauenswürdigen Zertifizierungsstelle eines Drittanbieters oder einer Microsoft Windows Public Key-Infrastruktur (PKI) mit Zertifikatdiensten ausgestellt, oder sie können selbstsigniert werden. Jeder Zertifikatstyp hat Vor- und Nachteile. Jeder Typ des digitalen Zertifikats ist manipulationssicher und kann nicht gefälscht werden.
Zertifikate können für mehrere Verwendungen ausgestellt werden. Dazu gehören webbenutzerauthentifizierung, Webserverauthentifizierung, Secure/Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), Transport Layer Security (TLS) und Codesignatur.
Ein Zertifikat enthält einen öffentlichen Schlüssel und fügt diesen öffentlichen Schlüssel an die Identität einer Person, eines Computers oder diensts an, der den entsprechenden privaten Schlüssel enthält. Die öffentlichen und privaten Schlüssel werden vom Client und vom Server verwendet, um die Daten zu verschlüsseln, bevor sie übertragen werden. Für Windows-basierte Benutzer, Computer und Dienste wird das Vertrauen in eine Zertifizierungsstelle hergestellt, wenn eine Kopie des Stammzertifikats im Stammspeicher für vertrauenswürdige Zertifikate vorhanden ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Damit das Zertifikat gültig ist, darf das Zertifikat nicht widerrufen worden sein, und der Gültigkeitszeitraum darf nicht abgelaufen sein.
SSL-Bindung
Sie können einer Website mehrere Bindungen zuweisen, wenn Sie Über Websiteinhalte verfügen, die unterschiedliche Zwecke erfüllen oder für die Sie ein anderes Protokoll verwenden müssen. Beispielsweise kann eine Commerce-Website über eine Anwendung verfügen, die erfordert, dass benutzer sich bei einem Konto anmelden, um Waren zu kaufen. Das Unternehmen hostt die Website über HTTP, aber Benutzer müssen sich auf einer HTTPS-Seite bei ihrem Konto anmelden. In diesem Beispiel verfügt die Website über zwei Bindungen: eine für den HTTP-Teil und eine für den HTTPS-Teil.
Standardmäßig können Sie keine Bindungen für andere Protokolle als HTTP und HTTPS mithilfe des IIS-Managers hinzufügen. Wenn Sie eine Bindung für ein anderes Protokoll hinzufügen möchten, z. B. ein von Windows Communication Foundation (WCF) unterstütztes Protokoll, verwenden Sie eines der anderen Verwaltungstools. Wenn Sie jedoch den IIS File Transfer Protocol (FTP)-Server installieren, können Sie FTP-Bindungen mithilfe des IIS-Managers hinzufügen. Möglicherweise stehen auch andere Module oder Funktionen von Drittanbietern zum Herunterladen zur Verfügung, die die Benutzeroberfläche erweitern.
Ssl für Ihre Website anfordern
Die SSL-Verschlüsselung (Secure Sockets Layer) schützt vertrauliche oder persönliche Informationen, die zwischen einem Client und einem Server gesendet werden. Wenn SSL aktiviert ist, greifen Remoteclients mithilfe von URLs, die mit https:// beginnen, auf Ihre Website zu.
Konfigurieren Sie zuerst ein Serverzertifikat und erstellen Sie eine HTTPS-Bindung, um alle SSL-Einstellungen zu aktivieren. Fordern Sie dann eine SSL-Verschlüsselung (Secure Sockets Layer) unter einem oder mehreren der folgenden Umstände an:
- Wenn vertrauliche oder persönliche Inhalte auf Ihrem Server durch einen verschlüsselten Kanal geschützt werden müssen.
- Wenn Sie möchten, dass Benutzer die Identität Ihres Servers bestätigen können, bevor sie persönliche Informationen übermitteln.
- Wenn Sie Clientzertifikate verwenden möchten, um Clients zu authentifizieren, die auf Ihren Server zugreifen.
Clientzertifikate
Wenn Sie möchten, dass Clients ihre Identität überprüfen, bevor sie auf Inhalte auf Ihrem Webserver zugreifen, konfigurieren Sie Clientzertifikate. Standardmäßig werden Clientzertifikate ignoriert.
Bevor Sie ein Clientzertifikat auf Ihrer Website konfigurieren können, konfigurieren Sie ein Serverzertifikat und erstellen eine HTTPS-Bindung, um SSL-Einstellungen (Secure Sockets Layer) zu ermöglichen.
Wenn alle Clients ihre Identität überprüfen sollen, geben Sie an, dass Clientzertifikate erforderlich sind. Wenn einige Clients auf Inhalte zugreifen können, ohne zuerst ihre Identität zu überprüfen, geben Sie an, dass Clientzertifikate akzeptiert werden.