SmartIT Zmorge: PKI + Zertifikate 27. April 2016 Herzlich Willkommen.

Transkript

1 SmartIT Zmorge: PKI + Zertifikate 27. April 2016 Herzlich Willkommen.

2 Agenda PKI + Zertifikate so geht s! Zeit Programm 08:45 10:00 Uhr Funktion, Nutzen und Komponenten von Zertifikaten und PKI Infrastruktur Uhr Pause Uhr Microsoft Active Directory Certificate Aufbau und Live Demo

3 PKI Da gibt s ein paar Dinge zu entdecken 1. Basics 2. Elemente 3. Setup 4. Demo 5. Empfehlungen Wichtig: in 3h lassen sich einige PKI Höhepunkte «durchnehmen», für «Alles» reicht s aber nicht. Hansruedi Brunner Consultant Tel unterstützt von: Michael Schäublin System Engineer Tel Review, Ideen Ergänzungen

4 Wozu überhaupt eine PKI Schutzziele der Informationssicherheit (CIA / VIV) Ausgangspunkt: - Schutzziele werden zum Erreichen bzw. Einhalten der Informationssicherheit und damit zum Schutz der Daten vor beabsichtigten Angriffen von IT-Systemen definiert: - Vertraulichkeit: Zugriff nur für berechtigte Personen - Integrität: Keine «unbemerkte» Veränderung von Daten, korrekte Inhalte - Verfügbarkeit: Zugriff auf Daten innerhalb nützlicher Frist - Authentizität: Daten können eindeutig einem Absender zugeordnet werden und sind echt - Verbindlichkeit: Der Absender kann die Transaktion nicht abstreiten Zertifikate, Zertifikate, Zertifikate - Um die aufgeführten Schutzziele IT-Technisch zu erreichen, sind Werkzeuge unter Nutzung von Zertifikaten in vielen Fällen das geeignete Instrument dazu: - Vertraulichkeit Verschlüsselung - Integrität, Authentizität, Verbindlichkeit Signatur

5 Wozu überhaupt eine PKI Wer verwendet eine PKI

6 Wozu überhaupt eine PKI Wer verwendet eine PKI Die Frage wie wo was betreffend PKI stellt sich beispielsweise in folgenden Situationen: - Wir wollen DirectAccess aufbauen und dabei auch Windows 7 Clients unterstützen - Wir werden eine flächendeckende WLAN Infrastruktur bereit stellen - Für jedes mobile Gerät wird es Remote Access geben - Wir wollen unsere PowerShell Scripts generell signiert haben - Wir werden eine neue Webseite mit sicherem Zugriff per aufschalten - Wir möchten für unsere neue Exchange Server Umgebung nicht mit Self-Signed Zertifikaten arbeiten - Wir wollen unsere s signiert versenden können - Wir wollen Two-Factor Authentication mit SmartCards einrichten

7 Was ist eine PKI Definition einer Public Key Infrastructure Akademisch: - Die Gesamtheit der Standards und Dienstleistungen, die zum Einsatz von Public Key- Kryptographie benötigt werden, bezeichnet man als Public Key Infrastruktur (PKI). - Insbesondere werden (vertrauenswürdige) Dritte (Zertifizierungsstelle = Certification Authority (CA)) benötigt, die nach bestimmten Regeln (Policy) Zertifikate herausgeben, erneuern und sperren. Quelle: KoopA ADV: Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselung in derverwaltung, V1.1, Seite: 40) - Aha, jetzt wissen wirs. :-) Volkstümlich: - Eine PKI stellt technische Werkzeuge zur Verfügung, um die genannten Schutzziele der Informationssicherheit erreichen zu können. - Eine PKI enthält «Zertifikatsfabriken», worin Zertifikate nach genau bestimmten Vorgaben herausgegeben, erneuert und gesperrt werden können. - Eine PKI stellt technische Mittel für asymmetrische Verschlüsselungen und Signaturen bereit. - Eine PKI «erzwingt» organisatorische Rahmenbedingungen, um der zu nutzenden Technik vertrauen zu können.

