Wenn Sie ein SSL-Zertifikat für Ihre Websites verwenden, erhalten Sie in erster Linie zwei Dinge:

1. Identitätsprüfung, dass Ihre Website diejenige ist, von der sie sagt, dass sie
2. Stream-Verschlüsselung der Daten zwischen ihnen ist Der Webserver und der Client
ol>

Indem Sie das tun, was Sie vorschlagen, was normalerweise als Selbstsignierung bezeichnet wird, können Sie sich nicht auf die Identitätsprüfung verlassen. Durch die Verwendung einer bekannten vertrauenswürdigen Zertifizierungsstelle kann der Client der Signaturkette von dem von Ihnen vorgelegten Zertifikat bis zu einer vertrauenswürdigen Zertifizierungsstelle auf Stammebene folgen und ein gewisses Vertrauen gewinnen, dass Sie der sind, für den Sie sich ausgeben. (Es sollte beachtet werden, dass dieses Vertrauen eher dem Glauben gleicht, da CA-Kompromisse auftreten und einige CAs das Proofing viel ernster nehmen als andere.)

Sie haben jedoch weiterhin die Datenverschlüsselung. Wenn Sie also den Vertrauensaspekt nicht benötigen, sollte es Ihnen gut gehen. Persönlich habe ich zu Hause mehrere Websites und Webanwendungen, für die ich selbstsignierte Zertifikate verwende. Da ich der einzige Benutzer bin, kann ich das Zertifikat angemessen manuell überprüfen, ohne dass ein Dritter mir mitteilen muss, dass der Computer unter meinem eigenen Schreibtisch wirklich der Computer unter meinem Schreibtisch ist.

Ich gehe davon aus, dass Sie Ihre eigenen Zertifikate ausstellen oder signieren und nicht hosten .

Unter dem Gesichtspunkt der reinen Sicherheit (Verschlüsselung / Datenvertraulichkeit) ist ein X.509c3-Zertifikat ein X.509c3-Zertifikat und bietet dieselbe Sicherheit für dieselbe Anzahl von Bits. Ein von Verisign ausgestelltes 2048-Bit-Zertifikat ist also genauso sicher wie ein von Ihnen ausgestelltes 2048-Bit-Zertifikat.

Aus Sicht der Vertrauenswürdigkeit (Identität) - für den durchschnittlichen Internetbenutzer Verisign oder einen anderen Drittanbieter als vertrauenswürdiger angesehen werden. Wenn Sie dies für eine enge Community tun, die Ihnen bereits vertraut, ist dieser Artikel auch eine Wäsche.

Aus Sicht des Risikomanagements müssen Sie entscheiden, ob Sie oder ein Dritter dies tun eine größere Möglichkeit eines Versagens und ob der Nutzen die Kosten überwiegt.

Der richtige Weg, dies zu tun, besteht darin, Ihre eigene private Zertifizierungsstelle zu betreiben. Anschließend können Sie mit Active Directory den öffentlichen Schlüssel der (selbstsignierten) Zertifizierungsstelle an alle Clientcomputer in Ihrem Netzwerk senden. Wenn Sie dies richtig machen, sollte niemand Zertifizierungswarnungen von seinen Browsern sehen.

Dies ist ein durchaus vernünftiger Ansatz für die Verwendung in einem internen Netzwerk (z. B. einem Unternehmensnetzwerk), wenn es nicht öffentlich ist -gesicht. Hier sind die Risiken:

• Ihre Sicherheit ist nur so gut wie die Sicherheit Ihres privaten CA-Vorgangs. Wenn der private Schlüssel für die private Zertifizierungsstelle an einen Angreifer weitergegeben wird oder ein Angreifer die Sicherheit des Systems verletzt, in dem der private Schlüssel der Zertifizierungsstelle gespeichert ist, sind alle Ihre Clients jetzt anfällig für nicht erkennbare Man-in-the-Middle-Angriffe. Das wäre schlecht Ähnliche Risiken bestehen, wenn Ihre private Zertifizierungsstelle jemals einen nicht vertrauenswürdigen öffentlichen Schlüssel signiert. Dies sind Probleme, mit denen sich große Zertifizierungsstellen befassen müssen. Wenn Sie Ihre eigene Zertifizierungsstelle werden, müssen Sie sich auch mit ihnen befassen.

• Ihre Sicherheit ist nur so gut wie die Sicherheit von Active Directory. Wenn ein Systemadministrator mit Kontrolle über den Active Directory-Dienst sein Konto gehackt hat, sind erneut Angriffe auf alle Ihre Clients möglich. Stellen Sie daher sicher, dass Ihr Active Directory-Dienst gut gesichert ist.

• Wenn Sie Benutzer haben, die von einem Computer, den Sie nicht verwalten, eine Verbindung zu Ihrem internen Webdienst herstellen, ist dies nicht der Fall. Wenn keine Verbindung über Ihr Active Directory hergestellt wird, werden Zertifizierungsfehler von ihrem Browser angezeigt, da der Browser den öffentlichen Schlüssel Ihrer privaten Zertifizierungsstelle nicht über Active Directory erhalten hat. Das ist schlecht, denn dann haben diese Benutzer keine Möglichkeit, die Authentizität Ihres internen Webdienstes zu überprüfen und sich nicht vor einem Man-in-the-Middle-Angriff zu schützen. Es ist auch schlecht, weil es diese Benutzer darin schult, Zertifizierungsfehler zu ignorieren, was sie für den Rest ihrer Internetnutzung anfällig machen kann.

  Dies ist heute ein wachsendes Risiko für viele Unternehmen, da viele Unternehmen den Trend zum "Bring-Your-Own-Devices" verfolgen. Beispielsweise möchten viele Mitarbeiter von ihren eigenen Smartphones, iPads usw. auf interne Webdienste zugreifen. Um Kosten zu sparen, möchten viele Unternehmen dies zulassen. Diese Geräte werden nicht über Ihr Active Directory verwaltet und führen daher zu einem solchen Risiko.

