Praktische Experimente mit OpenSSL


ursprünglich für Tests genutzte OpenSSL-Version: 0.9.5a

Die Beispiele sollten auch für aktuellere OpenSSL-Versionen so funktionieren.

URLs:


neue Test-CA erzeugen (mit selbstzertifziertem Zertifikat)

  CA.sh -newca
Bei Verwendung der Standard-Einstellungen in /usr/local/openssl/openssl.cnf wird ein Verzeichnis demoCA erstellt, in dem u.a. folgende Informationen zu finden sind:
private/cakey.pem privater Schlüssel der CA
cacert.pem selbstzertifziertes Zertifikat der CA
index.txt Liste der bereits ausgestellten Zertifikate
serial Seriennummer für das nächste Zertifikat
newcerts Verzeichnis für erstellte Zertifikate

Das hier und nachfolgend genutzte Skript CA.sh dient der Vereinfachung einiger typischer OpenSSL-Operationen, indem es die jeweils benötigten OpenSSL-Kommandos mit geeigneten Argumenten aufruft.

Bei -newca wird bei OpenSSL 1.0.0c standardmäßig folgende Kommandofolge ausgeführt:

  openssl req -new -keyout ./demoCA/private/cakey.pem -out ./demoCA/careq.pem

  openssl ca -create_serial -out ./demoCA/cacert.pem -days 365 -batch -keyfile ./demoCA/private/cakey.pem \
    -selfsign -extensions v3_ca -infiles ./demoCA/careq.pem

Ein selbstzertifziertes Zertifikat kann man ausgehend vom Schlüsselpaar der CA auch so erstellen:

  openssl req -new -days 1000 -x509 -out cacert_selfsigned.pem -key private/cakey.pem

neuen Schlüssel sowie Zertifikatsanforderung erstellen

  CA.sh -newreq
Diese Kommando ist auf der Ebene des Elternverzeichnisses von demoCA auszuführen.

Resultat: newreq.pem

Diese Datei sollte gut aufgehoben werden, da sie neben der Zertifikatsanforderung auch den neu generierten privaten Schlüssel enthält.

Zertifikatsanforderung manuell für existierenden Schlüssel erstellen:

  openssl req -new -key newkey.pem -out newreq.pem

manuelle Erzeugung eines RSA-Schlüssels (ohne Passwort):

  openssl genrsa -out rsa_key 1024

Zertifikat erstellen (Zertifikatsanforderung signieren)

  CA.sh -sign
Dies entspricht bei OpenSSL 1.0.0c standardmäßg dem Kommando:
  openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem
Dieses Kommando ist auf der Ebene des Elternverzeichnisses von demoCA auszuführen. Die Zertifikatsanforderung wird in der Datei newreq.pem erwartet.

Resultat: newcert.pem

Empfehlung: Zertifikatsanforderung, den privaten Schlüssel sowie das Zertifikat umbenennen und aufheben, z.B.:

  cp newreq.pem HINZ/hinz_req.pem
  cp demoCA/newkey.pem HINZ/hinz_key.pem
  cp newcert.pem HINZ/hinz_cert.pem

Zertifikat verifizieren

  CA.sh -verify
Diese Kommando ist auf der Ebene des Elternverzeichnisses von demoCA auszuführen und verifiziert das Zertifikat in der Datei newcert.pem.

Beispiel:

  CA.sh -verify
  newcert.pem: OK

Anzeige, Verifikation, Hash-Links

Anmerkung: Das Skript c_rehash kann für die automatische Aktualisierung der Hash-Links aller Zertifikate in bestimmten Verzeichnissen genutzt werden.

Beispiel:

  c_rehash .
Dadurch werden für alle Dateien *.pem im aktuellen Verzeichnis neue Hash-Links erstellt.

Schlüssel und Zertifikat für SSL-Server (z.B. Apache) erstellen


Schlüssel und Zertifikat für den Apache-Server installieren

Statt Zertifikat und Zertifikat der CA könnte man auch das selbstzertifizierte Zertifikat verwenden:
  cp server_self.crt /etc/httpd/conf/ssl.crt/server.crt