8 Basics: Symmetrische Asymmetrische Verschlüsselung Symmetrische Verschlüsselung Wer sich mit PKI beschäftigt, muss sich kurz die Basics zu symmetrischer, asymmetrischer und hybrider Verschlüsselung wieder ins Gedächtnis holen. Symmetrisch: Schnell, erprobt, «einfach», geeignet für grosse Datenmengen «Problem»: Austausch des geheimen Schlüssels zwischen den beiden Teilnehmenden Bob und Alice können den Schlüssel nicht «im Klartext über die Verbindung senden», er muss vorher verteilt sein ( z.b. Pre Shared Key )

9 Basics: Symmetrische Asymmetrische Verschlüsselung Asymmetrische Verschlüsselung: Ein hilfreicher Vergleich Lösung: Public: Verständliches Beispiel mit Vorhängeschloss Bob sendet Alice ein offenes Vorhängeschloss zu. Sie kann damit den vertraulich zu sendenden Inhalt in eine Schachtel legen und mit Bob s Schloss verriegeln. Nur Bob ist anschliessend in der Lage, mit seinem Schlüssel die Schachtel wieder zu öffnen. und Bob kann tausende offene Schlösser versenden, den einzigen passenden Schlüssel zum öffnen hat nur er.

10 Basics: Symmetrische Asymmetrische Verschlüsselung Public Key Private Key Asymmetrisch: Geeignet für kleine Datenmengen, «langsam», grösserer Aufwand Schloss Public Key von Bob muss er also für Verschlüsselung zuerst Alice zusenden!! Schlüssel Private Key von Bob wird er zur Decodierung der Message von Alice nutzen

11 Basics: Hybride Verschlüsselung So läuft s Hybrid Kombination der Vorteile Schlüsselaustausch Asymmetrisch ( zufällig generierter Session Key) Anschliessender vertraulicher Datentransfer Symmetrisch

12 Basics: Digitale Signatur So läuft s Ziele: - Integrität ( keine Veränderungen) i.o. - Absender zweifelsfrei identifiziert Wie läuft s: - Hash Value ( «Checksumme» ) zu Dokument berechnen - Hash mit Private Key Sender verschlüsseln - Dokument mit integriertem Hash sowie Zertifikat mit Public Key zu Empfänger - Empfänger kalkuliert selber Hash Value - Empfänger entschlüsselt mit Public Key des Senders den zugestellten Hash Value - Wenn selber berechneter und zugestellter Hash Value gleich OK!! - Wenn Zertifikat Sender OK, dann zweifelsfrei Absender identifiziert

13 Basics: Zertifikate Wozu überhaupt und was ist drin? Grundlage: - Wir wollen also Asymmetrische Verschlüsselung nutzen. Da kommt man kaum um Zertifikate herum. Zweck: - Digitale Zertifikate kommen bei der asymmetrischen Verschlüsselung zum Einsatz und bestätigen unter anderem, dass ein öffentlicher Schlüssel zu der Person gehört, die im Besitz des korrespondierenden privaten Schlüssels ist. Quelle:

14 Basics: Zertifikate Wozu überhaupt und was ist drin? Inhalte: - Information über User, Computer oder Device, welches den zum Zertifikat korrespondierenden Private Key hält. Genau dieser User, Computer oder das Device wird als Subject des Zertifikats bezeichnet. (Subject auf Deutsch: Antragsteller) - Information zur Issuing CA («herausgebende» CA) - Public Key des dem Zertifikat zugeordneten Schlüsselpaars - Verwendete Verschlüsselungs- und Signatur-Algorithmen - Eine Liste verschiedener X.509 Extensions (z.b. Verwendung) - Informationen zu Gültigkeits- und Sperrprüfung des Zertifikats - Hinweis: Der Private Key ist nur in speziellen Situationen mit dabei (z.b. während Setup oder Migration von Diensten).

