projekt [ XiWiki ]

Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
# Linux Server gestützte Public-Key-infrastruktur (PKI) im Unternehmen mit Microsoft Active Directory Umgebung

## weiter Links

[[ projekt:impress?do=export_impressjs | Präsentation des Projektes ]] [[  projekt:impress | Bearbeiten der Präsentation ]]

[[ projekt?do=export_impressjs | Impress]] - [[https://github.com/bartaz/impress.js/ | Präsentation via Impress ]]





# Projektbeschreibung

## Projektumfeld 


Das Projekt wird in einer virtualisierte Umgebung mit einer DMZ[(gl:dmz)]-Netzwerk-Architektur der Firma <FIRMA1> ( <FIRMA1> hier Dienstleister / Auftragnehmer) als Tochter Unternehmen der <FIRMA2> (Kunde / Auftraggeber) entwickelt, getestet und für die gedachte Umsetzung im Hause der <FIRMA2> vorbereitet.

### Projektziel

#### Hauptziel

Es soll ein Lösungskonzept zum Aufbau einer einfachen PK-Infrastruktur im Unternehmensumfeld der <FIRMA2> erstellt werden. Bislang gibt es Intern keine geeignete Möglichkeit, welche den aufkommenden Daten-Verkehr zwischen den Clients den unterschiedlichen Angeboten an Diensten (u.a. über dei Protokolle HTTP[(gl:prot:http)] und FTP[(gl:prot:ftp)] an Dokumenten-Server) zu Verschlüsselung. Mittelfristig wird der Einsatz einer neuen Software vorbereitet, welche diese einfache PK-Infrastruktur[(gl:pki)] ebenso als Schnittstelle zur Datenübertragung beinhalten könnte.

 - Herstellen einer Kosten neutralen und überschaubaren Public-Key-Infrastruktur, Certificate Authority-Root (CA[(gl:ca)]-Root) &  Certificate Authority Intermediate (CA-Sign) für den Einsatz in einer Microsoft Active-Directory Umgebung.

 - Ausstellen von Root-CA und Sign-CA Zertifikat für die Gesamtstruktur ( test.pp )

 - Verteilung der CA-Zertifikate via Active Directory-DC Gruppen-Richtlinie und/oder per Software.

 - Ausstellen und Unterschreiben (Sign-CA) von Server-, Client- und Code-Signing-Zertifikate welche valide zur Root-CA und Sign-CA sind.

 - Kontinuierliche Erstellung und Bereitstellung einer Sperrliste


#### Teilziele

 - Erstellen / Abrufen von Client Zertifikaten via Web-Oberfläche ohne Administrationsrechte.

 - Aufheben ( Revoke ) von Zertifikaten via Web-Oberfläche mit u. ohne Administrationsrechten.

 - Auffrischen von CA-Zertifikate vor Ablauf der zeitlichen Gültigkeit
 

 - Auffrischen von Zertifikaten kurz vor Ende der zeitlichen Gültigkeit 
 - Überprüfung

 - Client Authentifizierung via Client Certificate am Web-Server

### Aufgabenstellung (IST Analyse - SOLL-Konzept)

- IST Zustand:

 - In einer betrieblichen Umgebung (Kunden IT-Infrastruktur) mit einer Microsoft Domäne im AD-DC Verbund von über 500 Clients und mehreren Server-Systemen, sowohl Hardware wie auch in virtualisierten Umgebungen z.B. über Terminal Server, werden Datenschutz relevanten Informationen über das bestehende Netzwerk zum großen Teil unverschlüsselt ausgetauscht.

- Soll-Zustand:
 - Es soll sichergestellt werden das innerhalb der Domäne keine dieser Informationen weiterhin unverschlüsselt über das Netzwerk übermittelt werden und somit vor unberechtigtem Zugriff bzw. Abgriff hinreichen Geschütz sind.

 - Den Clients soll ausschließlich nach Einbindung in die Domäne und entsprechender Gruppen-Zuweisung, die nötigen CA-Zertifikate übermittelt und anschließend durch ein Eigens für diesen Client erstelltes Zertifikat zur Authentifizierung, Autorisierung und Verschlüsselung auf den spezifischen Datenübertragungswege gegenüber den vorhandenen Server Systemen ermöglichen.


### Projektbegründung

Spätestens seid den sogenannten Snoden-Enthüllungen und Ransomware (Krypto-/Erpressungstrojaner) Angriffen, ist offensichtlich geworden das nicht nur gezielte Angriffe erfolgen müssen um Schäden in Millionen Höhe zu verursachen.

Mit dem Internet of Things (IoT) wächst die Gefahr durch fehlerhafte Massenware auch annähernd Zufällig sensible Daten zu verlieren oder preis zugeben. Gerade auch in Bezug auf Industriespionage wäre ein solchen zustande kommen für ein Unternehmen fatal.
Eine fehlerhafte Schnittstelle in einem Router oder Switch könnte bereits ausreichen, wie z.B. offene Lücken im `telnet`-Dienst.
[[ https://www.heise.de/security/meldung/Sicherheitsupdate-in-Sicht-Gravierende-Telnet-Luecke-bedroht-zahlreiche-Cisco-Switches-3658915.html | Sicherheitsupdate in Sicht: Gravierende Telnet-Lücke bedroht zahlreiche Cisco-Switches | 20.03.2017 ]] {{ :it:projects:druckversion_-_sicherheitsupdate_in_sicht-_gravierende_telnet-luecke_bedroht_zahlreiche_cisco-switches_-_heise_security.pdf | PDF Artikel - Heise Security - Gravierende "telnet"-Lücke }}

### Abgrenzungen

- der Aufbau einer vollständigen Domänen-Struktur mit Domäne, Tree oder Forest und/oder AD-DC ist nicht die Aufgabe
- LDAP und andere Autentifizierungsverfahren sind nicht Bestandteil der Aufgabe
- Funktionalität bei 2 / 3 Browsern sind hinreichend
- User- oder E-Mail Zertifkate sind nicht Bestandteil der Aufgabe
- Bewertung, Analyse oder Erstellung von Krypto-Verfahren sowie Encryption und/oder Decryption übertragender Daten sind nicht Bestandteil der Aufgabe
- Aufbau einer vollständige Sicherheits-Architektur rund um Webserver und andere Dienste ist nicht die Aufgabe

## Projektplanung

### Projektphasen

Das Projekt wurde für 35 Stunden gem. der IHK Vorgaben geplant. Die Meilensteine dienen nicht nur der Orientierung und Soll/Ist Vergleichspunkte sondern vor allem wie im iterativen Wasserfallmodell (erweit. Wasserfallmodell) vorgesehen, als Kontrollrückkopplung um eventuellen Schwierigkeiten bei der Umsetzung des Projektes mit geeigneten Maßnahmen frühzeitig entgegen wirken zu können. Und zwar rechtzeitig, bevor ein Projekt mangels Qualitätssicherungsmaßnahmen ganz oder teilweise scheitert.

### Abweichungen vom Projektantrag

#### Ursprünglich geplantes Power-Shell Script für Firefox

- das signieren und ausführen des PS-Script zur installation des Firefox Zertifikat-Store konnte nicht hinreichend getestet werden. Die Ausführung war wie geplant durch das Herstellen einer mind. nötigen Vertraulichkeit in der Domäne möglich.

- der korrekte Speicherbereich konnte nicht Zuverlässig ermittelt werden, in der kürze der Zeit.

- gemäß einer Ankündigungen von Mozilla solle diese Maßnahmen in naher Zukunft nicht mehr notwendig sein.

- das Auffrischen der CA-Zertifikate ist aus zeitlichen Gründen nicht umgesetzt worden.

### Ressourcen-Planung

Die zur Umsetzung des Projektes genutzte Hard- und Software sowie die mind. Systemvoraussetzungen werden im Anhang vollständig Aufgeführt und Beschrieben.

## Zeitplanung / Meilenstein (Projektmanagement)

### Projektphasen mit Zeitplanung (in Stunden)
<grid>
<col xs="1" lg="2"></col>
<col xs="7" lg="5">

^ Nr ^ Phase      ^   Kurz Beschr.      ^ Zeit          ^
| 1 | Projektstart | Vorstellung des Projektes | 1 h |
| 2 | Analyse & Definition | Soll-Ist Analyse | 2 h |
| 3 | [[ projekt#Entwurf | Entwurf ]] | Ausarbeitung Scripte | 5 h |
| 4 | [[ projekt#Implementation|  Implementation ]]  | Aufsetzen Server / Client Instanzen | 10 h |
| 5 | [[ projekt#Test_Validierung |  Test / Validierung ]]  | Testlauf Zertifikat Verteilung | 8 h |
| 6 | [[ projekt#Einsatz | Einsatz ]] | Roll-Out | 2 h |
| 7 | [[ projekt#Abschluss | Abschluss ]] | Übergabe | 7 h |
</col>
</grid>

### Detaillierte Zeitplanung und Meilensteine (mit Soll-Ist Datum)
<grid>
<col xs="1" lg="2"></col>
<col xs="8" lg="8">
^ Projektphase         ^^^    Gesamtstunden    ^ Meilenstein             ^ Zwischensumme ^     Teilsumme       ^ Datum ^
|1. Projektstart         |||    1 h    | |||  |
|    |1.1  Projekt Vorstellung    ||||    45 min    | |21.12.16 |
|    |1.2  Projekt Genehmigung    ||||    15 min    | |21.12.16 |
|2. Analyse & Definition         |||    2 h    | |||  |
|    |2.1  Durchführung IST-Analyse    ||||    30 min    | |27.03.17 |
|    |2.2  Durchführung SOLL-Analyse    ||||    1,25 h    | |27.03.17 |
|    |2.3  Formulierung Definition    ||||    15 min    | |27.03.17 |
|    ||    1. Meilenstein|| Abschluss A & D mit erfg. Formulierung    ||||
|3. [[ projekt#entwurf | Entwurf ]]        |||    5 h    | |||  |
|    |[[ projekt#openssl |3.1  openSSL ]]    ||||    2,75 h    | | |
|    |    |[[ projekt#template_caconf | 3.1.1 Template ca.conf ]]     |||| 1 h |27.03.17 |
|    |    |[[ projekt#bash_script_ca-certs | 3.1.2 BASH Script CA-Cert.sh ]]   |||| 15 min |27.03.17 |
|    |    |[[ projekt#template_ciccertsconf | 3.1.3 Template cic.certs.conf ]]   |||| 1 h |27.03.17 |
|    |    |[[ projekt#bash_script_cic-certsh | 3.1.4 BASH Script CIC-Cert.sh ]]  |||| 30 min |27.03.17 |
|    ||    2.1 Meilenstein|| BASH-Scripte Lösung Formuliert    ||||
|    |[[ projekt#microsoft_x509-storage |3.2  Microsoft X.509-Storage ]]   ||||    1,25 h    | | |
|    |    |3.2.1 [[ projekt#c_program_cert-installerexe | C# Program Cert-Installer.exe ]]   |||| 1h |27.03.17 |
|    |    |3.2.1 [[ projekt#ps_script_firefox_cert-installps1 | PS Script Firefox Cert-Install ]]   |||| 15 min | 27.03.17 |
|    |    |    2.2 Meilenstein|| X509-Stores Lösung Formuliert    ||||
|    |[[ projekt#web-interface | 3.3 Web-Interface ]]   ||||    1 h    | | |
|    |    |3.3.1 PHP Scripte    |||| 30 min |27.03.17 |
|    |    |3.3.1 Bootstrap Webpage    |||| 30 min | 27.03.17 |
|    ||    2.3 Meilenstein|| Web-Interface Konzipiert    ||||
|[[ projekt#Implementation | 4.  Implementation  ]]       |||    10 h    | |||  |
|    |4.1 [[ projekt#linux_server |Linux Server ]]    ||||    3 h    | | |
|    |    |4.1.1 Update & Installation    |||| 1 h |28.03.17 |
|    |    |4.1.2 BASH-Scripte Lösung integrieren    |||| 15 min |28.03.17 |
|    |    |4.1.3 Webserver Konfiguration    |||| 1 h |28.03.17 |
|    |    |4.1.4 CA Zertifikate erzeugen & einbinden   |||| 30 min |28.03.17 |
|    |    |4.1.5 Über Web-Server Prüfen    |||| 30 min |28.03.17 |
|    |    |4.1.6 Fehler Dokumentation    |||| 30 min |28.03.17 |
|    ||    3.1 Meilenstein|| BASH-Scripte Lösung integriert    ||||
|    |[[ projekt#windows_server_client |4.2  Windows Server & Client ]]  ||||    5 h    | | |
|    |    |4.2.1 Windows Server Updates     |||| 1 h |28.03.17 |
|    |    |4.2.2 Domäne-Controller konfigurieren     |||| 2 h |28.03.17 |
|    |    |4.2.3 Active Directory konfigurieren     |||| 1 h |28.03.17 |
|    |    |4.2.4 Windows Client Updates     |||| 1 h |28.03.17 |
|    |    |4.2.5 Windows Client in Domäne Aufnehmen     |||| 15 min |29.03.17 |
|    |    |4.2.6 Konnektivität zwischen allen Systemen prüfen    |||| 15 min |29.03.17 |
|    |    |4.2.7 Fehler Dokumentation     |||| 30 min |29.03.17 |
|    ||    3.2. Meilenstein|| Windows Server AD-DC funktionsfähig    ||||
|    |[[ projekt#web-interface | 14.3 Web-Interface ]]   ||||    1 h    | |  |
|    |    |4.3.1 Web-Interface einpflegen    |||| 15 min |29.03.17 |
|    |    |4.3.2 Web Ausgabe überprüfen    |||| 15 min |29.03.17 |
|    |    |4.3.3 HTTPs Verbindung protokollieren    |||| 15 min |29.03.17 |
|    |    |4.3.4 Fehler Dokumentation     |||| 15 min |29.03.17 |
|    ||    3.3. Meilenstein|| Webserver & Interface erreichbar    ||||
|5. [[ projekt#Test_Validierung | Test / Validierung  ]]         |||    8 h    | |||  |
|    |5.1 Server Test    ||||    3 h    | | |
|    |    |5.1.1 Funktionsprüfung Bereitstellung Zertifikate     |||| 30 min |29.03.17 |
|    |    |5.1.2 Funktionsprüfung Verteilung CA - Zertifikate    |||| 30 min |29.03.17 |
|    |    |5.1.3 Auswertung und Dokumentation Logs bzw. Events    |||| 1 h |29.03.17 |
|    |    |5.1.4 Fehlerkorrekturen    |||| 1 h |29.03.17 |
|    ||    4.1 Meilenstein|| Bereitstellung und Verteilung erfolgt    ||||
|    |5.2 Client Test    ||||    3 h    | | 31.03.17 |
|    |    |5.2.1 Abruf und Installation der Client Zertifikate    |||| 30 min |29.03.17 |
|    |    |5.2.2 Überprüfung Windows.Store und Browser Ausgabe    |||| 30 min | 29.03.17 |
|    |    |5.2.3 Auswertung und Dokumentation Logs bzw. Events    |||| 1 h |29.03.17 |
|    |    |5.2.4 Fehlerkorrekturen    |||| 1 h |30.03.17 |
|    |    |    4.2 Meilenstein|| Client Authentifizierung erfolgt    ||||
|    |5.3 Web-Interface Test   ||||    2 h    | |  |
|    |    |5.3.1 Web-Interface Funktionsprüfung   |||| 30 min |30.03.17 |
|    |    |5.3.2 Automatischer Abruf Client Zertifikate prüfen    |||| 30 min |30.03.17 |
|    |    |5.3.3 Fehlerkorrekturen    |||| 1 h |30.03.17 |
|    ||    4.3. Meilenstein|| Web Verwaltung und automatischer Abruf erfolgt    ||||
|6. [[ projekt#Einsatz | Einsatz  ]]         |||    2 h    | |||  |
|    |6.1 Zurücksetzen und 2. Durchlauf starten    ||||    1 h    | |30.03.17 |
|    ||    5. Meilenstein|| 2. Durchlauf erfolgreich ohne Fehler    ||||
|    |6.2 Einweisung und Übergabe an Kunden    ||||    1 h    | |  |
|    |    |6.2.1 Projekt Präsentation und Vorführung    |||| 30 min |29.03.17 |
|    |    |6.2.2 Abnahme durch Kunden    |||| 30 min |29.03.17 |
|7. [[ projekt#Abschluss | Abschluss  ]]         |||    7 h    | |||  |
|    |7.1 Nachbereitung    ||||    1 h    | | |
|    |    |7.1.1 Fehlerkorrekturen     |||| 30 min |30.03.17 |
|    |    |7.1.2 Versionierung abschließen    |||| 30 min |30.03.17 |
|    |7.2 Dokumentation    ||||    6 h    | | 31.03.17 |
|8. Projektende         |||    0 h    | |||  |
</col>
</grid>

## Wirtschaftlichkeit

Ein Schaden am Unternehmen, hervorgerufen durch 'Men in the Middle' Angriffe in Verbindung mit der Entwendung von Daten oder ähnlichem, ist nicht kalkulierbar, auch ein wirtschaftlichen Totalschaden kann die Folge sein.
Es gilt diese Schäden vom Unternehmen abzuwenden durch die Anwendung aller möglichen Maßnahmen, daher sind Sicherheitsmaßnahmen wie die Nutzung von kryptographischen Lösungen unabdingbar.

#### Projektkosten (Plan-/Ist-Kosten)

- Kurzfristige Kosten (fallen in diesem Projekt nicht an)
 - [empfohlen] Zusätzlicher Speicherplatz mit separater einfacher Sicherung ( RAID 1 ) wenn nicht bereits Vorhanden
 - [empfohlen] Datenträger zur Aufbewahrung der CA-Zertifikate ( 3x CD's und oder 2x USB-Sticks )
 - Angenommene Personalkosten
<grid>
<col xs="1" lg="2"></col>
<col xs="6" lg="4">
^ Vergabe ^ Stunden ^ Einzel ^ Summe ^
| Extern | 35 h | 85 € | ∑ 2975 € |
| Intern | 35 h | 35 € | ∑ 1225 € |
</col>
</grid>
- Mittelfristige Kosten
 - zusätzlicher geringer Stromverbrauch
 - [empfohlen] 4 Jahre Turnus, Erneuerung der Festplatten im RAID 1 Verbund

- In diesem Projekt kam nur frei zugängliche Software bzw. Open Source Software zur Anwendung.


# Projektverlauf






## Dokumentation

### Entwurf


#### Proof of Concept PKI-Struktur

{{ :documents:proof_of_concept_pki-struktur_v2.png?600 |}}{{ :documents:proof_of_concept_web-gui_v2.png?400 |}}

### Erleuterung PKI

{{ :documents:2017-05-09_14_06_46-enscript_output.png?200|}}

- Die Nutzung eines öffentliches Schlüssels erfordert eine Vertrauenstellung und setzt voraus das der Schlüssel im Besitz des richtigem Subjektes ist ( einer Person oder eines Systems ) bei dem ein Verschlüsselungs- oder digitaler Signaturmechanismus zur Anwendung kommt.

- Diese Vertrauensstellung wird durch die Verwendung eines öffentlichen Schlüsselzertifikates erreicht, welcher der Datenstruktur des Subjektes im öffentlichen Schlüssel verbindlich entspricht.

- Diese Verbindlichkeit wird durch eine CA mit einer digitalen Unterschrift erklärt.

- Diese Erklärung basiert auf technischen Möglichkeiten der CA, z.B. über eine Challenge-Response-Authentifizierung , über das Vorzeigen des privaten Schlüssels oder über eine Erklärung des Subjektes.

- Solche Zertifikate haben nur einen definierte begrenzte Lebenszeit, welche ein Teil des unterschriebenen Inhaltes ist. Dies ermöglicht die unabhängige Überprüfung bei Client-Zertifikat Authentifizierung. Solche Zertifikate können über nicht Vertrauenswürdige Kommmunikatinos- und Server-System verteilt werden, und in ungesicherten Speicher des zu zertifizierenden Clients abgelegt werden.

Übersetzung aus [(rfc5280)]

[(rfc5280>https://tools.ietf.org/html/rfc5280 | RFC5280 )]

[[ https://www.rfc-editor.org/rfc/pdfrfc/rfc5280.txt.pdf | RFC 5280 PDF ]][[ https://tools.ietf.org/html/rfc5280#page-9 | RFC 5280 PKI Def. 3.1 ]]

### Die PKI-Zertifikat Struktur für dieses Projekt

^  Certificate Authority  ^^  Subordinated CA  ^^  non-CA certificates  ^
|  CA: <FIRMA2> Root CA X1  |  -->|  Intermediate: <FIRMA2> Sign CA X2  |  -->|  Server  |
|  |  |  |  --> |  Client  |
|  |  |  |  -->|  Codesign  |

#### Script oder Binary Parameter

Der Script Aufruf erfolgt mit den folgen Parametern :

Beispiel: ` ./use_cert.sh -srv create PC-Name_001 192.168.0.1`
^ ^ Host-Type: ^ ^ Funktion: ^ ^ notwendige Angaben ^ optional ^
|  | ^Parameter: |   ^Parameter: | |  |
|1 | Server | -srv | Ausstellen | create | <Hostname>  <IP-Adresse> | <Tage> |  
|2 | Client | -cli | Sperren | revoke | <Hostname> | | 
|3 | Code | -code | Prüfen | check | <Hostname> | | 

#### Ordner-Struktur

Die angewandten Strukturen sollten bereits zu beginn des Projektes so konzipiert werden, das es möglich ist für andere Systeme einen Zugang zu schaffen. Beispielsweise müssen/sollten die Ordner für das Web-Interface nicht direkt im Hauptordner für den Webserver liegen.

Ausgearbeitet wurden die Funktionen: Erstellen, Sperren und Prüfen, welche auf die verschiedenen Zertifikats-Arten angewendet werden. Das sind Server, Client und Code Zertifikate die dazu notwendigen Angaben sind Hostname und IP-Adresse optional kann auch die Gültigkeitsdauer angegeben werden.

####  OpenSSL Ordner Strukturen:

- Hauptordner
^ Betriebssystem ^ Name ^ Location ^ Funktion          ^ File-Konfiguration ^ User ^
| Linux     | PKI-CA Hauptordner  | <file>/opt/ca/<CA-Class></file> |      Projekt Gesamt-Ordner         |   0755   |   root   |
| Linux     | CA-Root Zertifikate      | <file>/opt/ca/<CA-Class>/certs</file> | Ablage CA-Root Zertifikate     |   0755   |  root   |
| Linux     | CA-Sign Hauptordner    | <file>/opt/ca/<CA-Class>/intermediate</file> | Hauptordner Intermediate |   0755   |   www-data   |
| Linux     | Sign Zertifikate       | <file>/opt/ca/<CA-Class>/intermediate/certs/<HOSTNAME></file> | Ablage CA-Sign-Zertifikate |   0755   |   www-data   |
| Linux     | Web-Interface  | <file>/opt/ca/<CA-Class>/intermediate/ppwi</file> | HTML und PHP Scripte |   0755   |   www-data   |

- Unterordner
| Betriebssystem ^ Name ^ Location ^ Funktion  ^ File-Konfiguration ^ User
^ Linux     | Key Files  | <file>../privates</file> | Private Keys | 0755 | www-data |
^ Linux     | Config Files  | <file>../templates</file> | Konfigurationen | 0755 | www-data |
^ Linux     | Requests Files  | <file>../requests </file> | Anfragen | 0755 | www-data |
^ Linux     | CRL Files  | <file>../revokes</file> | Sperrungen  | 0755 | www-data |

Begriffe ( CA-Root, Intermediate, Sign, Key , Config , Requests , CRL , File-Konfiguration )


##### Apache Webserver

| Betriebssystem ^ Name ^ Location ^ Funktion ^ File-Konfiguration ^ User
^ Linux     | SSL-Config  | <file>/etc/apache2/sites-enabled/default-ssl.conf</file> | Webserver SSL Konfigurations-File | 0755 | root |
^ Linux     | Web-Interface  | <file>/var/www/html/ppwi</file> | <file>/opt/ca/<CA-Class>/intermediate/ppwi</file> | Symlink | www-data |

Durch die gewählte Struktur ist der Zugriff auf die notwendigen Dateien für die Ausführung der PHP-Scripte vereinfacht worden, auch braucht so die Versionsverwaltung in nur einem Ordner angewandt werden.

Der Ordner mit den Web-Interface Dateien wurde als Submodule der Versionsverwaltung bekannt gemacht.

<file sh>
 git submodule add [url] ppwi/
</file>
 

### openSSL	

Die Konfiguration der Profile für jeweilgen Zertifikat-Arten wurde mit der Version 3 des X.509 Standards ermöglicht.

Wichtige angaben wurden mit `default` vordefiniert. Diese sind ggf. bei Standort Änderungen und ähnlichen Anzupassen.

##### 3.1.1 Template ca.conf	

- Profil Datei für die CA:
 - <FIRMA2> CA Root X1
 - <FIRMA2> CA Sign X2 (ähnlich)

[SNIPPET]

<file bash>
countryName_default             =       DE
stateOrProvinceName_default     =       Sachsen-Anhalt
localityName_default            =       Magdeburg
0.organizationName_default      =       <FIRMA2> Test
organizationalUnitName_default  =       <FIRMA2> Root Certificate Authority
commonName_default              =       <FIRMA2> CA Root X1
emailAddress_default            =       <FIRMA2>@<FIRMA2>.local
</file>

[SNIPPET]
<file bash>
[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ v3_ca ]
# Extensions for a typical CA (`man X509v3_config`).
subjectKeyIdentifier 		= hash
authorityKeyIdentifier 		= keyid:always,issuer:always
basicConstraints 		= critical, CA:true
keyUsage 			= critical, digitalSignature, cRLSign, keyCertSign, dataEncipherment, keyEncipherment, nonRepudiation 
extendedKeyUsage 		= clientAuth, serverAuth, emailProtection, msCTLSign, msEFS, codeSigning, caIssuers
issuerAltName            	= issuer:copy
crlDistributionPoints    	= URI:http://pp-linux1/revoke.crl
nsComment                	= <FIRMA2> Stammzertifikat
</file>

Nach dem das Grundprofil für die Certificate Authority angelegt wurde kann die Bash-Verarbeitung umgesetzt werden.
Im weiteren Projekt Verlauf ist an dieser Stelle ein schwerwiegender Fehler deutlich geworden.
Im Ursprünglichen Entwurf habe ich bei der `extendedKeyUsage` nur die Werte `caIssuers`, `msCTLSign` und `msEFS` definiert gehabt.
Aus diesem Grund war es in der CA Hierarchie dem Intermediate-Zertifikat untersagt Client Zertifikate auszustellen, dies Führte bei der Client-Server Authentifizierung zur gegenseitigen Ablehnung Zertifikate. Es war notwendig auch `clientAuth` und `serverAuth` hinzuzufügen.

> Das unterzeichnende (Intermediate) Zertifikat muss die Funktionen welche sie signiert selbst beinhalten 


> eine weitere Möglichkeit um auch die Verwendung des Client Zertifikates einzuschränken besteht darin das `extendedKeyUsage` als `critical` zu definieren. ( ist für dieses Projekt jedoch nicht Vorgesehen )


##### 3.1.2 BASH Script CA-Cert.sh
[SNIPPET]

- Root Certificate:

<file bash>
openssl genrsa -aes256 -out privates/ca.key.pem  \
      -passout pass:$capw 4096

openssl req -config $caconfig \
      -key privates/ca.key.pem \
      -new -x509 -days 730 -sha512 \
      -extensions v3_ca \
      -out certs/ca.cert.pem \
	  -passin pass:$capw \
	  -batch
</file>

- Intermediate Certificate:

<file bash>
openssl genrsa -aes256 \
      -out intermediate/priates/intermediate.key.pem \
      -passout pass:$caspw 4096

openssl req -config $caiconfig -new -sha512 \
      -key intermediate/priates/intermediate.key.pem \
      -out intermedicsrests/intermediate.csr.pem \
	  -passin pass:$caspw \
	  -batch
openssl ca -config $caiconfig -extensions v3_intermediate_ca \
      -days 3650 -notext -md sha512 \
      -in intermediate/csr/intermediate.csr.pem \
      -out intermediate/certs/intermediate.cert.pem \
	  -passin pass:$capw \
	  -batch
</file>

##### 3.1.3 Template cic.certs.conf
[SNIPPET]

<file bash>
[ v3_usr_cert_ca ]
# Extensions for user certificates (`man X509v3_config`).
basicConstraints                                = CA:FALSE
nsCertType                                      = objsign, email
nsComment                                       = "<FIRMA2> CA :VAR6: Class 2 - :VAR5:"
subjectKeyIdentifier                            = hash
authorityKeyIdentifier                          = keyid,issuer
keyUsage                                        = critical, digitalSignature, keyEncipherment, nonRepudiation, dataEncipherment, keyAgreement 
extendedKeyUsage                                = codeSigning, emailProtection, msCodeInd, msCodeCom
crlDistributionPoints           		= URI:http://pp-linux1/:VAR6:/<FIRMA2>_policy_:VAR6:.crl
authorityInfoAccess                             = @ocsp_info
subjectAltName          			= $ENV::UAN
issuerAltName                                   = $ENV::UAN

[ v3_srv_cert_ca ]
# Extensions for server certificates (`man X509v3_config`).
basicConstraints                                = CA:FALSE
nsCertType                                      = server
nsComment                                       = "<FIRMA2> CA :VAR6: Class 2 - Server :VAR2:"
subjectKeyIdentifier                            = hash
authorityKeyIdentifier                          = keyid,issuer:always
keyUsage                                        = critical,  digitalSignature, keyEncipherment, nonRepudiation, dataEncipherment, keyAgreement 
extendedKeyUsage                                = serverAuth, clientAuth
crlDistributionPoints           		= URI:http://pp-linux1/:VAR6:/<FIRMA2>_policy_:VAR6:.crl
authorityInfoAccess                             = @ocsp_info
subjectAltName          			= $ENV::SAN


[ v3_cli_cert_ca ]
# Extensions for client certificates (`man X509v3_config`).
basicConstraints                                = CA:FALSE
nsCertType                                      = client
nsComment                                       = "<FIRMA2> CA :VAR6: Class 2 - Client :VAR2:"
subjectKeyIdentifier                            = hash
authorityKeyIdentifier                          = keyid,issuer
keyUsage                                        = critical,  digitalSignature, keyEncipherment, nonRepudiation, dataEncipherment, keyAgreement 
extendedKeyUsage                                = clientAuth
crlDistributionPoints           		= URI:http://pp-linux1/:VAR6:/<FIRMA2>_policy_:VAR6:.crl
authorityInfoAccess                             = @ocsp_info
subjectAltName          			= $ENV::SAN
</file>

##### 3.1.4 BASH Script CIC-Cert.sh
[SNIPPET]

- Client Certificate

<file bash>
openssl req -new -key $key -out $csr -config $cnf -batch;

openssl x509  -CA $int_crt_file -CAkey $int_key_file -CAcreateserial $passin -req -in $csr -days $4 -outform PEM  -out $pem  -$sha_rsa -extensions $v3_ext ; 

openssl ca -config $cnf -in $csr -days $4 -out $crt -extensions $v3_ext $passin -batch;

openssl pkcs12 -export -inkey $key -name "$2" -in $crt -out $pfx $passout ;
</file>

### Microsoft X.509-Storage 

#### C# Program Cert-Installer.exe
 - Das zu installierende PFX-File enthält neben dem Client-Zertifikat auch den Private-Key. Dieser Private Schlüssel ist zur Client-Authentifizierung gegen über einem Server notwendig.

 - Die Installation stellte eine besondere Herausforderung dar, der Download der <ClientName.pfx> und die Anschließende Installation in den Windows-Certificate Store ergab doch einige Hürden.
Die sinnvollste Lösung war den Bezug des PFX-Files für den Clienten über die `WebRequest` und `WebClient` Klassen per HTTPS zu realisieren.

 - Im Anschluss kam das folgende Programm [SNIPPET] zur Anwendung. {{ https://msdn.microsoft.com/de-de/library/ms148581(v=vs.110).aspx | Quelle: msdn.microsoft.com }}

[SNIPPET]
<code csharp>
       private void InstallCertPfx(string certpw)
       {
            try
            {
               string certPath = $@"{resultTempPath}\<FIRMA2>-{clientname}.pfx";
                var cert = new X509Certificate2(certPath, certpw);

                var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
                store.Open(OpenFlags.ReadWrite);
                if (!store.Certificates.Contains(cert))
                {
                    store.Add(cert);
                }
                var storepers = new X509Store(StoreName.TrustedPeople, StoreLocation.CurrentUser);
                storepers.Open(OpenFlags.ReadWrite);
                if (!storepers.Certificates.Contains(cert))
                {
                    storepers.Add(cert);
                }
              }
              ...
        }
</code>

Nach einigen Fehlversuchen und Fehlerkorrekturen konnte auch das hier vorliegende Mysterium zumindest umgangen werden.
Sowohl der Edge-Browser von Microsoft wie auch der Chrome, welche beide auf den Windows.X509Store zugreifen konnten sich sporadisch nicht am Server mittels des im `Eigene Zertifikate` befindliche Zertifikat (inkl. Private Key) Authentifizieren.
Im weiteren Verlauf erkante ich das bei dem Authentifizierung-Versuch auch auf den X509Store.Vertraute Personen zu gegriffen wurde.
Daher entschied ich für auch diesen Zertifikat-Storage anzusteuern.

Weiter sollte sichergestellt sein das kein bereits Installiertes Zertifikat wieder Exportiert wird mit privatem Schlüssel, daher wird das PFX-File vom Server aus mit einer Passphrase versehen und ausgeliefert. Diese Passphrase ist im Programm `Cert-Installer.exe` codiert hinterlegt.

#### PS Script Firefox MFF-Cert-Install.ps1

Für Firefox wird nicht ausschließlich ein PFX-File benötigt sonder kan auch ein PEM-File sein. [[ https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS | Quelle: developer.mozilla.org ]]

<code bash>
$ComputerName = "<FIRMA2>-cli"+$env:COMPUTERNAME".pem"

$ProfilePath = "C:\Users\" + $env:username + "\AppData\Roaming\Mozilla\Firefox\Profiles\"
$ProfilePath = $ProfilePath + (Get-ChildItem $ProfilePath | ForEach-Object { $_.Name }).ToString()

C:\ctmp\certs\nss\bin\certutil -A -n "<FIRMA2>" -t "CT,C,C" -i $certlocation\$ComputerName -d $ProfilePath 

</code>

- Zur Ausführung des PS-Scriptes auf der Domäne muss dieses noch Signiert werden. Voraussetzung dazu sind eine Installierte CA-Hierarchie und eine CodeSign Zertifikat. [[https://technet.microsoft.com/de-de/library/2008.04.powershell.aspx| Windows PowerShell signieren]]

- [[ it:win:pki#CodeSign | Wichtige Einstellungen und Einsicht in den X.509 Store]]

<code >
Set-ExecutionPolicy allsigned
$Zertifikat = @(gci cert:\currentuser\my -codesigning)[0]
Set-AuthenticodeSignature C:\powershell\MFF-Cert-Install.ps1 $Zertifikat
Sign MFF-Cert-Install.ps1 $Zertifikat 
</code>

### Web-Interface

- Übergabe der vom Web-Interface übergebenen Formular Informationen an das Script ./usr_cert.sh.

PHP-Code Snippet

<code php>
    function cert($parm)
    {
        exec('cd /opt/ca/x2/intermediate/; ./use_cert.sh '.$parm.' 2>&1', $out0);
                foreach ($out0 as $i)
                {
                    echo "<p> $i </p>";
                }
    }
</code>

- Bootstrap -> [[http://getbootstrap.com/|Quelle des freien Bootstrap CSS-Framework]]

### Implementation

#### 4.1 Linux Server
	
- 4.1.1 Update & Installation

<code bash>
apt update && apt upgrade -y;

apt install openssl apache2 php7.0-cli php7.0-curl php7.0-gd \ 
            php7.0-geoip php7.0-intl php7.0-json \ 
            php7.0-mbstring php7.0-mcrypt php7.0-mysql \ 
            php7.0-opcache php7.0-readline php7.0-xml \
            php7.0-xsl php7.0-zip;
</code>

- 4.1.2 BASH-Scripte Lösung integrieren
 
 - über git-Repository einbringen

<code bash>
git clone [url] /opt/ca
</code>

oder

 - Anlegen der Ordner Struktur (s.o) mittels `mkdir` 
 - Die vorbereiteten Dateien in die Ordner Struktur übertragen via FTP oder SSH/SFTP

- 4.1.3 Webserver Konfiguration

 - Das Script welches später ausgeführt wird erzeugt für den Server die nötigen Zertifikate unter `/opt/ca/intermediate/certs/srv-PPLINUX001`

 - der Apache2 Server muss noch für SSL Konfiguriert werden

<code bash>a2enmod ssl</code> 
 
 - und die Konfiguration:

`nano /etc/apache2/sites-available/default-ssl.conf`

 <code bash>
               SSLEngine on
               SSLUseStapling on
               SSLCertificateFile      /opt/ca/<CA CLASS>/intermediate/certs/srv-PPLINUX.crt
               SSLCertificateKeyFile   /opt/ca/<CA CLASS>/intermediate/privates/srv-PPLINUX001.pem
               SSLCertificateChainFile /opt/ca/<CA CLASS>/intermediate/certs/intermediate.crt
               SSLCACertificatePath    /opt/ca/<CA CLASS>/intermediate/certs/
               SSLCACertificateFile    /opt/ca/<CA CLASS>/intermediate/certs/ca.bundle.crt
               SSLCARevocationPath     /opt/ca/<CA CLASS>/intermediate/revokes/
               SSLCARevocationFile     /opt/ca/<CA CLASS>/intermediate/revokes/<FIRMA2>_policy_X1.crl
               SSLVerifyClient         optional
               SSLVerifyDepth          10
</code>

 - im Anschluss noch die Konfiguration aktivieren

<code bash>
   ln -s /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-enabled/default-ssl.conf ;
   apachectl -t ; </code>

Die Ausgabe sollte mit `Syntax OK` die korrekte Konfiguration bestätigen.

- 4.1.4 CA Zertifikate erzeugen & einbinden

<code bash>
    /opt/ca/ca_create.sh;
    /opt/ca/intermediate/use_cert.sh -srv create PP-LINUX1 192.168.6.201 365 ;
    chown -R www-data:www-data /opt/ca/intermediate;
    sleep 10;
    apachectl restart ;
</code>

- 4.1.5 Über Web-Server Prüfen

<code bash>
curl -Iv http://pp-linux1
</code>

Die Ausgabe sollte `* Connected to ... ` enthalten

oder den Web-Browser des Clients die Erreichbarkeit prüfen.

- 4.1.6 Fehler Dokumentation

 *  ``` d.Z. Keine Daten vorhanden ```

#### 4.2 Windows Server & Client
	
 - 4.2.1 Windows Server Updates
    
    Aufgrund der DMZ Restriktionen der virtuellen Umgebung können keine Updates bezogen werden.

- 4.2.2 Domäne-Controller konfigurieren

 * ``` d.Z. Keine weiteren Daten vorhanden ```

> Auf den Inhalt des Projektes ist sind am Domäne-Controller keine Einstellungen notwendig


> Die Clients müssen sich in der Domäne befinden


- 4.2.3 Active Directory konfigurieren

 - Gruppenrichtlinie 

{{ :documents:windows_2012_r2_gpo_msi.png?400|}}

Das Programm Cert-Installer.exe konnte nicht als EXE-File über die GPO verteilt werden, dies erforderte noch die Integration in ein MSI-File, was über die Software "Advanced Installer 13" realisiert wurde.

Im Anschluss kann über die GPO:

`-> Gruppenrichtlinien-Editor -> Client OU -> Default Domain Policy 

-> Computerkonfiguration -> Richtlinien -> Softwareeinstellungen -> Softwareinstallation` 

die MSI Datei an die Clients Verteilt werden.  


- 4.2.4 Windows Client Updates

 * ``` d.Z. Keine weiteren Daten vorhanden ```

- 4.2.5 Windows Client in Domäne Aufnehmen

 * ``` d.Z. Keine weiteren Daten vorhanden ```

- 4.2.6 Konnektivität zwischen allen Systemen prüfen

 * ``` d.Z. Keine weiteren Daten vorhanden ```

- 4.2.7 Fehler Dokumentation

 * ``` d.Z. Keine Daten vorhanden ```

#### 4.3 Web-Interface
	
- 4.3.1 Web-Interface einpflegen

<code bash>
  ln -s /opt/ca/x2/intermediate/ppwi/ /var/www/html/ppwi
  chown www-data:www-data /var/www/html/ppwi
</code>

- 4.3.2 Web Ausgabe überprüfen

1. Prüfung
<code bash>
 curl -L -k http://pp-linux1/ppwi
</code>

Die Ausgabe sollte HTML-Code enthalten

2. Prüfung

Über den Web-Browser die Webseite -> http://pp-linux1/ppwi und https://pp-linux1/ppwi aufrufen


- 4.3.3 HTTPs Verbindung protokollieren

Beispiel einer Positiven Verbindung im Logfile von Apache:

<code>
----END CERTIFICATE-----

Server certificate subject=/C=DE/ST=Sachsen-Anhalt/O=<FIRMA2> Test/OU=<FIRMA2> Root Certificate Authority/CN=PP-Linux1/emailAddress=PP-Linux1@192.168.6.201

issuer=/C=DE/ST=Sachsen-Anhalt/O=<FIRMA2> Test/OU=<FIRMA2> Root Certificate Authority/CN=<FIRMA2> Sign CA X3/emailAddress=<FIRMA2>@192.168.6.201

Acceptable client certificate CA names /C=DE/ST=Sachsen-Anhalt/O=<FIRMA2> Test/OU=<FIRMA2> Root Certificate Authority/CN=<FIRMA2> Sign CA X3/emailAddress=<FIRMA2>@192.168.6.201 /C=DE/ST=Sachsen-Anhalt/L=Magdeburg/O=<FIRMA2> Test/OU=<FIRMA2> Root Certificate Authority/CN=<FIRMA2> CA Root X1/emailAddress=<FIRMA2>@192.168.6.201 
Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: ...+SHA1:ECDSA+SHA1 
Shared Requested Signature Algorithms: ...SHA1 Peer signing digest: SHA512

Server Temp Key: ECDH, P-256, 256 bits

SSL handshake has read 8085 bytes and written 5673 bytes
</code>

- 4.3.4 Fehler Dokumentation

 * ``` d.Z. Keine Daten vorhanden ```

### Test / Validierung

Die Zertifikate können auf dem Linux-Server mittels openSSL geprüft werden.

<code bash>
openssl verify -CAfile /opt/ca/intermediate/certs/sign-ca-chain.crt <client-certificate>
</code>

Sollte die Ausgabe `OK` erzeugen.

Um einen ausschließlichen Client-Authentifizierungsvorgang zu provozieren muss der Apache2 Server noch einmal konfiguriert werden.

In der Datei `/etc/apache2/sites-available/default-ssl.conf` wird der Wert "optional" durch "require" ersetzt. Anschließend muss der Apache Dienst neugestartet werden.

<code>
     SSLVerifyClient require
</code>

Nach dem die Zertifikate an die Client(s) verteilt wurden, sollte mittels der Browser Edge und Chrome beim Aufrufen der Webseite https://pp-linux1/ eine Abfrage über das Zertifikat erfolgen und mit <OK> quittiert werden können. 

Dann nach sollte die Apache Test Seite zu sehen sein.

> Fehlercode: SSL_ERROR_HANDSHAKE_FAILURE_ALERT oder ähnliches weißt auf das Fehlen oder ein Fehlerhaftes Zertifikat hin.



der Linux-Client PP-Linux2 ermöglicht es hier noch eine Prüfung zu vollziehen

<code bash>
openssl s_client -connect pp-linux1:443 -CAfile ca-chain.cert.pem -cert publicCert.pem -key private.key -showcerts
</code>

Die Ausgabe sollte unter anderem `verify return:1` beinhalten.

### Einsatz

> Bei der Wiederholung der oben beschriebenen Vorgänge kam es nur durch eine fehlerhafte Web-Server Konfiguration zu einer Störung. Dann jedoch gab es keinen weiteren Schwierigkeiten.


> Dem Windows Server 2008 konnte mittels des Cert_Installer.exe / bzw. der MSI kein Zertifikat übermittelt werden, da keine sichere Verbindung über HTTPS aufgebaut werden konnte bzw. von Windows ablehnt wurde. Als Ursache habe ich den älteren Internet Explorer und  fehlenden Updates ermittelt.



### Abschluss





# Projekterfolg

### Soll-Ist-Vergleich

^ Nr ^ Ziel      ^   Kurz Beschr.      ^ Status          ^
|1| CA-Root | Ausstellen eines Certificate Authority Root Zertifikat | {{fa>check}} |
|2| CA-Sign | Ausstellen eines Certificate Authority Sign Zertifikat | {{fa>check}} |
|3| Client Certs | Ausstellen Client Zertifikate per Script | {{fa>check}} |
|4| Deploy CAs | Verteilen CA-Root/CA-Sign Zertifikat | {{fa>check}} |
|5| Deploy Client Certs | Abrufen & installieren Client Zertifikate | {{fa>check}} |
|6| Renew on expired CAs| Erkennen von Ablauf CAs Zertifikate und Erneuerung | {{fa>times}} |
|7| Web-Gen. Client Cert | Erzeugen von Client-Zertifikat via Web-Interface | {{fa>check}} |
|8| Gen. Revoke List | Erzeugen einer abrufbaren Sperrliste | {{fa>check}} |
|9| Cli-Srv Auth | Authentifizierung des Clients am Server via Zertifikat | {{fa>check}} |

### Ausblick

* Weitere Einsatzmöglichkeiten

 * Software Signierung
 
 * LDAP Zertifikate und ( [[https://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol | Wikipedia LDAP]] )
  
  * RFC 2587 
  * RFC 2559 
  * RFC 2459 

 * VPN Technologie

 *  


### Folgeaktivitäten

 * Erstellen einer Binary sowie eines Repository Package (deb bzw. rpm)

 * OCSP Erweiterung

 * Veröffentlichung GitHub

# Fazit

Das Projekt umfasste in der Planung 35 Stunden, diese Zeit konnte aufgrund einer Störung im betrieblichen Ablauf im Vorfeld des Projektes und wegen meines gravierenden Fehlers bezüglich der PKI-Vererbungshierarchie[(#1)] nicht absolut Eingehalten werden.

Mangels der Internet Anbindung und dem dadurch ausgebliebenen Updates der Windows Systeme habe ich 2 Stunden gewonnen, welche ich wie oben beschrieb dann 4 Stunden Fehler und Ursachen Behebung gegenrechnen muss. Der zeitlich Vergleich zwischen Soll und Ist wurde dem Anhang hinzugefügt. 

Auch musste ich feststellen das das strengende erw. Wasserfallmodell nicht zwangsläufig die beste Wahl sein muss für solche Projekte.
Das ständige Hin und Her zwischen den Plattformen, die Abhängigkeiten bei Server Zertifikat und Client-Authentifizierung sowie das damit verbundene neustarten der Dienste konnte auch nicht den Fehler Frühzeit erkenntlich machen.

# Glossar

[(gl:ca>CA - Certificate Authority)]

[(gl:dmz> DMZ - Demilitarisierte Zone)]

[(gl:pki> PKI - Demilitarisierte Zone)]


[(gl:prot:http> HTTP - Hyper Text Transfer Protokoll - Port 80)]

[(gl:prot:https> HTTPS - Hyper Text Transfer Protokoll Secure - Port 443)]

[(gl:prot:ftp> FTP - File Transfer Protokoll - Port 21)]




~~REFNOTES gl ~~

###Protokolle

~~REFNOTES gl:prot ~~

^  Kürzel  ^Erklärung   ^
|  DMZ  |Demilitarisierte Zone    |
|  Isuser  |  |

# Abbildungsverzeichnis

# Quellennachweis

~~REFNOTES~~


~~REFNOTES cite 10 ~~
~~REFNOTES cite /2 ~~

===== Citations =====


<refnotes cite /2> refnote-id: i; note-preview: none </refnotes>


[(rfc5820>rfc5820)] - [[ https://tools.ietf.org/html/rfc5820 ]]

[(RFC6818>RFC6818)] - [[ https://tools.ietf.org/html/rfc6818 ]]
		 
[[https://tools.ietf.org/html/3280 | RFC3280 ]]	 
		 
[[http://www.alvestrand.no/objectid/2.5.29.32.0.html | "anyPolicy" - Wildcard ]]	 
		 
		 
[[https://social.technet.microsoft.com/wiki/contents/articles/3147.pki-certificate-chaining-engine-cce.aspx | PKI-Certificate-Chaining]]	 
		 

[[https://www.sysadmins.lv/blog-en/certificate-policies-extension-all-you-should-know-part-1.aspx| Policy identifier - PEN]]

[[http://pen.iana.org/pen/PenApplication.page | PEN Request - iana]]	 

# Anlagen / Anhang:

### Weitere Angaben

 - Domäne: test.pp

- Signaturalgorithmus / Hash-Algorithmus : sha256rsa / sha256

- Root-CA: <FIRMA2> CA Root X1
- Sign-CA: <FIRMA2> CA Sign X2

<FIRMA2> CA Root X1
<file>
countryName_default             =       DE
stateOrProvinceName_default     =       Sachsen-Anhalt
localityName_default            =       Magdeburg
0.organizationName_default      =       <FIRMA2> Test
organizationalUnitName_default  =       <FIRMA2> Root Certificate Authority
commonName_default              =       <FIRMA2> CA Root X1
emailAddress_default            =       <FIRMA2>@<FIRMA2>.local
</file>

<FIRMA2> Sign CA X2
<file>
countryName_default             =       DE
stateOrProvinceName_default     =       Sachsen-Anhalt
localityName_default            =       Magdeburg
0.organizationName_default      =       <FIRMA2> Test
organizationalUnitName_default  =       <FIRMA2> Root Certificate Authority
commonName_default              =       <FIRMA2> Sign CA X2
emailAddress_default            =       <FIRMA2>@<FIRMA2>.local
</file>

## Ressourcen


- Virtuelle Umgebung und Betriebssystem

| Name             ^ IP          ^ Betriebssystem ^ Funktion          ^ Konfiguration ^ 
^ PP-Linux1        | 192.168.6.201 | #93-Ubuntu SMP     | PKI-Server             | Ground          |
^ PP-Linux2        | 192.168.6.202 | #93-Ubuntu SMP     | Example SRV/CLI        | Ground          |
^ w2k8-template    | 192.168.6.203 | Windows Server 2k8 | AD-Domäne Controller   | Template        |
^ TestCli          | 192.168.6.204 | Windows 10         | Example Client         | Template        |

- Netzwerk Konfiguration

 - Netzwerk: 192.168.6.0 / 24 GW .1

#### Anforderungen

  - Version 3 X.509 Standard ( X.509v3 )
  - mind. SHA256 in Zertifikaten
  - Linux Server
    - Apache Web-Service / NginX Web-Service
    - MySql bzw. MariaDB Datenbank
    - SSL Client Certificate Authentication
    - BASH o.ä.
    - openSSL
  - Windows Server 2012 RC2 bzw. Windows Server 2008 RC2
    - Domäne-Server (mind. Grundkonfiguration)
    - Active Directory - Domäne-Controller
    - [optioal] OCSP Rolle (Online Certificate Status Protocol)
  - Windows Client(s)
    - MS Windows 7+
    - Clients in AD-DC migriert bzw. migrierbar
    - Browser: iE 8+, FireFox, Chrome
  - PowerShell
  - VisualStudio mit C#, C++
  - Definierte Netzwerk-Umgebung

#### Systemvoraussetzungen

- mindest Hardwareanforderung
 - x64-Prozessor AMD-V mit NX-Bit oder Intel VT mit XD-Bit als DEP
 - 8 GB RAM
 - 2 GB freien Festplattenspeicher
 - integriertes 1-GBit/s Netzwerk
 - Internetverbindung

- optional bei realer/produktiver Umsetzung (Bsp. Debian Jessie)
 - empfiehlt es sich den "PKI"-Linux Server auf einer eigenständigen Hardware bzw. unabhängig vom Hyper-V mit Windows Servern und somit auf einem separaten Virtualisierungs-Server zu betreiben.
 - Nahezu alle x86-basierten (IA32) Prozessoren, 32-Bit AMD- und VIA- (früher Cyrix) Prozessoren sowie Prozessoren wie den Athlon XP und Intel P4 Xeon.
 - nicht auf 486- oder älteren Prozessoren oder Intel Quark
 - Intel Pentium und dessen Klone inklusive denen ohne eine FPU (Fließkommaeinheit oder mathematischem Coprozessor) werden unterstützt.
 - 80 MB / 128 MB / 512 MB RAM   ( Abs. Minimum / Minimum Betrieb / Empfohlen )
 - 680 MB / 2 GB / 10 GB freien Festplattenspeicher
 - integriertes 1-GBit/s Netzwerk
 - Internetverbindung

- mind. Softwareanforderung
 - Windows Server 2012 oder Windows Server 2008
 - Windows 10/8/7
 - Linux-Distro ( Debian / Ubuntu / Fodera / openSuSe o.ä. ) als Net-Install-ISO oder Standard-ISO's

#### Entwicklungsumgebung

- VisualStudio 2015/2017 Community
- Eclipse ( optional )
- VIM / Nano / gedit
- Brackets

#### Prüfprogramme

- [[ https://www.wireshark.org/ | WireShark ]] (( WireShark | https://www.wireshark.org/  ))
- [[http://www.tcpdump.org/tcpdump_man.html| tcpdump ]] (( tcpdump | http://www.tcpdump.org/tcpdump_man.html ))

#### Programmiersprachen

- C#
- PowerShell-Script
- Linux-Shell (sh/bash)
- PHP

#### Nützliche Tools

 - git Versionsverwaltung

## Soll-/Ist Vergleich Zeitplanung

^ Nr ^ Phase      ^ Kurz Beschr.      ^  Soll-Zeit          ^  Ist-Zeit  ^ Diff  ^
| 1 | Projektstart | Vorstellung des Projektes |  1 h  |  1 h  |
| 2 | Analyse & Definition | Soll-Ist Analyse |  2 h  |  2 h  |
| 3 | [[ projekt#Entwurf | Entwurf ]] | Ausarbeitung Scripte|  5 h  |  5 h  |
| 4 | [[ projekt#Implementation|  Implementation ]]  | Aufsetzen Server / Client Instanzen |  10 h  |  8 h  | - 2 |
| 5 | [[ projekt#Test_Validierung |  Test / Validierung ]]  | Testlauf Zertifikat Verteilung |  8 h  |  12 h  | +4 | 
| 6 | [[ projekt#Einsatz | Einsatz ]] | Roll-Out |  2 h  |  2 h  |
| 7 | [[ projekt#Abschluss | Abschluss ]] | Übergabe |  7 h  |  7 h  |
|  | ^   Summe ^  35 h  ^  37 h  |