Zertifikat einer CA in den Browser laden

Die Liste der bekannten Zertifikate von CAs findet man bei Netscape 4.x unter Security --> Certificates --> Signers. Diese Liste kann erweitert werden, indem der Browser per HTTP ein Dokument mit dem MIME-Inhaltstyp
  application/x-x509-ca-cert
lädt.

Neben CA-Zertifikaten können auch Nutzer-, E-Mail- und Server-Zertifikate in den Browser geladen werden. Die entsprechenden Inhaltstypen lauten:

  application/x-x509-server-cert
  application/x-x509-user-cert
  application/x-x509-email-cert
Das Laden von Zertifikaten kann z.B. über das Formular loadcert.html und das zugehörige CGI-Programm loadcert.pl erfolgen.

PKCS #12

Mit Hilfe dieses Formats kann der Netscape-Browser Zertifikate und private Schlüssel importieren und exportieren. Dies empfiehlt sich bei der (in der heutigen Praxis eher untypischen) Nutzung von Klienten-Zertifikaten für die Authentifizierung gegenüber einem WWW-Server. Diese Klienten-Zertifikate können mit OpenSSL generiert und konvertiert werden:

Fortify

Dieser Abschnitt ist heute bei Verwendung moderner Browser irrelevant.

Damit kann die in den für den Export bestimmten Netscape-Browsern nutzbare Menge von Cipher Suites für SSL erweitert werden.

Seit der Lockerung der US-Exportbestimmungen dürfen auch Browser exportiert werden, die starke Kryptographie unterstützen. Daher wurde das Projekt Fortify mit Netscape 4.72 eingestellt.

Zugriff auf einen Apache-Server mittels Netscape und SSL


SSL-Telnet

Der Server ließ sich in den Tests nur im Debug-Modus sinnvoll betreiben. Im Normalmodus, wenn er vom inetd gestartet wird, wird die Verbindung sehr früh beendet. Die Ursache ist unklar.

Der Telnet-Server entnimmt seinen privaten Schlüssel sowie sein Zertifikat standardmäßig der Datei /usr/local/openssl/certs/telnetd.pem. Hierfür ist z.B. die weiter unten bei Stunnel genutzte Datei kirke.stunnel verwendbar:

  cp KIRKE/kirke.stunnel /usr/local/openssl/certs/telnetd.pem

Start des Servers:

Nutzung des Klienten ohne Zertifikat (anonymes SSL bei Telnet, HTTP ...):

  telnet -z ssl kirke
  telnet -z ssl kirke 443

Nutzung des Klienten mit Zertifikat:

  telnet -z ssl -z cert=hinz_cert.pem -z key=hinz_req.pem kirke 443

s_client und s_server

Hierbei handelt es sich um einen SSL-Klienten sowie einen SSL-Server. Beide sind Bestandteil von openssl und eignen sich für Tests. Im folgenden werden einige Benutzungsbeispiele gezeigt.

Klient:

  openssl s_client -connect kirke:443
  openssl s_client -cipher DES-CBC-SHA -connect kirke:443
  openssl s_client -connect kirke:443 -key hinz_req.pem -cert hinz_cert.pem
HTTP-Anweisungen:
  GET /test/SSLrequire/1.html
  GET /sslcgi/printenv

Server:


privaten Key durch Netscape-Browser erstellen und per WWW zertifizieren lassen

Die HTML-Seite ca.html aus dem Paket Stunnel initiiert über das Tag
  <KEYGEN NAME="SPKAC">
die Schlüssel-Generierung und sorgt für den Versand der Zertifikatsanforderung im SPKAC-Format (signed public key and challenge) an den WWW-Server.

Das CGI-Programm ca.pl realisiert die Zertifizierung durch

  openssl ca -batch ...
und sendet das Ergebnis als
  Content-type: application/x-x509-user-cert
zurück.

Stunnel

Dieses Werkzeug stellt universelle SSL-Tunnel bereit.

Holger Trapp

letzte Modifikation: 29.12.2014