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

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«. 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.

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.