15 Basics: Vergleich Zertifikat mit Fahrausweis Mein Fahrausweis ( ich habe tatsächlich so etwas ) Ein Fahrausweis dient dazu, die Fahrfähigkeit verlässlich einer bestimmten Person zuzuordnen: Zertifikat: Fahrausweis: - Subject - Name, Vorname (Felder 1. und 2.) - Valid from Valid to - Ausstelldatum (4.a), Ablaufdatum (4.b) - Authority Key Identifier + Issuer - Herausgeber (4.c) - Extended Key Usage - Kategorien (9.) - Thumbprint - Ausweisnummer (5.) - Signature - Sicherheitsmerkmale auf Ausweis - CRL Distribution Point - Webseite/Telefon zur Überprüfung, ob gesperrt

16 Demo: Inhalte Zertifikat Jetzt wollen wir s selber sehen: - Subject - Key Usage - Thumbprint - CDP - Valid from/to - Issuer - Certification Path zeigen auf LON-CL1:

17 Wozu eine EIGENE PKI Infrastruktur Warum Zertifikate nicht extern kaufen. Soll ich Zertifikate kaufen oder selber bauen??? - Wenn Nutzerkreis «unendlich» ist und nur wenige Zertifikate erforderlich sind z.b. für Verbindungen auf eigenen Firmenwebserver: Zertifikat extern kaufen von «anerkannter» Public CA (Verisign, GoDaddy etc.) - Wenn Nutzerkreis «endlich» und viele Zertifikate benötigt werden hauptsächlich für interne Nutzer z.b. Computer Zertifikate für VPN: Zertifikate mit eigener PKI Infrastruktur selber herstellen.ich hab es selber gebaut :-) gemischte Lösung kann sinnvoll sein! Interne CA als Sub-CA einer public PKI: «Fünfer und Weggli Lösung» leider teuer ( z.b. 5-stelliger Betrag / Jahr)

18 Zusammenfassung: Was muss eine PKI also leisten Die Aufgaben einer gesamten PKI Infrastruktur inkl. Personal und organisatorischen Belangen: Grundsätzlich: - Beantragen, Erzeugen, Ausstellen, Verteilen und Zurückziehen von Zertifikaten Umsetzung: - Persönliche Identifizierung der Antragssteller - Festlegung der Richtlinien / Vorlagen für ausgestellte Zertifikate - Dokumentation der Arbeitsschritte, Einhaltung von Arbeitsrichtlinien und Vorschriften - Geeignete Publikation von Zertifikaten (Public Keys) z.b. auf Webseite - Sperrung von Zertifikaten bei Kompromittierung oder Schlüsselverlust mittels Veröffentlichung von Sperrlisten (Certificates Revocation List, CRL) oder per Online Certificate Status Protocol (OCSP) - Benachrichtigung der Zertifikatnehmer (Ausstellung, Sperrung, Gültigkeit...) - Sicherheitsanforderungen an Hard- und Software erfüllen, sichere Datenhaltung garantieren - Backup und Archivierung von Verschlüsselungs-Zertifikaten (Private Key, Recovery Policy) - Einhaltung von regulatorischen Vorgaben

19 Zusammenfassung: Was muss eine PKI also leisten Die Aufgaben einer gesamten PKI Infrastruktur inkl. Personal: Fazit: - Eine PKI besteht nicht nur aus Technik! - Eine PKI muss in ein Sicherheitskonzept der gesamten Firma eingebettet sein - Rollen mit klar zugewiesenen Tätigkeiten und Berechtigungen angepasst auf Grösse und Sicherheitsanforderungen einer Firma, Stichwort «Role Separation» - Regulatorische Vorgaben, eigene Richtlinien und Arbeitsanweisungen - Schulung der Zertifikatsnutzer bezüglich Anwendung und Sicherheit

20 Elemente einer PKI (AD CS) Microsoft AD CS Die App muss mitmachen

21 Elemente einer PKI CAs Zertifizierungsstellen (CAs) sind Kernelement einer PKI: Die CA macht s: Zertifikatsverwaltung / Sperrung / Templates / Zertifikatsarchivierung Verteilung der Zertifikate manuell oder mittels Auto-Enrollment

