Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

tux:root_ca [2014/06/05 09:30]
wikisysop
tux:root_ca [2014/06/14 21:01] (aktuell)
wikisysop [Zertifikat ausstellen und signieren]
Zeile 2: Zeile 2:
 ===== Certification Authority (CA) ===== ===== Certification Authority (CA) =====
  
-Eine >><​fc #​008000>​Certification Authority (CA)</​fc><<​((http://​de.wikipedia.org/​wiki/​Zertifizierungsstelle)) ist eine Instanz die digitale Zertifikate erstellt und signiert, quasi digital unterschreibt. Damit wird ein öffentlicher Schlüssel einer Person oder Organisation beglaubigt. Somit soll sichergestellt werden, dass der Kommunikationspartner auch derjenige ist, den er vorgibt zu sein. Ein Anwendungsbeispiel für die Verwendung von digitalen Zertifikaten ist die Verschlüsselung der Kommunikation bestimmter Webseiten im Umgang mit sensiblen Daten, zB Logininformationen. ​+Eine >><​fc #​008000>​Certification Authority (CA)</​fc><<​((http://​de.wikipedia.org/​wiki/​Zertifizierungsstelle))((http://​www.tldp.org/​HOWTO/​SSL-Certificates-HOWTO/​x195.html)) ist eine Instanz die digitale Zertifikate erstellt und signiert, quasi digital unterschreibt. Damit wird ein öffentlicher Schlüssel einer Person oder Organisation beglaubigt. Somit soll sichergestellt werden, dass der Kommunikationspartner auch derjenige ist, den er vorgibt zu sein. Ein Anwendungsbeispiel für die Verwendung von digitalen Zertifikaten ist die Verschlüsselung der Kommunikation bestimmter Webseiten im Umgang mit sensiblen Daten, zB Logininformationen. ​
  
