All posts in PKI

 

 

 

 

 

Hallo zusammen,

um einen nginx Webserver installieren zu können, benötigt es ein paar Vorbereitungen.
In diesen Beispiel verwende wir einen Ubuntu 16.04 LTS Server in einer Virtuellen Umgebung.

Nach der Grundinstallation des Servers, muss der Server auf den neusten Stand gebracht werden.
Nach dem Login, wechselt man zum root Benutzer mit:

Nach dem das System up to date ist, konfiguriert man den Server mit einer statischen IP-Adresse.

nginx Webserver installation und überprüfen

Standardverzeichnisse nach der Installation

Grundlegende nginx Befehle

Mit folgenden Befehl überprüft man, ob der nginx Server auf Port 80 lauscht

PID File Anpassung in der nginx.service Datei

Erste Webseite konfigurieren

 

 

 

 

 

Virtuellen Host konfigurieren

 

 

 

 

 

Webserver SSL Zertifikat erstellen

mysite.htdom.local Konfiguration anpassen

Mit folgenden Befehl überprüft man, ob der nginx Server auf Port 80 und 443 lauscht

 

 

 

 

 

 

Um noch mehr Sicherheit in die TLS Verbindung zu bekommen, sollte man das TLS Protokoll und den Schlüsselaustausch (Chiper) eingrenzen.
Dazu gibt es eine sehr gute Webseite von Mozilla, mit dieser Mozilla SSL Configuration Generator kann man sich die passende Konfiguration für seinen Webserver zusammenklicken.

https://mozilla.github.io/server-side-tls/ssl-config-generator/

Modern: Ist Stand heute die sicherste Einstellung, hier wird nur noch TLSv1.2 verwendet
Intermediate: Ist ein kompromiss aus Sicherheit und Kompatibilität, hier wird noch TLSv1 TLSv1.1 TLSv1.2 verwendet.
Old: Ist die schlechterste Wahl, hier wird sogar noch das veraltete SSLv3 verwendet.

Alle heutigen Browser unterstützen bereits TLSv1.2 daher sollte man, wenn möglich Intermediate oder Modern benutzen.
Um die Konfiguration auf der Webseite vornehmen zu können, müssen wir erst die nginx und openssl Version herausfinden, dies funktioniert mit folgenden Befehl.

Und so sieht meine Modern Konfiguration aus

SSL/TLS Verbindungstest kann man auf folgender Webseite durchführen
https://www.ssllabs.com/ssltest/index.html

Wenn man nun die Variante Modern nutzt, könnte die Handshake Simulation wie folgt aussehen.
Alle Browser die kein TLSv1.2 unterstützen, werden abgewiesen, bzw. können keine Verbindung zum Webserver aufbauen.

 

 

 

 

 

 

 

Viel Spaß beim ausprobieren

Gruß Helmut

 

 

 

 

 

In diesen Beitrag möchte ich kurz zeigen, wie man sich für eine Testumgebung oder vielleicht einen späteren Live Betrieb eine zweistufige PKI mit OpenSSL einrichtet.
Hierzu wurde ein Standard Ubuntu 16.04 LTS Server installiert.

Das wichtigste für eine CA ist die OpenSSL-Konfigurationsdatei, diese liegt Standardmäßig jeder openssl Installation bei, diese Datei wurde kopiert und auf die Testumgebung angepasst.
Wenn Ihr andere Installationspfade nutzen wollt, dann bitte dementsprechend die ca-config.cnf Datei nach euren Bedürfnisse anpassen.

Was sehr wichtig ist, sind die Sektionen. Die URLs müssen unbedingt für die Testumgebung angepasst werden. Damit im Zertifikat später die richtigen URLs stehen.
Die Certification Revocation List (*.crl) muss über http:// erreichbar sein, wenn das nicht der Fall ist, kann es zu unnötigen Fehlern kommen.

ca-config.cnf

Root Certificate Authority einrichten

Issuing Certificate Authority einrichten

Issuing Certificate Request genemigen

Webserver Zertifikat erstellen

Certification Revocation List erstellen

Zertifikate wiederrufen

Nützliche Befehle

Da kein Computer dieser Welt unsere CA kennt, müssen wir natürlich das Root CA Zertifikat und Issuing CA Zertifikat auf jeden Computer installieren.
Dazu lege ich mir eine RootCA.txt und eine IssuingCA.txt Datei lokal auf dem Computer an und hole mir wie oben beschrieben die Zertifikatsinformationen.

Wenn beide Text Dateien gefüllt sind, werden dies in *.crt umbenannt, danach installiere ich diese unter Windows in den passenden Zertifikatsspeicher.
Das RootCA Zertifikat wird in den „Vertrauenswürdige Stammzertifizierungsstelle“ installiert.

 

 

 

 

 

Und das Issuing CA Zertifikat wird unter „Zwischenzertifizierungsstelle“ installiert.

 

 

 

 

 

Wenn beide Zertifikate sauber installiert wurde, kann man sich das Zertifikat ansehen, in dem das man es doppelklickt und sich alle Informationen ansieht.

 

 

 

 

 

Unter Linux ist das ganze ein bisschen einfacher, hierzu kopiert man beide Zertifikate in den Zertifikatsspeicher und lässt ein Update laufen, danach sind dem Linux Server/Client die Zertifikate bekannt.

So nun viel Spaß beim ausprobieren.

Viele Grüße
Helmut

Hier in diesen Howto möchte ich euch zeigen, wie man die Zertifikatssperrliste(n) im Active Directory veröffentlicht. Das ganze wurde wieder in einer Virtuellen Umgebung mit Oracle – VirtualBox nachgestellt.

