Certificate Authority mit OpenSSL und Python. - webca -

Transkript

1 Semesterarbeit Certificate Authority mit OpenSSL und Python - webca - an der Hochschule für Technik Zürich dem Fachbereich Informatik vorgelegt von Matthias Güntert im Oktober 2009 Referent: Peter Stadlin

2 Einführende Bemerkungen Version 292, publiziert im Oktober Matthias Güntert Lizenz. Dieses Werk ist unter einem Creative Commons Namensnennung- Keine kommerzielle Nutzung-Keine Bearbeitung 2.5 Schweiz Lizenzvertrag lizenziert. Um die Lizenz anzusehen, gehen Sie bitte zu oder schicken Sie einen Brief an Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA. Tipps für den Bildschirm Gebrauch. Diese Arbeit ist sowohl für den Bildschirm- wie auch für den Gebrauch auf Papier optimiert. Wenn möglich empfiehlt es sich aber, die digitale Version im PDF Format zu verwenden. Textprogramm. Dieses Dokument wurde mit OpenOffice Writer Version erstellt.

3 Erklärung Hiermit versichere ich, die vorliegende Arbeit selbstständig und unter ausschliesslicher Verwendung der angegebenen Literatur und Hilfsmittel erstellt zu haben. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt. Zürich, Oktober 2009 Ort, Datum Unterschrift (Matthias Güntert)

4 Zusammenfassung Zusammenfassung Ziel dieser Arbeit war die Konzeption und Entwicklung einer webbasierten Certificate Authority (CA), mit welcher über ein einfaches, plattformunabhängiges Interface (Browser) digitale Zertifikate beantragt, ausgestellt und verwaltet werden können. Die Applikation gliedert sich dabei in zwei Teile, nämlich in den Anwender- sowie den Administrationsteil, wobei die Administrationsoberfläche durch ein konfigurierbares Passwort geschützt ist. Mit der vorliegenden Applikation und Arbeit konnten viele Erfahrungswerte im Umgang mit OpenSSL, Python und Pylons gesammelt werden, welche bei der Weiterentwicklung der Diplomarbeit von Vorteil sein werden. Die Webanwendung ist mehr exemplarisch zu verstehen und soll aufzeigen, auf welchem Wege und mit welchen Mitteln sich das Ziel einer vollständig und webbasierten CA erreichen liesse (siehe dazu Ausblick Diplomarbeit).

5 Inhaltsverzeichnis Inhaltsverzeichnis Zusammenfassung... Inhaltsverzeichnis... 1 Verwendete Tools, Komponenten und Technologien Python Pylons Verzeichnisstruktur Erläuterungen zur Verzeichnisstruktur OpenSSL Erstellen eines selfsigned Root Zertifikats Erstellen eines Signing Requests Ausgeben eines Signing Requests Signieren eines Signing Requests Ausgeben eines x509 Zertifikats Zurückziehen eines Zertifikats Eclipse und Google Project Hosting Eclipse Konfiguration Python Paste Wichtige Paste Kommandos Mako Template Library for Python Beispiel Template Erläuterungen zum Beispiel MVC Pattern Model View Controller Konfiguration, Struktur und Benutzung der webca Pylons Konfiguration Verzeichnisstruktur Erläuterungen OpenSSL Konfiguration openssl.cnf Erläuterungen Benutzung der Applikation Administrationsoberfläche Anwenderoberfläche Hilfe zu den Modulen admin.py app_globals.py client.py login.py parser.py routing.py tools.py Konzept, ursprünglicher Ansatz und deren Problemfelder Zieldefinition Perl und Crypt::OpenSSL::CA OpenSSL Datenbank M2Crypto...43

6 Inhaltsverzeichnis 3.5 pyopenssl Ausblick Diplomarbeit Mögliche Verbesserungen der Anwendung Mögliche Erweiterungen...45 A Glossar und Abkürzungen...47 Index...

7 1 Verwendete Tools, Komponenten und Technologien 1 Verwendete Tools, Komponenten und Technologien Free Software is a matter of liberty, not price. Free as in free speech, not as in free beer [Frei im Sinne von Redefreiheit, nicht im Sinne von umsonst.] Richard M. Stallman 12 zu Open Source Zur Planung und Programmierung der Semesterarbeit wurden verschiedene Tools verwendet, welche im Folgenden kurz vorgestellt werden. Dabei war es dem Autor wichtig wann immer möglich OpenSource Software zu verwenden. 1.1 Python Python ist eine einfache und übersichtliche Programmiersprache, welche mit relativ wenig Schlüsselwörtern auskommt. Ausserdem kann sie objektorientiert, aspektorientiert sowie auch funktional eingesetzt werden. Auf der offiziellen Website 3 werden Interpreter für die wichtigsten Betriebssysteme zum Download angeboten. Man kann Python auf folgenden Plattformen verwenden: Linux, Windows, Macintosh FreeBSD, Solaris, OS/2, Amiga, AROS, AS/400, BeOS, OS/390, z/os, Palm OS, QNX, VMS, Psion, Acorn RISC OS, VxWorks, PlayStation, Sharp Zaurus, Windows CE und sogar PocketPC. Neben einer guten Dokumentation sprechen vor allem die umfangreichen Bibliotheken für die Verwendung dieser Sprache. So muss man sich nicht mit verschiedenen Java Designs oder C++ Übersetzer- oder Laufzeitfehler herumschlagen und kann sich auf das Konzept konzentrieren. Für die Semesterarbeit wurde Python in der Version 2.6 verwendet