22 Der einfachste Weg zur eigenen PKI Single Tier Online Enterprise Root CA Eine Single Tier PKI mit einer online Enterprise CA vereinigt alle Funktionalitäten in einem einzigen Server: Vorteile: - Einfaches und schnelles Setup mit voller AD Integration - AutoEnrollment von Zertifikaten auf Domain Clients und -User möglich - Geringer «Lizenzverbrauch» - Einfache Verwaltung, gute Übersicht, wenig Pflegeaufwand Warum nicht immer so? Da gibt s drum ein Problem:

23 CA Hierarchien: Gründe für eine CA Hierarchie Warum eine einzige CA nicht immer genügt. Mittels Vergleich zu Fahrausweis lässt sich das Problem veranschaulichen: - Der Polizist vertraut dem Fahrausweis, weil dieser von einem anerkannten Strassenverkehrsamt herausgegeben wurde, das auf dem Ausweis vermerkt ist. - Das anerkannte Strassenverkehrsamt hat sich aber nicht selbst bewilligt, sondern hat seine Betriebsbewilligung von der zuständigen Regierung, gewählt vom Volk. - Volk und Regierung haben keine übergeordnete Instanz, «bewilligen sich selbst», stehen zuoberst. Werden Volk und Regierung gekapert und überwältigt, hat dieser «Bösewicht» nun die Möglichkeit, eigene «schwarze» Strassenverkehrsämter zu eröffnen und diesen eine vermeintlich ordentliche Betriebsbewilligung zu erteilen. - Security dahin D.h. die oberste, sich selbst «bewilligende» Instanz ist der Ausgangs- und Ankerpunkt der gesamten Sicherheit der Fahrausweise. Ist sie «weg», ist die gesamte Sicherheit im Eimer D.h. diese oberste Instanz muss unter allen Umständen «kaperungssicher» gestaltet werden. Also: Regierung und Volk Isolieren, Einschliessen, Verbergen, Abhängen, Schützen!!

24 CA Hierarchien Sinn und Zweck mehrstufiger CA Hierarchien Forderung 1: Der «Ausgangspunkt» der PKI Security muss geschützt werden!! Oberste Instanz Isolieren, Einschliessen, Verbergen, Abhängen Forderung 2: Es müssen aber stets auch Zertifikate herausgegeben werden können: Teile der Infrastruktur müssen verfügbar sein und angesprochen werden können Online sein! Lösung: - Eine sich selbst bewilligende Root CA wird offline betrieben, ohne Netzwerkverbindung und Domänenmitgliedschaft Maximale Sicherheit - Die Zertifikats herausgebenden Subordinate CAs werden von dieser Offline CA «bewilligt», sind online in Betrieb und nutzen Active Directory Domänendienste Maximale Funktionalität CA Hierarchie

25 CA Hierarchien Sinn und Zweck offline Root CA Auf den Punkt gebracht Hauptziel offline Root CA: - Verhindern von Identitätsfälschungen: Private Key der Root CA lässt sich nicht entwenden Private Key lässt sich nicht missbrauchen, um gefälschte CAs und Zertifikate zu erstellen - D.h. maximaler Schutz des Root CA Private Keys ist gefordert!!

26 CA Hierarchien Two Tier Three Tier Three Tier CA Hierarchie: Two Tier CA Hierarchie: Bestehen sehr unterschiedliche Sicherheitsanforderungen z.b. pro Konzernbereich / Intern-Extern o.ä. lassen sich mittels Policy CAs entsprechend unterschiedliche Regeln gegen unten durchdrücken Online CAs Zertifikats Herausgabe Für KMUs ist dann eine Two Tier CA Hierarchie in den meisten Fällen ausreichend!