-Vereinfacht ausgedrückt verläuft der SSL-Handshake wie folgt((http://​publib.boulder.ibm.com/​tividd/​td/​TRM/​SC23-4822-00/​de_DE/​HTML/​user277.htm)):​ +Daten können nur dann ver- und entschlüsselt werden, wenn beide Kommunikationspartner die öffentlichen Schlüssel des jeweils anderen übermittelt bekommen haben. Das Schlüsselpaar privater Schlüssel >><​fc #​008000>​private key</​fc><<​ und öffentlicher Schlüssel >><​fc #​008000>​public key</​fc><<​ stehen in direktem Zusammenhang. Ein Datenpaket wird mit dem privaten Schlüssel des Senders und dem öffentlichen Schlüssel des Empfängers verschlüsselt und der Empfänger entpackt das Paket mit seinem privaten Schlüssel und den öffentlichen Schlüssel des Senders. Somit ist sichergestellt dass sich beide Kommunikationspartner kennen und sich kein dritter einschleichen kann ohne aufzufallen.((http://​publib.boulder.ibm.com/​tividd/​td/​TRM/​SC23-4822-00/​de_DE/​HTML/​user277.htm)) ​
- +
-  * Der Client sendet eine Anfrage zur verschlüsselten Kommunikation. +
-  * Der Server antwortet und sendet sein digitales Zertifikat. +
-  * Der Client prüft die Gültigkeit des Zertifikats. +
-  * Der Client antwortet mit einem zufällig generiert Schlüssel und verschlüsselt diesen mit dem öffentlichen Schlüssel des Servers. +
-  * Der Server verschlüsselt nun die Daten mit seinem privaten und dem öffentlichen (zufällig generierten) Schlüssel des Clients. +
-  * Der Client entschlüsselt die Daten mit seinem in Verbindung mit dem zufällig generierten privaten und dem öffentlichen Schlüssel des Servers. +
- +
-Somit können ​Daten nur dann ver- und entschlüsselt werden, wenn beide Kommunikationspartner die öffentlichen Schlüssel des jeweils anderen übermittelt bekommen haben. Das Schlüsselpaar privater Schlüssel >><​fc #​008000>​private key</​fc><<​ und öffentlicher Schlüssel >><​fc #​008000>​public key</​fc><<​ stehen in direktem Zusammenhang. Ein Datenpaket wird mit dem privaten Schlüssel des Senders und dem öffentlichen Schlüssel des Empfängers verschlüsselt und der Empfänger entpackt das Paket mit seinem privaten Schlüssel und den öffentlichen Schlüssel des Senders. Somit ist sichergestellt dass sich beide Kommunikationspartner kennen und sich kein dritter einschleichen kann ohne aufzufallen. ​+
  
  
Zeile 122: Zeile 113:
  ​**Note:​** Sie können dieses Kommando auch auf jedem beliebigen Client System oder gar auf dem Server der die >><​fc #​008000>​CA</​fc><<​ hostet ausführen, Sie müssen lediglich dafür Sorge tragen, dass der private Schlüssel >><​fc #​008000>​example.key</​fc><<​ auf dem richtigen Server und in den richtigen Händen gelangt. Geraten private Schlüssel in falsche Hände ist die Identität quasi gestohlen.  ​**Note:​** Sie können dieses Kommando auch auf jedem beliebigen Client System oder gar auf dem Server der die >><​fc #​008000>​CA</​fc><<​ hostet ausführen, Sie müssen lediglich dafür Sorge tragen, dass der private Schlüssel >><​fc #​008000>​example.key</​fc><<​ auf dem richtigen Server und in den richtigen Händen gelangt. Geraten private Schlüssel in falsche Hände ist die Identität quasi gestohlen.
  
-<note important>​**Note:​** Wenn Sie bei der Zertifikatsanforderung ein >><​fc #​008000>​Challenge Password</​fc><<​ vergeben müssen Sie dieses bei jedem Start des Webservers erneut eingeben. Verzichten Sie wenn möglich darauf, ansonsten kann es nach einer Systemstörung sein, dass Ihr Webangebot solange nicht mehr erreichbar ist, bis Sie das >><​fc #​008000>​Challenge Password</​fc><<​. Viel Vergnügen auf Ihrer Atlantiküberquerung... ;​-)</​note>​+<note important>​**Note:​** Wenn Sie bei der Zertifikatsanforderung ein >><​fc #​008000>​Challenge Password</​fc><<​ vergeben müssen Sie dieses bei jedem Start des Webservers erneut eingeben. Verzichten Sie wenn möglich darauf, ansonsten kann es nach einer Systemstörung sein, dass Ihr Webangebot solange nicht mehr erreichbar ist, bis Sie das >><​fc #​008000>​Challenge Password</​fc><< ​wieder eingeben. Viel Vergnügen auf Ihrer Atlantiküberquerung... ;​-)</​note>​
  
 Sie finden dann im Verzeichnis wo Sie das og Kommando ausgeführt haben die Dateien >><​fc #​008000>​example.key</​fc><<​ was Ihren privaten Schlüssel repräsentiert und die Datei >><​fc #​008000>​example.csr</​fc><<​ in welcher die Zertifikatsanforderung verschlüsselt wurde. Senden Sie nun dem >><​fc #​008000>​CA-Administrator</​fc><<​ die Datei mit der Zertifikatsanforderung... Sie finden dann im Verzeichnis wo Sie das og Kommando ausgeführt haben die Dateien >><​fc #​008000>​example.key</​fc><<​ was Ihren privaten Schlüssel repräsentiert und die Datei >><​fc #​008000>​example.csr</​fc><<​ in welcher die Zertifikatsanforderung verschlüsselt wurde. Senden Sie nun dem >><​fc #​008000>​CA-Administrator</​fc><<​ die Datei mit der Zertifikatsanforderung...
Zeile 173: Zeile 164:
  
 **Verwandte Artikel:** **Verwandte Artikel:**
 +[[:​it:​ssl|SSL -> So funktioniert es]]
 [[:​tux:​apache_vhost|Virtuelle Hosts auf Apache2 Webserver einrichten]] [[:​tux:​apache_vhost|Virtuelle Hosts auf Apache2 Webserver einrichten]]
  
tux/root_ca.1401953455.txt.gz (20208 views) · Zuletzt geändert: 2014/06/05 09:30 von wikisysop
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0