8 1 Verwendete Tools, Komponenten und Technologien 1.2 Pylons Pylons ist ein plattform-unabhängiges OpenSource Webframework, welches starken Gebrauch des WSGI Standards macht. Das Framework ist in Python geschrieben und wird unter der BSD Lizenz zum Download angeboten. Es wurde stark von Ruby on Rails beeinflusst und vereint die besten Eigenschaften von Python und Perl. Zusätzlich werden das Datenbankschema, die Darstellung sowie die Programmlogik sauber getrennt. Dieses Architekturmodell ist unter dem Namen MVC Pattern bekannt (siehe dazu Kapitel 1.7 MVC Pattern) und wurde schon 1979 von Trygve Reenskaug 4 beschrieben 5. Pylons unterstützt verschiedene Templating Engines, wobei für die Semesterarbeit durchgehend Mako 6 verwendet wurde Verzeichnisstruktur Hier sieht man die Verzeichnisstruktur eines neu angelegten Pylons Ordners. (siehe dazu Kapitel Wichtige Paste Kommandos) $ tree pylons_project/ 1. pylons_project/ MANIFEST.in README.txt development.ini docs 6. `-- index.txt ez_setup.py ez_setup.pyo pylons_project init.py config init.py deployment.ini_tmpl environment.py middleware.py 16. `-- routing.py controllers init.py 19. `-- error.py lib init.py app_globals.py

9 1 Verwendete Tools, Komponenten und Technologien base.py 24. `-- helpers.py model 26. `-- init.py public bg.png favicon.ico index.html 31. `-- pylons-logo.gif templates tests init.py functional 36. `-- init.py 37. `-- test_models.py 38. `-- websetup.py pylons_project.egg-info PKG-INFO SOURCES.txt dependency_links.txt entry_points.txt not-zip-safe paster_plugins.txt requires.txt 47. `-- top_level.txt setup.cfg setup.py 50.`-- test.ini Erläuterungen zur Verzeichnisstruktur 7 Zeile 4: development.ini: Das Runtime Configuration File, welches zur Entwicklung der Applikation benötigt wird. Zeile 49: setup.py Das Application Setup wird hier vorgenommen. Zeile 14: environment.py Setzt die grundlegenden Umgebungsvariablen von Pylons, welche für die Ausführung der Applikation notwendig sind

10 1 Verwendete Tools, Komponenten und Technologien Zeile 15: middleware.py Hier wird der WSGI Stack des Projektes konfiguriert. Zeile 16: routing.py Konfiguration von URL zu Controller Mapping. Zeile 17: controllers Dieses Verzeichnis beinhaltet die verschiedenen Controller der Pylons Applikation (siehe dazu Kapitel 1.5.1, Abschnitt Anlegen eines neuen Controllers). Zeile 22: app_globals.py Bei der Instanziierung der Applikation wird das Objekt app_globals angelegt. Es bleibt während der gesamten Laufzeit bestehen und beinhaltet alle globalen Variablen und Objekte. Zeile 24: helpers.py Sogenannte Helpers sind Funktionen, welche für den Gebrauch in Templates oder für die Handhabung mit HTML und Textmanipulationen gedacht sind. Sie stehen dem Entwickler unter dem Objekt h zur Verfügung. Sollen weitere Helpers in der Anwendung verfügbar sein, so müssen diese hier importiert werden. Zeile 32: templates Dieses Verzeichnis enthält die Templates. Im Falle der Semesterarbeit handelt es sich um Mako Templates welche die Dateinamenerweiterung *.mako tragen. Zeile 33: tests Unit und Testfunktionen werden hier gespeichert. 4

11 1 Verwendete Tools, Komponenten und Technologien Zeile 38: websetup.py Beinhaltet das Setupscript für eine Pylonsanwendung. 1.3 OpenSSL OpenSSL 8 ist ein quelloffenes Kryptowerkzeug, welches die Secure Socket Layer (SSL v2/v3) und Transport Layer Security (TLS v1) Netzwerkprotokolle implementiert. Es kann zusätzlich in folgenden Bereichen benutzt werden: Erstellen von RSA, DH, DSA Schlüsselparametern Erstellen von X.509 Zertifikaten, CSR's und CRL's Berechnung von Message Digests Ent- und Verschlüsselung mit verschiedenen Chiffren SSL/TLS Client und Server Tests Umgang mit S/MIME signierten oder verschlüsselten s Die für die Semesterarbeit wichtigen Kommandos, als auch die dazugehörigen Parameter werden im nächsten Kapitel erklärt Erstellen eines selfsigned Root Zertifikats OpenSSL Aufruf: $ openssl req \ -config openssl.cnf \ -new \ -newkey rsa:2048 \ -x509 \ -extensions v3_ca \ -keyout CA/private/rootCA.key \ -out CA/certs/rootCA.crt \ -batch \ -passout pass:ca_password \ -subj /C=CH/ST=ZH/L=Zurich/O=Company/OU=IT/CN=rootCA \ -days aus 'man 1 openssl' 5

12 1 Verwendete Tools, Komponenten und Technologien Parametererläuterung 9 : -config openssl.cnf Dieser Parameter erlaubt ese eine alternative Konfiguration zu benutzen und überschreibt den zur Kompilierzeit angegebenen Dateinamen oder die in $OPENSSL_CONF spezifizierte Umgebungsvariable (siehe dazu Kapitel 2.2 OpenSSL Konfiguration). -new Generierung eines neuen Signing Requests. Der Benutzer wird aufgefordert, alle relevanten Daten für den DN einzugeben. Welche Daten mit welcher minimalen und maximalen Länge und was für Extensions abgefragt werden, ist in der OpenSSL Konfiguration in den Policy Sektionen festgehalten. -newkey rsa:2048 Dieser Parameter erstellt eine neue Zertifikats-Anfrage, sowie ein neues RSA Schlüsselpaar der Länge 2048 bit. Als Argument kann eine der folgenden zwei Formen verwendet werden: rsa:nbits, wobei nbits die Anzahl der Bits darstellt und ein RSA Schlüssel mit nbits erstellt wird. dsa:filename generiert einen DSA Schlüssel mit denen in der Datei 'filename' definierten Parametern. -x509 Diese Option gibt ein an der Stelle des Zertifikat Requests selbst signiertes Zertifikat zurück. Dieses wird typischerweise benutzt, um Testzertifikate zu erstellen oder aber um Root Zertifikate zu erzeugen. Die Extensions, welche dem Zertifikat hinzugefügt werden, sind in der OpenSSL Konfigurationsdatei festgehalten. Wenn mittels 'set_serial' Parameter nichts anderes spezifiziert wurde, wird '0' als Seriennummer verwendet. 9 aus 'man 1 req' 6

13 1 Verwendete Tools, Komponenten und Technologien -extensions v3_ca Ermöglicht die Auswahl eines Extensionabschnittes in der OpenSSL Konfiguration. -keyout CA/private/rootCA.key Hier wird angegeben, an welchen Ort der neu erstellte, private Schlüssel geschrieben werden soll. Ist dieser Parameter nicht vorhanden, wird derjenige in der Konfiguration verwendet. -out CA/certs/rootCA.crt Dieser Parameter legt fest, wo das Zertifikat gespeichert werden soll. Ansonsten erfolgt die Ausgabe auf einer Standardausgabe (STDOUT). -batch Wechsel in den nicht interaktiven Modus. -passout pass:ca_password Hier wird die Passwortquelle für die Ausgabedatei definiert. Genaueres findet sich in der Sektion 'PASS PHRASE ARGUMENTS' in 'man 1 openssl'. Als weitere Quellen können dienen: env:var: Bezieht das Password über die Umgebungsvariable var. file:pathname: Die erste Zeile der Datei pathname entspricht dem Passwort. fd:number: Liest das Passwort von einem Filedescriptor mit der Nummer number. stdin: Hier wird das Passwort über die Standardeingabe eingelesen. 7

14 1 Verwendete Tools, Komponenten und Technologien -subj /C=CH/ST=ZH/L=Zurich/O=Company/OU=IT/CN=rootCA Setzt den Subject Name für neue Requests oder überschreibt den Subject Name, wenn ein Request bearbeitet wird. Der Subject Name muss auf folgende Art formatiert sein: /type0=value0/type1=value1/type2=... Leer- und Sonderzeichen müssen mit Backslash escaped werden. -days 365 In Kombination mit dem Parameter '-x509' erfolgt die Angabe über die Dauer der Zertifikatsgültigkeit Erstellen eines Signing Requests OpenSSL Aufruf: $ openssl req \ -new \ -nodes \ -keyout CA/private/my_req.key -out CA/csr/my_req.csr -subj /C=CH/ST=ZH/L=Zurich/O=Company/OU=IT/CN=client_01 Parametererläuterung: 10 -new Generierung eines neuen Signing Requests. Der Benutzer wird aufgefordert, alle relevanten Daten für den DN einzugeben. Welche Daten mit welcher minimalen und maximalen Länge und was für Extensions abgefragt werden, ist in der OpenSSL Konfiguration in den Policy Sektionen festgehalten. -nodes Wenn dieser Parameter verwendet wird, erfolgt keine Verschlüsselung des erstellten Schlüsselpaares, was wichtig für die Verwendung des Zertifikats sein kann (z.b. bei Webservern). -keyout CA/private/my_req.key 10 aus 'man 1 req' 8

15 1 Verwendete Tools, Komponenten und Technologien Hier wird angegeben, an welchem Ort der neu erstellte, private Schlüssel geschrieben werden soll. Ist dieser Parameter nicht vorhanden, wird der Wert von private_key aus der OpenSSL Konfiguration verwendet. -out CA/csr/my_req.csr Dieser Parameter legt fest, wo der Request gespeichert werden soll. Ansonsten erfolgt die Ausgabe auf einer Standardausgabe (STDOUT). -subj /C=CH/ST=ZH/L=Zurich/O=Company/OU=IT/CN=client_01 Setzt den Subject Name des Antragstellers. Kann z.b. durch erweitert werden Ausgeben eines Signing Requests OpenSSL Aufruf: $ openssl req \ -text \ -noout \ -in CA/csr/my_req.csr Parametererläuterung: 11 -text Rückgabe des Signing Requests in Textform. -noout Unterdrückt die Ausgabe der PEM codierten Version des Requests. -in CA/csr/my_req.csr Spezifizierung der Eingabedatei, von welcher der Request gelesen werden soll. Ist dieser Parameter nicht vorhanden, wird versucht von der Standard Eingabe zu lesen (STDIN). Ein Request kann nur dann gelesen werden, wenn die Optionen '-new' und '-newkey' nicht angegeben wurden. 11 aus 'man 1 req' 9

16 1 Verwendete Tools, Komponenten und Technologien Signieren eines Signing Requests OpenSSL Aufruf: $ openssl ca \ -config openssl.cnf \ -out CA/certs/my_cert.crt \ -in CA/csr/my_req.csr \ -batch \ -passin pass:ca_password Parametererläuterung: 12 -config openssl.cnf Spezifizierung der zu verwendenden OpenSSL Konfigurationsdatei. -out CA/certs/my_cert.crt Es handelt sich hier um die Ausgabedatei, in welche das signierte Zertifikat geschrieben werden soll. Alle Zertifikatdetails werden zusätzlich in das File geschrieben. Bei Nichtverwenden des Parameters, wird die Ausgabe nach STDOUT geschrieben. -in CA/csr/my_req.csr Gibt an, welcher Request von der CA signiert werden soll. -batch Aktiviert den Batch Modus. In diesem Modus werden dem Benutzer keine Fragen gestellt und alle Zertifikate werden automatisch und ohne Sicherheitsabfrage signiert. -passin pass:ca_password Gibt die Quelle für das Password an. 12 aus 'man 1 ca' 10

17 1 Verwendete Tools, Komponenten und Technologien Ausgeben eines x509 Zertifikats OpenSSL Aufruf: $ openssl x509 \ -noout \ -text \ -in CA/certs/my_cert.crt Parametererläuterung: 13 -noout Unterdrückt die Ausgabe der codierten Version des Zertifikats. -text Gibt das Zertifikat in Textform zurück. Dazu werden Details über den öffentlichen Schlüssel, den verwendeten Signieralgorithmus, Issuer, Subject Name, Seriennummer, evtl. Extensions oder Trust Settings ausgegeben. -in CA/certs/my_cert.crt Spezifiziert die Eingabedatei, von welcher das Zertifikat gelesen werden soll. Wird dieser Parameter nicht verwendet, liesst OpenSSL von der Standardeingabe Zurückziehen eines Zertifikats OpenSSL Aufruf: $ openssl ca \ -revoke CA/certs/my_cert.crt \ -config openssl.cnf \ -batch \ -key ca_password Parametererläuterung: 14 -revoke CA/certs/my_cert.crt Gibt an, welches Zertifikat zurückgezogen werden soll. 13 Aus 'man 1 x509' 14 aus 'man 1 ca' 11

18 1 Verwendete Tools, Komponenten und Technologien -config openssl.cnf Spezifiziert die zu verwendende OpenSSL Konfiguration (siehe dazu Kapitel 2.2.OpenSSL Konfiguration). -batch Aktiviert den Batch Modus. In diesem Modus werden dem Benutzer keine Fragen gestellt und alle Zertifikate werden automatisch und ohne Sicherheitsabfrage signiert. -key ca_password Gibt das Passwort an, welches zur Verschlüsselung des privaten Schlüssels gebraucht wird. 1.4 Eclipse und Google Project Hosting Eclipse 15 ist eine OpenSource IDE, welche ursprünglich zur Entwicklung von Java Anwendungen geschrieben wurde. Durch seine enorme Erweiterbarkeit wird Eclipse mittlerweile auch zur Entwicklung von C, C++, Perl, PHP, ColdFusion, Ruby, Python, C# Fortran und Ada2005 Anwendungen verwendet. Die IDE selbst basiert auf Java und einem OSGI Framework namens Equinox. Für die Programmierung der Semesterarbeit wurden die Plugins pydev und Subclipse verwendet, welche unter Fedora 11 mit 'yum install eclipse-pydev eclipse-subclipse eclipse-platform eclipse-jdt' installiert werden können. Für das Hosting und Repository wurde 'Google Project Hosting' 16 verwendet. Google Project Hosting ist ein Hosting Service, welcher Revision Control sowohl mit Subversion als auch mit Mercurial anbietet. Neben einem Issuetracker und einer Wiki zur Dokumentation, stehen dem Benutzer 1 GB an Speicher zur Verfügung. Die Semesterarbeit ist unter der Adresse erreichbar, wobei der Sourcecode über

19 1 Verwendete Tools, Komponenten und Technologien werden kann. durchforscht Eclipse Konfiguration Um nun Google Project Hosting mit Eclipse nutzen zu können, sind folgende Schritte notwendig: Erstellen eines Gmail Accounts oder einloggen mit dem Selbigen Auf der Seite 'Create a new Project' anklicken und neues Projekt erstellen Im Eclipse Package Explorer über 'File' -> 'New' -> 'Other' 'Checkout Projects from SVN' auswählen Dort 'Create a new repository location' auswählen Als URL muss verwendet werden. Wichtig ist hier HTTPS anstatt HTTP zu verwenden, da sonst auf das Repository nur lesend zugegriffen werden kann. Auswahl des Ordners (z.b. trunk) und auf 'Next' Auswahl von 'Check out as a project configured using the New Project Wizard' und auf 'Finish' Auswahl von 'Pydev' -> 'Pydev Project' Jetzt muss das Projekt noch benannt und auf 'Finish' geklickt werden Im Package Explorer sollte nun das Projekt 'webca' gelistet werden 1.5 Python Paste Das Python Paste Paket 17 bietet hauptsächlich als Middleware fungierende Module an, welche zur Programmierung von Webapplikationen genutzt werden können. Jedes dieser Module benutzt das WSGI Interface (PEP 333) 18. Es beinhaltet einen einfachen Webserver welcher die Entwicklung von Pylons- basierten Applikationen vereinfacht. Ausserdem kann es zum Veröffentlichen und Paketiren von Anwendungen genutzt werden. 17 aus '$ yum info python-paste'

20 1 Verwendete Tools, Komponenten und Technologien Wichtige Paste Kommandos Erzeugen eines neuen Pylons Projekts 19 $ paster create --template=pylons my_project Anlegen eines neuen Controllers 20 $ paster controller controller_name Starten des Paste Webservers im Reload-Modus 21 $ paster serve -reload development.ini 1.6 Mako Template Library for Python Mako ist eine Template Library, welche in Python geschrieben wurde. Der Syntax ist an die besten Eigenschaften von Django Templates, Cheetah, Mygthy and Genshi angelehnt Beispiel Template 22 <%inherit file="base.html"/> <% rows = [[v for v in range(0,10)] for row in range(0,10)] %> <table> % for row in rows: ${makerow(row)} % endfor </table> <%def name="makerow(row)"> <tr> % for name in row: <td>${name}</td>\ % endfor </tr> </%def> 19 aus '$ paster help create' 20 aus '$ paster help controller' 21 aus '$ paster help serve'

21 1 Verwendete Tools, Komponenten und Technologien Erläuterungen zum Beispiel <%inherit file= base.html /> Mit dieser Anweisung erbt das Template die Eigenschaften des Files base.html und reiht sich somit in die Vererbungshierarchie ein. <%... / > oder <%... %> oder mit % beginnende Zeilen Gibt an, dass hier Python/Mako Code abgearbeitet wird. ${c.var} Erlaubt den Zugriff auf eine Kontextvariable innerhalb eines Mako-Templates mit dem Namen var. 15

22 1 Verwendete Tools, Komponenten und Technologien MVC Pattern Die MVC Architektur 26 gehört zu den wohl bekanntesten Entwurfsmustern in der Softwareentwicklung und teilt eine Anwendung in drei Bereiche auf. MVC Pattern Model Das Model beinhaltet die eigentlichen Rohdaten und wird in den meisten Fälllen eine Datenbank wie MySQL, Progress, etc. sein. Allerdings kann einer Software auch eine Datenbasis im XML oder Berkely DB Format zugrunde liegen. Bei Pylons entspricht dieser Bereich dem Verzeichnis: $ ~/pylons_project/pylons_project/model

23 1.7.2 View 1 Verwendete Tools, Komponenten und Technologien Der View Bereich übernimmt die Darstellung bzw. Eingabe/Ausgabe der Daten und fungiert als User Interface. Hier kommt die Python Template Engine Mako zum Zug. Entspricht dem Verzeichnis: $ ~/pylons_project/pylons_project/templates Controller Der Controller steuert die Anwendung und beinhaltet die eigentliche Programmlogik. Dieser Bereich empfängt Daten, verarbeitet sie und erstellt Antworten (Response). Entspricht dem Verzeichnis: $ ~/pylons_project/pylons_project/controllers 17

24 2 Konfiguration, Struktur und Benutzung der webca 2 Konfiguration, Struktur und Benutzung der webca 2.1 Pylons Konfiguration Verzeichnisstruktur $ tree webca/ 51.webca/ MANIFEST.in README.txt development.ini docs 56. `-- index.txt ez_setup.py setup.cfg setup.py test.ini webca init.py init.pyc config init.py init.pyc deployment.ini_tmpl environment.py environment.pyc middleware.py middleware.pyc routing.py 73. `-- routing.pyc controllers init.py init.pyc admin.py admin.pyc client.py client.pyc error.py error.pyc login.py login.pyc tools.py 86. `-- tools.pyc lib init.py init.pyc app_globals.py app_globals.pyc base.py base.pyc 19