27 Nur eine einzelne online CA oder doch eine Hierarchie? Single Tier Online Enterprise Root CA äs chunnt drufaa Empfehlungen SmartIT: In einfacheren Anwendungsfällen bei geringer Anzahl Zertifikate z.b. für WLAN-Access-Points oder Client Zertifikate kann eine One-Tier-Hierarchie bestens genügen. Mögliche Kriterien: Nur intern zu nutzende Zertifikate / Bei «Sicherheitsleck» können alle verteilten Zertifikate kurzfristig und vollständig entfernt werden. CA lässt sich einfach löschen. Für «mittleres» Sicherheitsniveau (KMU Anforderungen, max. FIPS Level 2) zweistufige CA Hierarchie aufbauen mit virtualisierter offline Root CA Mögliche Kriterien: PKI Nutzung muss längerfristig «offene Perspektiven» bieten / Breitere Nutzung auch ausserhalb eigenem Netz / Branche mit höheren Sicherheitsanforderungen /.im Zweifel auf Nummer Sicher gehen / MS Technet Best Practices Empfehlungen umsetzen Zwei oder Three Tier Hierarchie mit physischer offline Root CA und HSM (Hardware Storage Module) etc. nur bei besonders hohen Sicherheitsanforderungen oder regulatorischen Vorgaben Wir beraten Sie gerne :-)

28 Two Tier Verständnis CDP / AIA Zugriff auf die Infos der «ausgeschalteten» Root CA CDP / AIA «Gewisse» Dinge der offline geschalteten CA müssen trotzdem zugreifbar sein: - Sperrliste (CRL) und Delta Sperrliste (CRL+) - CA Zertifikat «Root Zertifikat» Definition von Publikationspunkten: Enterprise Subordinate CA «Issuing CA» - CDP: CRL Distribution Point (Sperrliste) - AIA: Authority Information Access (Root Zert.) Publikation beispielsweise auf WebServer ( und AD DS (LDAP) und dann gleich für alle CAs In jedem von der Enterprise CA herausgegebenen Zertifikat sind diese Publikationspunkte enthalten. und manuelle Speicherung Root CA Zertifikat und SubCA Zertifikat Nutzung für Zertifikatsüberprüfung

29 Einlagerung CDP Info in Zertifikate Passende Konfiguration der Issuing CA Config wo: File lokal auf CA AD DS ldap:// CA: Neu generierte Sperrlisten hier speichern CA: Diesen Ort in jede CRL einbauen, um Delta CRL Location anzugeben CA: Diesen Ort in jedes Zertifikat als CDP einbauen. File auf WebSrv zeigen auf Sub-CA

30 Zertifikatsprüfung häufige Fehlerquelle wenn s klemmt! Vergleich mit Fahrausweiskontrolle: - Ist der Ausweis echt und nicht manipuliert? - Stimmt Fahrer mit Foto auf Ausweis überein? - Darf der Fahrer diese Kategorie Auto fahren? - Ist der Ausweis nicht abgelaufen? - Ist der Ausweis gesperrt? ( Abfrage DB)

31 Zertifikatsprüfung häufige Fehlerquelle wenn s klemmt! Was wird überprüft: - Format: X.509 konformes Format vorhanden - Content: Alle X.509 «Muss-Felder» müssen einen Inhalt haben - Critical Extensions: Alle X.509 Version 3 Certificate-Extensions, die als kritisch markiert sind, müssen von der nutzenden Applikation «verstanden» werden. - Application Policy: Die von der Applikation verlangten OIDs (d.h. die gewünschten «Verwendungszwecke»), müssen im Zertifikat enthalten sein. - Revocation Check: Das Zertifikat darf nicht in der Sperrliste (CRL) der herausgebenden CA enthalten sein. - Root Check: Die Prüfung der «Certificate Chain» muss für alle intermediate CAs gültige Zertifikate liefern und in einer gültigen, trusted Root CA enden. - Signature Check: Das Zertifikat darf keine Veränderungen aufweisen - Time Validity: Das aktuelle Nutzungsdatum muss innerhalb der Gültigkeitsdauer des Zertifikats liegen

32 Zertifikatsprüfung Vergleich Certificate Chain häufige Fehlerquelle wenn s klemmt! Vergleich mit Fahrausweiskontrolle: - Kommt der Ausweis von einer bekannten Ausgabestelle? - Ist die Ausgabestelle «in Betrieb» und OK? - Sind alle übergeordneten Instanzen bekannt? - Sind alle übergeordneten Instanzen bis zur obersten Behörde operationell und OK?

33 Zertifikatsprüfung - Chain Certificate Chain Zweck Certificate Chains: - Jeder beteiligte «Herausgeber» (d.h. jede beteiligte CA) wird geprüft. Alle müssen OK sein!! - Stoppt erst, wenn «self signed Root Zertifikat» erreicht ist. (d.h. wenn Issuer = Subject) Dieses Root Zertifikat muss trusted sein, d.h. ein bekannter Herausgeber sein Zusammenstellung Chain: - Im zu nutzenden Zertifikat wird AKI Extension gelesen. (subject, issuer serial number, KeyID). - Passendes übergeordnetes CA Zertifikat mit Übereinstimmung dieser Felder wird verwendet. ( Exact Match) Zu nutzendes Zertifikat: Übergeordnetes CA Zert. AKI Extension Serial Nr. + Subject

34 Test Sperrlistenpublikationspunkt CDP Troubleshooting, wenn s bei Zertifikatsprüfung klemmt. Schritt1: Wo sind CDPs Schritt2: certutil -URL Test: AIA CDP CDPs URL von Sperrliste ( oder AIA, je nach Test) zeigen auf LON-CL1

35 Pause Let s Talk about PKI :-)

