Eine »Certification Authority (CA)«¹⁾ 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²⁾:

• 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 »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.

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