25 2 Konfiguration, Struktur und Benutzung der webca helpers.py helpers.pyc parser.py 97. `-- parser.pyc model init.py 100. `-- init.pyc public openssl.cnf webca.css 104. `-- webca.css~ templates base.mako boot_strap.mako certs.mako login.mako make_req.mako 111. `-- sign_req.mako tests init.py functional init.py test_admin.py test_client.py 118. `-- test_login.py 119. `-- test_models.py 120. `-- websetup.py 121.`-- webca.egg-info PKG-INFO SOURCES.txt dependency_links.txt entry_points.txt not-zip-safe paster_plugins.txt requires.txt 129. `-- top_level.txt Erläuterungen NB: An dieser Stelle soll auf die ausführlichen Kommentare im Quelltext hingewiesen werden, welche detailliert beschreiben, welche Vorgänge an welcher Stelle im Programmablauf geschehen (siehe dazu Kapitel 2.4 Hilfe zu den Modulen). Zeile 55: docs Dieses Verzeichnis beinhaltet die Dokumentation der einzelnen Module. 20

26 2 Konfiguration, Struktur und Benutzung der webca Zeile 59: setup.py [...] name='webca', version='0.1', description='webbased certificate authority', author='matthias Guentert', [...] Festlegen der Standard Attribute für eine späteres Setup der paketierten Anwendung. Zeile 77: admin.py Dieses Modul beinhaltet alle für den Administrator der CA relevanten Funktionen: Initialisieren der Anwendung Ausgeben von Requests Löschen von Requests Signieren von Zertifikaten Zurückziehen von Zertifikaten Zeile 83: login.py In diesem Modul findet die Authentisierung für die Administrationsoberfläche statt. Zeile 85: tools.py Beinhaltet kleinere Helferfunktionen: Anlegen einer leeren Datei Anlegen eines Verzeichnisses Distinguished Name zusammensetzen Zeile 90: app_globals.py 21

27 2 Konfiguration, Struktur und Benutzung der webca Hier werden die Parameter der OpenSSL-Konfiguration ausgelesen und der Applikation unter der Variablen config['pylons.app_globals'].my_var zur Verfügung gestellt. Zeile 96: parser.py Das Parser Modul liesst mit der Funktion get_all_sections(filename) die OpenSSL Konfiguration ein und gibt diese als Wörterbuch (dict) zurück. Zeile 102: openssl.cnf Die in Abschnitt beschriebene OpenSSL Konfiguration. Zeile 106: base.mako Alle weiteren Mako Templates erben von dieser Datei. 2.2 OpenSSL Konfiguration Die OpenSSL Konfiguration befindet sich im Ordner: ~/webca/webca/public/openssl.cnf Sie besteht aus Sektionen, Attributen und den zugehörige Werten. Sie muss der Umgebung entsprechend angepasst werden. Die verschiedenen Verzeichnisse, sowie das Root Zertifikat und die Datenbank können dann über die Administrationsoberfläche eingerichtet werden. Erläuterungen zu den für die Semesterarbeit wichtigsten Attributen finden sich im Abschnitt Erläuterungen openssl.cnf 27 [...] #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir = /home/sp4rc/ca # Where everything is kept certs = /home/sp4rc/ca/certs # Where the certs are kept crl_dir = /home/sp4rc/ca/crl # Where the issued crl are kept database = /home/sp4rc/ca/index.txt # database index file. #unique_subject = no # allow creation of several # certs with same subject

28 2 Konfiguration, Struktur und Benutzung der webca new_certs_dir = /home/sp4rc/ca/newcerts # default place for new certs. certificate = /home/sp4rc/ca/certs/rootca.crt # The CA certificate serial = /home/sp4rc/ca/serial # The current serial number crlnumber = /home/sp4rc/ca/crlnumber # the current crl number must be # commented leave a V1 CRL crl = /home/sp4rc/ca/crl/rootca.crl # The current CRL private_key = /home/sp4rc/ca/private/rootca.key # The private key RANDFILE = /home/sp4rc/ca/private/.rand # private random number file x509_extensions = usr_cert # The ext. to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options # Extension copying option: use with caution. # copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # crlnumber must also be commented out to leave a V1 CRL. # crl_extensions = crl_ext default_days = 365 # how long to certify for default_crl_days = 30 # how long before next CRL default_md = sha1 # which md to use. preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) #policy = policy_match policy = policy_anything # For the CA policy [ policy_match ] countryname = match stateorprovincename = match organizationname = match organizationalunitname= optional commonname = supplied address = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryname = optional stateorprovincename = optional localityname = optional organizationname = optional organizationalunitname= optional commonname = supplied address = optional #################################################################### [ req ] default_bits = 1024 default_md = sha1 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The ext. to add to the self signed cert [...] # req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryname = Country Name (2 letter code) countryname_default = GB countryname_min = 2 23

29 2 Konfiguration, Struktur und Benutzung der webca countryname_max = 2 stateorprovincename stateorprovincename_default localityname localityname_default 0.organizationName 0.organizationName_default = State or Province Name (full name) = Berkshire = Locality Name (eg, city) = Newbury = Organization Name (eg, company) = My Company Ltd # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalunitname = Organizational Unit Name (eg, section) #organizationalunitname_default = commonname = Common Name (eg, your name or your server\'s hostname) commonname_max = 64 address = Address address_max = 64 # SET-ex3 = SET extension number 3 [ req_attributes ] challengepassword = A challenge password challengepassword_min = 4 challengepassword_max = 20 unstructuredname = An optional company name [ usr_cert ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. BasicConstraints = CA:FALSE # Here are some examples of the usage of nscerttype. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. # nscerttype = server # For an object signing certificate this would be used. # nscerttype = objsign # For normal client use this is typical # nscerttype = client, # and for everything including object signing: # nscerttype = client, , objsign # This is typical in keyusage for a client certificate. # keyusage = nonrepudiation, digitalsignature, keyencipherment # This will be displayed in Netscape's comment listbox. nscomment = "OpenSSL Generated Certificate" # PKIX recommendations harmless if included in all certificates. SubjectKeyIdentifier = hash authoritykeyidentifier = keyid,issuer # This stuff is for subjectaltname and issueraltname. # Import the address. # subjectaltname = copy # An alternative to produce certificates that aren't # deprecated according to PKIX. # subjectaltname = move 24

30 2 Konfiguration, Struktur und Benutzung der webca # Copy subject details # issueraltname=issuer:copy #nscarevocationurl #nsbaseurl #nsrevocationurl #nsrenewalurl #nscapolicyurl #nssslservername = [ v3_req ] # Extensions to add to a certificate request basicconstraints = CA:FALSE keyusage = nonrepudiation, digitalsignature, keyencipherment [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. SubjectKeyIdentifier authoritykeyidentifier = hash = keyid:always,issuer:always # This is what PKIX recommends but some broken software chokes on critical # extensions. #basicconstraints = critical,ca:true # So we do this instead. basicconstraints = CA:true # Key usage: this is typical for a CA certificate. However since it will # prevent it being used as an test self-signed certificate it is best # left out by default. # keyusage = crlsign, keycertsign # Some might want this also # nscerttype = sslca, ca # Include address in subject alt name: another PKIX recommendation # subjectaltname = copy # Copy issuer details # issueraltname = issuer:copy # DER hex encoding of an extension: beware experts only! # obj = DER:02:03 # Where 'obj' is a standard or added object # You can even override a supported extension: # basicconstraints = critical, DER:30:03:01:01:FF [ crl_ext ] [...] [ proxy_cert_ext ] [...] Erläuterungen dir = /home/sp4rc/ca Angabe des Basisverzeichnisses. Unter diesem Verzeichnis werden alle weiteren Ordner, Zertifikate, etc. angelegt. certs = /home/sp4rc/ca/certs Hier befindet sich das Root Zertifikat sowie, frisch signierte Zertifikate. 25

31 2 Konfiguration, Struktur und Benutzung der webca database = /home/sp4rc/ca/index.txt Das Datenbankfile mit dem Status der ausgestellten oder zurückgezogenen Zertifikate. certificate = /home/sp4rc/ca/certs/rootca.crt Definiert den Speicherort des Root Zertifikates, welches immer den oben angegebenen Namen haben muss. serial = /home/sp4rc/ca/serial Die zuletzt ausgestellte Seriennummer. private_key = /home/sp4rc/ca/private/rootca.key Der private Schlüssel der CA. default_days = 365 Definiert wie lange ausgestellte Zertifikate gültig sein sollen. Kann per Paremter überschrieben werden (-days). policy = policy_anything Hält fest, welche Policy zur Validation verwendet werden soll. [ policy_anything ] countryname = optional stateorprovincename = optional localityname = optional organizationname = optional organizationalunitname= optional commonname = supplied address = optional Hier sind die Schlüsselwörter optional, match und supplied gültige Werte. Sie definieren, wie die Attribute eines Requests überprüft werden und wie sie auf das Root Zertifikat passen müssen. 26

32 2 Konfiguration, Struktur und Benutzung der webca Optional: match: Der Benutzer kann ein Attribut frei eingeben Das vom Benutzer übermittelte Attribut muss zu dem entsprechenden Attribut des Root Zertifikates passen supplied: Attribut wird vom Benutzer angegeben [ v3_ca ] SubjectKeyIdentifier authoritykeyidentifier = hash = keyid:always,issuer:always # This is what PKIX recommends but some broken software chokes on critical # extensions. #basicconstraints = critical,ca:true # So we do this instead. basicconstraints = CA:true Dieser Extension-Abschnitt ist für selbst signierte Zertifikate gedacht, welche als Root- oder Testzertifikate Einsatz finden. basicconstraints = CA:true # or better # basicconstraints = critical, CA:true Die basiccontraints Erweiterung 28 gibt an, ob es sich um ein CA Zertifikat handelt, wobei die Arbeitsgruppe PKIX empfiehlt, diese als critical zu markieren. SubjectKeyIdentifier = hash Der Subject Key Identifier 29 identifiziert anhand eines eindeutigen Hashes den Schlüssel des Inhabers. authoritykeyidentifier = keyid:always,issuer:always Die Authority Key Identifier -Erweiterung wird verwendet, um den richtigen Ausstellerschlüssel ausfindig zu machen. Diese Extension muss laut PKIX vorhanden sein, stellt aber eine nicht-kritische Erweiterung dar

33 2 Konfiguration, Struktur und Benutzung der webca 2.3 Benutzung der Applikation Administrationsoberfläche Starten der Anwendung Um die Anwendung über den Paster Webserver zu starten, muss in das Projektverzeichnis gewechselt werden, das auch die Konfiguration enthält. Danach kann paster mit dem Parameter - reload aufgerufen werden. Dieser Parameter erleichtert die Entwicklung einer Pylons Anwendung enorm, da der Webserver nach jeder Änderung am Quelltext automatisch alle relevanten Komponenten neu lädt. $ paster serve --reload development.ini Starting subprocess with file monitor Starting server in PID serving on 28

34 2 Konfiguration, Struktur und Benutzung der webca Einloggen Nach dem Starten der Anwendung kann über die URL auf die Loginmaske zugegriffen werden. Der Benutzername und das Passwort für den Administratorzugriff können in der Pylons Konfigurationsdatei (z.b. development.ini) über die Attribute ca_admin_user und ca_admin_pass eingestellt werden. Als Vorgabe wurden Benutzer: admin und Passwort: admin gewählt. Initialisieren der webca Zum Initialisieren der CA muss auf die Seite CA Management gewechselt werden. Im Abschnitt Subject können die Attribute, welche später den DN bilden, eingegeben werden. Die dort angezeigten Pfade werden direkt aus der 29

35 2 Konfiguration, Struktur und Benutzung der webca OpenSSL Konfiguration ausgelesen und können in der vorliegenden Version nicht per Browser geändert werden. Der Button Boot Strap CA legt alle notwendigen Ordner und die Datenbank an. Ausserdem werden ein passwortgeschütztes RSA Schlüsselpaar sowie das selbst signierte Root Zertifikat erstellt und an der konfigurierten Stelle abgespeichert. CA Management Wie die Bezeichnung vermuten lässt, kann über die Schaltfläche Get CA Cert das Root Zertifikat heruntergeladen werden. Bei einem Klick auf Print CA Cert erfolgt eine Ausgabe im Textformat. Entsprechend kann über die Schaltfläche Print CA Config die OpenSSL Konfiguration ausgegeben und kontrolliert werden. 30

36 2 Konfiguration, Struktur und Benutzung der webca Überprüfen, Signieren oder Löschen eines Requests Über den Link Request Management werden die erzeugten oder hochgeladenen Signing Request eingesehen und überprüft. Ausgabe eines Certificate Signing Request Möchte man einen Request signieren, muss der entsprechende Eintrag aus der Liste ausgewählt und mit einem Klick auf Sign Request(s) digital mit dem Root Schlüssel unterschrieben werden. Bei diesem Vorgang wird der CSR aus dem Verzeichnis gelöscht und das neu erstellte Zertifikat in den konfigurierten Ordner verschoben. Ausserdem erstellt OpenSSL im Hintergrund einen Datenbankeintrag über den soeben ausgeführten Vorgang. 31

37 2 Konfiguration, Struktur und Benutzung der webca Signieren eines Requests Sollen für bestimmte Requests keine Zertifikate erstellt werden, können diese per Delete Request(s) gelöscht werden. Gründe dafür können beispielsweise fehlerhafte Request Dateien oder keine eindeutige Identifizierung des Antragstellers sein. 32

38 2 Konfiguration, Struktur und Benutzung der webca Ausgeben oder Zurückrufen eines Zertifikats Über das Certificate Management lassen sich ausgestellte Zertifikate ausgeben oder auch zurückrufen. Certificate Management Datenbankschema 30 $ cat index.txt R Z Z 01 unknown /C=CH/ST=ZH/L=Zurich/O=Company/OU=IT/CN=client_01 V Z 02 unknown /C=CH/ST=ZH/L=Zurich/O=Company/OU=IT/CN=client_04 Das erste Feld zeigt an, ob das Zertifikat gültig ((V)alid) oder abgelaufen ((e)xpired) ist, oder ob es zurückgezogen ((R)evoked) wurde

39 2 Konfiguration, Struktur und Benutzung der webca Das zweite Feld hält das Datum und die Uhrzeit der Zertifikats- Ausstellung fest, wobei zur Zeitnotation UTCTime 31 verwendet wird Das dritte Feld hält den Revocation Zeitpunkt fest Das vierte Feld ist von OpenSSL nicht implementiert und hat immer den Wert unknown Das fünfte Feld hält den Subject fest Anwenderoberfläche Serverseitige Requestgenerierung Um ein CSR vom Server erzeugen zu lassen, müssen die Attribute Country, State, Location, Organisation, Organisation Unit, Common Name und Address eingegeben werden. Welches Attribut was für Eingaben verlangt, hängt von der definierten Policy der OpenSSL Konfiguration ab. Erzeugen eines Certificate Signing Requests

40 2 Konfiguration, Struktur und Benutzung der webca Nach einem Klick auf Generate CSR, wird ein RSA Schlüsselpaar erstellt und der Request im konfigurierten Verzeichnis abgelegt. Von dort aus kann er später vom Betreiber der CA eingesehen, kontrolliert und signiert werden. Upload eines Requests Möchte man dem CA Betreiber einen anderweitig generierten Request schicken, so kann das über die Upload-Funktion geschehen. Wie man beispielsweise einen CSR mit OpenSSL auf der Konsole erzeugt, ist im Kapitel Erstellen eines Signing Requests erläutert. 2.4 Hilfe zu den Modulen Die Hilfe zu den Modulen wurde mit pydoc 32 (z.b. $ pydoc webca/controllers/admin.py > admin.txt) automatisch erstellt. Pydoc liest die Kommentare aus dem Quelltext und stellt sie in entsprechender Form dar. Es kann zwischen einer Text und HTML Darstellung gewählt werden. Diese Dateien befinden sich im Ordner: 'docs' (siehe dazu Alternativ könnte auch Sphinx 33 oder oder Pudge 34 verwendet werde admin.py Help on module admin: NAME admin FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/controlle rs/admin.py DESCRIPTION This module contains all necessary functions to administrate the certificate authority plication 35

41 2 Konfiguration, Struktur und Benutzung der webca Todo: * create system call handler * integrate better logging facility * add input validation * add status to each certificate in the listing (valid/revoked) CLASSES webca.lib.base.basecontroller(pylons.controllers.core.wsgicontroller) AdminController class AdminController(webca.lib.base.BaseController) Method resolution order: AdminController webca.lib.base.basecontroller pylons.controllers.core.wsgicontroller builtin.object Methods defined here: boot_strap(self) module to initialize the CA, it creates the folder structure, creates and fills the OpenSSL serial file, database. Also it creates a self signed Root Certificate Todo: * output folder/file creation to view * needs more/better checking certs(self) This module handles the CA's certificates, it is responsible for certificate printing and revocation, also the OpenSSL database can be printed. Todo: * provide better checks sign_req(self) This module is responsible for printing, signing and deleting of certificate signing requests. Todo: * Data and other attributes defined here: requires_auth = True Methods inherited from webca.lib.base.basecontroller: before (self) call (self, environ, start_response) Invoke the Controller Data descriptors inherited from pylons.controllers.core.wsgicontroller: dict dictionary for instance variables (if defined) weakref list of weak references to the object (if defined) DATA c = <paste.registry.stackedobjectproxy object at 0x18d7190> config = {'pylons.c_attach_args': True, 'buffet.template_...'charset':... log = <logging.logger instance at 0x18e60e0> request = <paste.registry.stackedobjectproxy object at 0x17da5d0> 36

42 2 Konfiguration, Struktur und Benutzung der webca response = <paste.registry.stackedobjectproxy object at 0x17f8650> session = <paste.registry.stackedobjectproxy object at 0x18cffd0> app_globals.py Help on module app_globals: NAME app_globals - The application's Globals object FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/lib/app_g lobals.py CLASSES builtin.object Globals class Globals( builtin.object) Globals acts as a container for objects available throughout the life of the application Methods defined here: init (self) One instance of Globals is created during application initialization and is available during requests via the 'app_globals' variable Data descriptors defined here: dict dictionary for instance variables (if defined) weakref list of weak references to the object (if defined) DATA config = {'pylons.c_attach_args': True, 'buffet.template_...'charset': client.py Help on module client: NAME client FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/controlle rs/client.py DESCRIPTION This module does not need any authentication checks a CA user can create signing requests to the administrator and also upload CSR's Todo: * check if uploaded file is really a CSR in PEM format * check if CSR is already there * validate user input using formencode schema * password protect CSRs for later key/cert downloading * add a module for key/cert downloading CLASSES webca.lib.base.basecontroller(pylons.controllers.core.wsgicontroller) ClientController class ClientController(webca.lib.base.BaseController) 37

43 2 Konfiguration, Struktur und Benutzung der webca Method resolution order: ClientController webca.lib.base.basecontroller pylons.controllers.core.wsgicontroller builtin.object Methods defined here: make_req(self) This function generates certificate signing request in PEM format Methods inherited from webca.lib.base.basecontroller: before (self) call (self, environ, start_response) Invoke the Controller Data and other attributes inherited from webca.lib.base.basecontroller: requires_auth = False Data descriptors inherited from pylons.controllers.core.wsgicontroller: dict dictionary for instance variables (if defined) weakref list of weak references to the object (if defined) DATA c = <paste.registry.stackedobjectproxy object at 0x1e1b0d0> config = {'pylons.c_attach_args': True, 'buffet.template_...'charset':... log = <logging.logger instance at 0x1e1aef0> request = <paste.registry.stackedobjectproxy object at 0x1d1a510> response = <paste.registry.stackedobjectproxy object at 0x1d38590> session = <paste.registry.stackedobjectproxy object at 0x1e13f10> login.py Help on module login: NAME login FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/controlle rs/login.py DESCRIPTION This module inherits from class BaseController and provides an easy way to authenticate a user using username and password. Every class using this need's to have a 'requires_auth = True' statement right after the class signature. CLASSES webca.lib.base.basecontroller(pylons.controllers.core.wsgicontroller) LoginController class LoginController(webca.lib.base.BaseController) Method resolution order: LoginController webca.lib.base.basecontroller pylons.controllers.core.wsgicontroller builtin.object Methods defined here: 38

44 2 Konfiguration, Struktur und Benutzung der webca index(self) Show login form. Submits to /login/submit logout(self) Logout the user, delete the session and display a confirmation message submit(self) Verify username and password Methods inherited from webca.lib.base.basecontroller: before (self) call (self, environ, start_response) Invoke the Controller Data and other attributes inherited from webca.lib.base.basecontroller: requires_auth = False Data descriptors inherited from pylons.controllers.core.wsgicontroller: dict dictionary for instance variables (if defined) weakref list of weak references to the object (if defined) DATA c = <paste.registry.stackedobjectproxy object at 0x2ef8d10> config = {'pylons.c_attach_args': True, 'buffet.template_...'charset':... log = <logging.logger instance at 0x7f7d985393b0> request = <paste.registry.stackedobjectproxy object at 0x2e03190> response = <paste.registry.stackedobjectproxy object at 0x2e23210> session = <paste.registry.stackedobjectproxy object at 0x2ef8b90> parser.py Help on module parser: NAME parser FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/lib/parse r.py DESCRIPTION This module parses the OpenSSL configuration file and returns it as a dictionary FUNCTIONS get_all_sections(filename) routing.py Help on module routing: NAME routing - Routes configuration FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/config/ro uting.py DESCRIPTION The more specific and detailed routes should be defined first so they 39

45 2 Konfiguration, Struktur und Benutzung der webca may take precedent over the more generic routes. For more information refer to the routes manual at FUNCTIONS make_map() Create, configure and return the routes Mapper DATA config = {'pylons.c_attach_args': True, 'buffet.template_...'charset': tools.py Help on module tools: NAME tools FILE /home/sp4rc/documents/studium/semesterarbeit/workspace/webca/src/webca/webca/controlle rs/tools.py DESCRIPTION This module contains some little helper functions and definitely need some more checks for the future. FUNCTIONS build_subject(country, state, location, organisation, organisation_unit, common_name, _address) Tiny helper function to build the distinguished name make_file(file) This function looks for the existence of a file, if it is not already there it gets created make_folder(folder) This function looks for the existence of a folder, if it is not there it gets created 40