36 Setup CA Hierarchie Wir bauen eine CA Hierarchie: High Level Steps - Vorbereitende Arbeiten: Server Installation Root-CA und Subordinate-CA, DNS etc. - Offline Root-CA einrichten - Root CA Zertifikat und Root-CA Sperrliste «exportieren» und auf CDP/AIA Lokation kopieren - Online Issuing Subordinate CA einrichten - «Betriebsbewilligung» für Issuing Sub-CA für von Root-CA einholen Sub-CA Zertifikatsanfrage manuell auf Root-CA transportieren Sub-CA Zertifikat von Root-CA signieren lassen Sub-CA Zertifikat manuell auf Sub-CA bringen, importieren und Sub-CA damit «laufen lassen» - Zertifikatsvorlagen passend konfigurieren - Einzelne Zertifikate je nach Bedarf erstellen und verteilen - Auto-Enrollment einrichten und Zertifikate verteilen lassen

37 Setup two Tier PKI Hierarchie Vorbereitende Arbeiten Was ist vorbereitend zu erledigen: - Root CA Isolierter Server, keine Netzwerkverbindungen, keine Domäne, lizenziert Datentransport für Certificate Requests z.b. per virtual Floppy bereitstellen - Issuing Sub CA Domain Member, Online in internem Netz - DNS In Zertifikaten sind konkrete Servernamen aus Sicherheitsgründen zu vermeiden, d.h. DNS Aliase für PKI Komponenten definieren: ca.firma.ch, crl.firma.ch - DNS Split DNS oder «Pinpoint» Einträge erstellen Extern und Intern müssen dieselben URLs auf passende Ressourcen zeigen - capolicy.inf Installation mittels Config-Files und Scripts, damit vorgängige Tests möglich sind und Nachvollziehbarkeit gewährleistet bleibt - Dokumentation Organisatorische Rahmenbedingungen, regulatorische Vorgaben, Namenswahl, Setup Vorgang, CA Test und Abnahme sowie Betrieb und personelle Rollen dokumentieren. Umfang dabei passend zum erforderlichen Sicherheitslevel festlegen.

38 Setup two tier PKI hierarchy: Root CA Installation offline Root CA Kombination aus Powershell- und cmd Befehlen ( funktioniert in Praxis am Besten) SHA256!! Root: 20 Jahre... CDP AIA 1 * pro Jahr neue Root CA CRL Root CA Infos in AD publizieren