Die erste Frage die sich stellt, was ist eigentliche eine Zertifikatssperrliste?

  • Eine Zertifikatsperrliste (certificate revocation list, CRL) ist eine Liste, die die Ungültigkeit von Zertifikaten beschreibt. Sie ermöglicht es, festzustellen, ob ein Zertifikat gesperrt oder widerrufen wurde und warum.
  • Zertifikate werden gesperrt oder widerrufen, wenn deren zugehöriger Schlüssel z. B. nicht mehr sicher ist, weil sie in die falsche Hände geraten sind oder kompromittiert wurden – in solchen Fällen muss das Zertifikat noch vor dem eigentlichen Ablaufdatum gesperrt werden.

Hier geht es wieder zum Howto – Zertifikatssperrliste im Active Directory veröffentlichen

Viel Spaß damit

Gruß Helmut Thurnhofer

Hallo zusammen,

das wichtigste zuerst, wenn man sich nun intensiver mit PowerShell beschäftigen möchte, muss man seine Umgebung anpassen, um lokal Skripte ausführen zu können/dürfen.

Dazu dient das cmdlet „Set-ExecutionPolicy

Es gibt 5 verschieden Policy Einstellungen

Restricted = Die Powershell führt keine Skripte aus. Das ist der Defaulwert für die Powershell.
AllSigned = Die Powershell startet nur Skripte, die eine digitale Signatur haben.
RemoteSigned = Die Powershell wird keine Skripte ausführen, die aus dem Internet stammen – außer sie haben eine digitale Signatur.
Unrestricted = Die Powershell ignoriert die digitalen  Signatur, fragt aber nach, ob ein Skript, das aus dem Internet stammt, ausgeführt werden soll.
Bypass = Alle Skripte werden ohne Nachfrage ausgeführt (Sehr unsicher)

Undefined = Setzt den Defaultwert auf Restricted, sobald Gruppenrichtlinien im Einsatz sind, hat dieser Schalter keine Auswirkung.

Wenn man nun lokal Skripte ausführen möchte, setzt man dementsprechend seine ExecutionPolicy

Sobald man aber in einen Firmenumfeld Powershell Skripte einsetzen möchte, sollte man seine fertigen Skripte mit einem Zertifikat signieren. Ob das Sinnvoll ist oder nicht, muss natürlich jeder für sich selbst entscheiden. Es gibt natürlich auch hier Mittel und Wege das ganze auszuhebeln, aber für unerfahrene Mitstreiter eine kleine Lebensaufgabe.

Hier die Vorbereitung um Firmenweit seine Powershellskripte zu signieren:
Als erstes erstelle ich eine neue Gruppenrichtlinien für die Domain, diese Gruppenrichtlinie verknüpfe ich mit der Domain.

Computerkonfiguration –> Richtlinien –> Administrative Vorlagen –> Windows-Komponenten –> Windows Powershell –> Skriptausführung aktivieren (Nur signierte Skripte zulassen)

GPO

 

 

 

 

 

GPO_Shortcut

 

 

 

 

 

Wenn man nun mit gpupdate /force die Gruppenrichtlinien aktualisiert, bekommt man beim Öffnen von PowerShell eine Fehlermeldung. (Bei mir war bereits eine PowerShell Profildatei hinterlegt)

PowershellError

 

 

 

 

 

Danach erstelle ich mir in Active Directory eine neue Rollengruppe und füge alle Mitglieder hinzu, die PowerShellSkripte signieren dürfen.

Rollengruppe

 

 

 

 

 

Jetzt öffne ich meine AD Zertifizierungsstelle und lege eine neue Zertifikatsvorlage an. Diese Zertifikatsvorlage Veröffentliche ich im Anschluss.

Zertifikatsvorlage1

 

 

 

 

 

Zertifikatsvorlage2

 

 

 

 

 

Zertifikatsvorlage3

 

 

 

 

 

Alle Benutzer die berechtigt sind, Skripte zu signieren. Öffnen nun eine neue MMC Konsole und fügen sich das SnapIn Zertifikate/Eigenes Benutzerkonto hinzu.

Unter Eigene Zertifikate –> Zertifikate –> Neu Aufgaben –> Neues Zertifikat anfordern, fordern nun die Benutzer ein Codesigning Zertifikat an.

Zertifikat_anfordern1

 

 

 

 

 

Zertifikat_anfordern2

 

 

 

 

 

Und mit folgenden beiden Befehlen kann man seine Skripte signieren

Script_Signieren

 

 

 

 

 

Powershell_ohne_Error

 

 

 

 

 

Sobald die Gruppenrichtlinie AllSigned gesetzt wurde, kann man diese nicht mehr !vorübergehen! außer Kraft setzen.

keine_aenderung_moeglich

 

 

 

 

 

Viel Spaß und bis die Tage
Helmut

Hier in diesen Howto möchte ich euch zeigen, wie man die Active Directory-Zertifikatdienste Installiert und grundlegend konfiguriert. Das ganze wurde in einer Virtuellen Umgebung mit Oracle – VirtualBox nachgestellt. Diese Zertifikatstelle benötige ich für Exchange 2010 und Sharepoint 2010.

image

In den Serverrollen aktiviere ich die Active Directory-Zertifikatdienste und klicke auf Weiter

image

Aktiviere die Zertifizierungsstelle und die Zertifizierungsstelle-Webregistrierung, danach poppt der Rollen Assistent hoch dass noch der IIS zusätzlich Installiert werden muss.

image

Hier findet Ihr wieder das Howto zum folgenden Beitrag –>  Active-Directory-Zertifikatdienste (PKI) Installieren & konfigurieren

 

Viele Grüße
Helmut

Quellen:
Rachfahl IT Solution –> Link
Windows Server 2008 R2 Buch von Ulrich B. Boddenberg –> Link