Alle diese Risiken können über geeignete Prozesse verwaltet werden, aber Sie haben sie über die Risiken Bescheid wissen und geeignete Prozesse einrichten, um sie anzugehen.

Das Hosten Ihres eigenen Zertifikats ist sicherlich kein Problem.

Ich denke, Sie meinen das Ausstellen Ihres eigenen Zertifikats (ob selbstsigniert oder über Ihre eigene Zertifizierungsstelle). Sie müssten natürlich den privaten Schlüssel schützen, aber das ist bei jedem Serverzertifikat der Fall. Wenn Sie Ihre eigene Zertifizierungsstelle verwenden, muss der private Schlüssel im Prinzip nicht einmal auf einem Server gehostet werden.

Gibt an, ob Sie stattdessen Ihre eigene Zertifizierungsstelle (oder ein selbstsigniertes Zertifikat) verwenden möchten Eine kommerzielle Zertifizierungsstelle ist sicherlich kein Sicherheitsrisiko (dies könnte das Vertrauen in diesen Server verbessern). Wie ich in dieser verwandten Antwort sagte, muss die Wahl der Zertifizierungsstelle jedoch immer aus Sicht des Benutzers berücksichtigt werden. Als Dienstanbieter ist dies nur wichtig, weil der Benutzer dem Zertifikat Ihres Dienstes vertrauen soll.

Der Vorteil der kommerziellen Zertifizierungsstellen besteht darin, dass sie standardmäßig in die meisten Browser eingebettet sind dass die Benutzer keine zusätzlichen Einstellungen benötigen, um Ihrer eigenen Zertifizierungsstelle zu vertrauen. Dies ist nur der einfache Weg, da Benutzer, die nichts über Zertifikate wissen, keine Fragen stellen müssen (was nicht großartig ist, aber die Bequemlichkeit gewinnt ...)

Angenommen, dies ist nur für die Verwendung in Ihrem privaten Netzwerk vorgesehen:

Sie können auch Ihre eigene lokale Zertifizierungsstelle ausführen. Anschließend generieren Sie Zertifikatsignierungsanforderungen und signieren sie mit dem Computer, den Sie als Zertifizierungsstelle eingerichtet haben. Anschließend geben Sie allen Computern im Netzwerk das CA-Zertifikat, damit sie Ihrer CA vertrauen. Auf diese Weise können Sie Ihre eigenen Zertifikate für den eigenen Gebrauch ausstellen und erhalten diese nervige Warnung nicht von Ihrem Browser.

http://www.g-loaded.eu/2005/11/ 10 / be-your-own-ca /

Ein Sicherheitsproblem besteht darin, dass Sie ein selbstsigniertes Zertifikat nicht widerrufen können, wenn es kompromittiert wird.

In Ihrem speziellen Szenario steuern Sie jedoch alle Clients sowie den Server wird kein Problem sein.

Und da Sie dies tun, um Spaß zu haben, werden Sie sehr wahrscheinlich das ganze Schwein gehen und eine private Zertifizierungsstelle einrichten, wie andere vorgeschlagen haben: In diesem Fall werden Sie es sein widerrufen können.

Es ist mir egal, ob sich Browser über die Tatsache beschweren, dass sie nichts über mich wissen, da ich der einzige sein werde, der HTTPS verwendet.

Die Sicherheit Das Risiko (vorausgesetzt, Ihr CA-Zertifikat ist nicht auf den Clients installiert) besteht darin, dass Sie jetzt für Man-in-the-Middle-Angriffe offen sind. Jemand kann sich als Server ausgeben, die gesamte Kommunikation zum eigentlichen Server tunneln, und der Client hat keine Ahnung, dass er mit dem falschen Server spricht. Mit anderen Worten, Sie haben praktisch keine Sicherheit. Es gibt einen Grund, warum sich der Browser beschwert. Wenn Sicherheit kein Problem darstellt, haben Sie kein Problem :-)

Wenn Sie Ihren Browser auf die Website Ihrer Bank richten und ein selbstsigniertes Zertifikat (oder ein nicht überprüfbares Zertifikat) vorlegen, geben Sie Ihre Anmeldeinformationen ein ? Schlechte Idee.

Ein vertrauenswürdiges Stammzertifikat ist die Art und Weise, wie Clients überprüfen, wer die Server sind, von denen sie behaupten, dass sie eine wichtige Komponente eines öffentlichen Schlüsselsystems sind (vorausgesetzt, die Parteien können die öffentlichen Schlüssel nicht über einige austauschen sichere Mittel.)

Beachten Sie, dass Sie Ihre eigenen Zertifikate, die noch eine Vertrauenskette haben, an eine bekannte Zertifizierungsstelle ausstellen können. Nicht jedes von Ihnen verwendete Zertifikat muss von einer bekannten Zertifizierungsstelle ausgestellt werden. Sie benötigen lediglich eine Vertrauenskette zu dieser CA. Sie agieren also im Grunde genommen als "Zwischen" -CA. Wie andere angemerkt haben, können Sie auch eine eigene "Root" -ZA haben und von dieser signierte Zertifikate ausstellen. Der Schlüssel besteht jedoch darin, das Stammzertifikat auf eine Weise an die Clients weiterzuleiten. Dann warnt der Browser nicht und Sie haben die gewünschte Sicherheit ...