39 Setup two tier PKI hierarchy: Root CA capolicy.inf ( in C:\Windows ablegen vor Installation) Bei IANA zu lösende eindeutige OID (Organizational ID der eigenen Firma ( hier firma.biz) URL mit rechtlichen Hinweisen zur PKI Nutzung URL mit Hinweisen zum Umgang mit Zertifikaten Begrenzung: CA Hierarchie max. 2 stufig (Two Tier) Root CA gibt keine Delta CRLs ( CRL+) heraus Nach Setup sind noch keine Zertifikatsvorlagen bereit zur Nutzung, diese müssen anschliessend «von Hand» freigegeben werden

40 Setup two tier PKI hierarchy: Publikationspunkte AIA und CDP Webserver für Sperrlisten- und CA Zertifikatspublikation vorbereiten: Grundinstallation: - Damit Root Zertifikat und CRLs über http von CDP bzw. AIA abgerufen werden können, wird der Serverdienst IIS mindestens auf einem Rechner installiert: Webseite crl.firma.com: - Mittels IIS Manager muss nun eine neue Webseite angelegt werden, welche über die URL crl.firma.com erreichbar ist. Auf diese URL Verweisen CDP und AIA aller auszugebenen Zertifikate Double Escaping einschalten: - Weil die Delta-Sperrliste in ihrem Dateinamen ein + Zeichen enthält, muss für diese Webseite allowdoubleescaping eingeschaltet werden. Dies lässt sich per Feature Settings einrichten:

41 Vorbereitung Issuing CA (Enterprise Online Subordinate) CA Hierarchie ermöglichen Trust zu Root CA - Das Zertifikat der Root CA muss vor der Installation der Sub-CA Rolle auf dem entsprechenden Server in «Trusted Root Certification Authorities» vorhanden sein: Entweder: In AD DS publishen mittels und damit per Group Policy verteilen lassen u.a. also auch auf die Sub-CA Und / oder: sofort lokal auf der Sub-CA Sperrliste und Root Zertifikat zum «OnLine Zugriff» bereitstellen: - Sperrliste und Zertifikat der offline Root CA müssen stets erreichbar sein: Firma-Root-CA.crt und Firma-Root-CA.crl ins Verzeichnis eines Webservers kopieren, welches unter intern wie extern erreichbar ist.

42 Installation Sub-CA Installation Online Enterprise Sub-CA Auf Root CA!! Gültigkeitsdauer Sub-CA Zertifikat auf 10 Jahre setzen: 10 Jahre Vorgehen Sub-CA Setup analog zur Root CA: Enterprise Subordinate SHA256!! analog auch auf Sub-CA CDP / AIA setzen: CDP AIA

43 Installation Sub-CA Certificate Request zu Root CA transportieren Der PowerShell Befehl: löst eine Zertifikatsanfrage (*.req Datei) zur Root CA aus. diese Anfrage zur «Betriebsbewilligung» (*.req) wird per Floppy A:\ zur Root CA transportiert mittels certreq submit wird die Anfrage der Root-CA eingespielt und dort vom Certificate Manager manuell bestätigt ( «issued» )

44 Demo: Offline CA Was gibt s da alles zu sehen - Issued Certificates - General KSP / SHA256 - Properties Extensions CDP/AIA - Properties Policy Module Properties - Properties Exit Module Properties - Auditing - Certificate Managers ( Role Separation) - Revoked Certificates All Tasks Publish - Hyper-V Manager VM Settings Network Adapter

45 Demo: Sub-CA Was es da so alles gibt - Issued Certificates - General KSP / SHA256 - Properties Extensions CDP/AIA - Certificate Managers ( Role Separation) - Enrollment Agents ( z.b. Personalbüro) - Recovery Agents - Auditing - Revoked Certificates All Tasks Publish

46 Demo Enterprise PKI Funktionalität überprüfen mit Enterprise PKI und IE Kontrolle Zertifikate und Sperrlisten per CDP/AIA: Kontrolle AD Container:

47 Konfiguration und Betrieb CA Certificate Templates - Certificate Template: Vorlage, welche den Inhalt eines Zertifikates vorgibt - Templates für User- und Computer Zertifikate - AD CS speichert die Templates in der Configuration Partition von AD DS Allen Enterprise CAs eines AD Forests stehen dieselben Templates zur Verfügung - Versionen: V1: nicht modifizierbar, V2: anpassbar V3: anpassbar + CNG, OCSP V4: anpassbar + CNG, OSCP, Renew with same Key

48 Konfiguration und Betrieb CA Certificate Templates Security Tab: Berechtigungen, wer Zertifikat «lösen» kann. Abbildung: Einstellungen für Auto-Enrollment von Computer Zertifikaten Request Handling Tab: Wie wird Zertifikat erstellt. Exportierbarkeit Private Key (Pfeil), Zweck (Purpose), Archivierung, Key Erneuerung, Cryptography Tab: Was wird im Zertifikat eingestellt: Verschlüsselungsalgorithmus, Key Länge, Cryptographic Provider

49 Konfiguration und Betrieb CA Certificate Templates Subject Name: Für wen wird das Zertifikat ausgestellt. Abbildung: SSL Zertifikat per Auto Enrollment Extensions Tab: Wozu wird Zertifikat verwendet. Application Policies (OIDs), weitere Einschränkungen unter Key Usage Wenn fertig, dann «Issue»

50 Demo Certificate Templates - Neues Template erstellen per Kopie - Subject Name - Berechtigungen passend setzen: Zeigen SmartIT-WebServerSSL LON-SVR2$ - Issuance Requirements - Compatibility Tab 2008 R2 oder höher Hinweis: Wenn keine CNG (Cryptographic Next Generation) Algorithmen, dann 2003/XP wählen - Superseeded Templates

51 Tipps und Tricks Certificate AutoEnrollment Voraussetzung: Gruppenrichtlinie AutoEnrollment grundsätzlich einschalten

52 Tipps und Tricks Certificate AutoEnrollment GPO für AutoEnrollment in AD DS passend platzieren z.b auf Domain Level: und wie bereits gezeigt die Berechtigungen auf dem «zuständigen» Template passend setzen: Read Enroll Autoenroll

53 Demo Certificate AutoEnrollment - GPO Konfig AutoEnrollment-UserCertificates - Template Konfiguration Security - Löschen bestehendes EFS Zertifikat auf Client - Re-Enroll

54 Key Archival Zweck - Privater Schlüssel wird zusätzlich in Active Directory archiviert - Ein spezieller als Key Recovery Agent (KRA) konfigurierter Account kann dann bei Bedarf einen archivierten Private Key wieder herstellen - Sinnvoll bei persönlichen Zertifikaten wie z.b. Encrypting File System (EFS) Einschalten auf Certificate Template Ab Einschaltung wird der private Key aller Zertifikate archiviert, welche über dieses Template erzeugt wurden

55 Demo Key Archival einrichten Archived Key - CA Konfiguration Key Recovery Agent (KRA) inkl. Zertifikat - Template Konfiguration Key Recovery enabled - Template Konfiguration Security Auto Enrollment EFS User Zertifikat

56 Tipps und Tricks: SHA Was ist SHA: Secure Hash Algorithm Signatur von Zertifikaten und Meldungen - Aktuelles Problem: Default Installation AD CS nutzt SHA-1 Gilt unterdessen als «Knackbar» - Wie Upgraden: Kontrolle, welcher Cryptographic Service Provider auf der CA installiert ist. o Wenn CSP: Falls noch der mit Windows 2000/2003 eingeführte CSP aktiv ist: Wechsel der Krypto-Engine auf den ab Windows 2008 verfügbaren KSP Hinweis: In diesem Fall ist ein paralleler Aufbau einer neuen PKI Infrastruktur ernsthaft in Erwägung zu ziehen. o Wenn KSP: «Nur» Wechseln des Hash Algorithmus von SHA-1 auf SHA Anwendungen: Migrations-Bedingung generell: Alle zertifikatsnutzenden Anwendungen müssen SHA256 unterstützen!!

57 Tipps und Tricks: CSP oder KSP?? Was ist für die Migration von SHA1 auf SHA256 zu tun. Ausführen von certutil -store my ContosoSub-CA ( Beispiel CA) Cryptographic Provider ist auf dieser Beispiel CA von Contoso noch CSP Also braucht s eine komplette Migration zu KSP (Microsoft Key Storage Provider) dann ist evtl. der parallele Aufbau einer neuen PKI Hierarchie einfacher Wenn CA bereits KSP nutzt, dann «ganz einfach» der Hash Algorithmus auf SHA256 umschalten Wir beraten Sie gerne :-)

58 Tipps und Tricks Do s and don ts Quelle:

59 Merci! Fragen? und das nächste SmartIT Zmorge kommt bestimmt :-)