[[:tux|{{ :linux.png?40|}}]] ===== Certification Authority (CA) ===== Eine >>Certification Authority (CA)<<((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. 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 >>private key<< und öffentlicher Schlüssel >>public key<< 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)) ==== Erstellen einer neuen CA ==== Vertrauen ist eine der Hauptanforderungen an SSL verschlüsselte Kommunikation und auch zugleich das Hauptproblem jeder selbst erstellten >>CA<<. Damit ein Client einem Serverzertifikat vertraut, muss es auch von einer vertrauenswürdigen >>CA<< ausgestellt worden sein. Möchte ich nun als Bandit ein gültiges uns seriöses Serverzertifikat für zb >>www.meinonlinebanking.de<< erstellen lassen, muss ich der ausstellenden >>CA<< meine Identität beweisen. Das geht von der Lieferung einer Kopie des Personalausweises bis hin zu notarieller Beglaubigung bei sicherheitsrelevanten Organisationen. Der Bandit könnte jetzt zwar eine eigene >>CA<< installieren und das Zertifikat seiner gekaperten Seite >>www.meinonlinebanking.de<< selbst ausstellen, nur hat er dann das Problem, dass kein Webbrowser diese ausstellende CA kennt und dieser somit auch nicht vertraut und eine Warnung ausgeben wird. Warum dann also selbst eine >>CA<< erstellen? Die Gründe können vielfältig sein und reichen vermutlich von bloßer Ignoranz über Zertikikate zu Demo und Dokumentationszwecken bis hin zu Unternehmenszertifikaten, wo die Client System vorhersagbar und somit bekannt sind. Bei bekannten Clientsystemen zB bestünde die Möglichkeit das Zertifikat der >>CA<< in den Zertifikatsspeicher des Clients als >>vertrauenswürdige CA<< zu importieren, was dann die Zertifikatswarnung beim aufrufen des >>SSL<< verschlüsselten Inhalts beseitigt. Man spricht dann von >>selbstsignierten Zertifikaten<< Eine eigene >>CA<< zum Erstellen >>selbstsignierte Zertifikate<< ist unter Linux im Handumdrehen installiert. Debian bringt mit dem Paket >>openssl<< bereits alle notwendigen Werkzeuge mit. Starten Sie das >>CA.pl<< Perlskript mit dem Parameter >>-newca<< und folgen Sie dem Assistenten: # /usr/lib/ssl/misc/CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... Generating a 2048 bit RSA private key .............................................+++ ................+++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase: *** Verifying - Enter PEM pass phrase: *** ----- snip ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:BY Locality Name (eg, city) []:Wolnzach Organization Name (eg, company) [Internet Widgits Pty Ltd]:Prontosystems.org Organizational Unit Name (eg, section) []:CA Common Name (e.g. server FQDN or YOUR name) []:prontotsystems.org Email Address []:camaster@prontosystems.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 12518091987949220495 (0xadb93256df60728f) Validity Not Before: Jun 3 20:30:29 2014 GMT Not After : Jun 2 20:30:29 2017 GMT Subject: countryName = DE stateOrProvinceName = BY organizationName = Prontosystems.org organizationalUnitName = CA commonName = prontotsystems.org emailAddress = camaster@prontosystems.org X509v3 extensions: X509v3 Subject Key Identifier: 1C:AE:23:F5:0A:3B:20:D1:CC:11:D3:82:4C:66:3D:31:2E:7F:B0:3A X509v3 Authority Key Identifier: keyid:1C:AE:23:F5:0A:3B:20:D1:CC:11:D3:82:4C:66:3D:31:2E:7F:B0:3A X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Jun 2 20:30:29 2017 GMT (1095 days) Write out database with 1 new entries Data Base Updated Das war es eigentlich schon auch, Sie finden nun ein Verzeichnis >>demoCA<< in dem Verzeichnis wo Sie das Kommando /usr/lib/ssl/misc/CA.pl -newca ausgeführt haben: # tree demoCA/ demoCA/ ├── cacert.pem ├── careq.pem ├── certs ├── crl ├── crlnumber ├── index.txt ├── index.txt.attr ├── index.txt.old ├── newcerts │   └── ADB93256DF60728F.pem ├── private │   └── cakey.pem └── serial 4 directories, 9 files //''It's just that simple''// ==== Zertifikatsanforderung erstellen ==== Um Zertifikate auszustellen benötigt man eine >>Zertifikatsanforderung<< bzw. einen >>Certificate Request<<. Darin verschlüsselt der Antragsteller diverse Information wie Land, Stadt, Provinz, Admin und vor allem den >>Common Name<< des Hosts welcher SSL anbieten soll. IdR ist das der >>Full Qualified Domain Name<< oder kurz >>FQDN<<, zB: >>www.example.com<<. IdR wird dieser CertRequest vom Serveradministrator des zu verschlüsselnden Hosts ausgefüllt. Führen Sie das folgende Kommando (idR) auf dem Server aus auf dem die zu verschlüsselnde Seite gehostet wird. Hier im Beispiel heißt der Host >>www.example.com<<. Dieser Name muss __exakt__ dem Namen des Server FQDN entsprechen. : # openssl req -new -nodes -keyout example.key -out example.csr -newkey rsa:2048 Generating a 2048 bit RSA private key ..............................+++ ......................................................................+++ writing new private key to 'example.key' ----- snip ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:BY Locality Name (eg, city) []:Wolnzach Organization Name (eg, company) [Internet Widgits Pty Ltd]:WWW Organizational Unit Name (eg, section) []:Public Common Name (e.g. server FQDN or YOUR name) []:>>www.example.com<< Email Address []:contact@example.de Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: **Note:** Sie können dieses Kommando auch auf jedem beliebigen Client System oder gar auf dem Server der die >>CA<< hostet ausführen, Sie müssen lediglich dafür Sorge tragen, dass der private Schlüssel >>example.key<< 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:** Wenn Sie bei der Zertifikatsanforderung ein >>Challenge Password<< 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 >>Challenge Password<< wieder eingeben. Viel Vergnügen auf Ihrer Atlantiküberquerung... ;-) Sie finden dann im Verzeichnis wo Sie das og Kommando ausgeführt haben die Dateien >>example.key<< was Ihren privaten Schlüssel repräsentiert und die Datei >>example.csr<< in welcher die Zertifikatsanforderung verschlüsselt wurde. Senden Sie nun dem >>CA-Administrator<< die Datei mit der Zertifikatsanforderung... ...und warten Sie geduldig, bis dieser Ihnen Ihr Zertifikat zukommen lässt. ==== Zertifikat ausstellen und signieren ==== Der >>CA-Administrator<< hat nun von Ihnen Ihre in der Datei >>example.csr<< verpackte Zertifikatsanforderung erhalten. Mit dem folgenden Kommando wird nun die Zertifikatsanforderung verarbeitet und ein signiertes Zertifikat >>example.cert<< erstellt. : # openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -out example.cert -infiles example.csr Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 12518091987949220496 (0xadb93256df607290) Validity Not Before: Jun 3 21:44:33 2014 GMT Not After : May 31 21:44:33 2024 GMT Subject: countryName = DE stateOrProvinceName = BY localityName = Wolnzach organizationName = WWW organizationalUnitName = Public commonName = >>www.example.com<< emailAddress = contact@example.de X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: FC:DA:FD:8D:87:2B:70:DF:56:02:8F:3F:B4:D0:35:FA:47:51:D6:68 X509v3 Authority Key Identifier: keyid:1C:AE:23:F5:0A:3B:20:D1:CC:11:D3:82:4C:66:3D:31:2E:7F:B0:3A Certificate is to be certified until May 31 21:44:33 2024 GMT (3650 days) Sign the certificate? [y/n]:**y** 1 out of 1 certificate requests certified, commit? [y/n]**y** Write out database with 1 new entries Data Base Updated Beachten Sie bitte die beiden Rückfragen >>Sign the certificate? [y/n]<< und >>1 out of 1 certificate requests certified, commit? [y/n]<< mit einem >>y<< zu beantworten. Das ausgestellte und signierte Zertifikat >>example.cert<< kann nun dem Antragsteller zurückgesendet werden. **Verwandte Artikel:** [[:it:ssl|SSL -> So funktioniert es]] [[:tux:apache_vhost|Virtuelle Hosts auf Apache2 Webserver einrichten]] --- //pronto 2014/06/05 09:26// {{keywords>openssl certification authority certificate request public private key sign}}