Schlagwort-Archive: Zertifikate

Installation einer Offline Root CA

Aufgrund eines Fehlers und wahrscheinlich, weil ich nicht aufgepasst habe, habe ich bei der Migration von ESXi auf Hyper-V eine VM gelöscht, auf der meine Offline CA gespeichert war. Natürlich hatte ich ausgerechnet von diesem Zertifikat keine Datensicherung des privaten Schlüssels. Da in der Root CA auch noch ein Designfehler vorhanden war bzgl. der CRL, habe ich mich dazu entschieden, ein neues Root Zertifikat zu erstellen und die vorhandenen Designfehler zu korrigieren.

Da sieht man mal wieder, wie wichtig eine vernünftige Planung, auch in einer Testumgebung ist und das man natürlich die Datensicherung, gerade von kritischen Geräten nicht vergessen sollte 😉

Die Grundkonfiguration lässt sich mit folgenden Schritten schnell erledigen:

  1. 1. Standard-Installation von Windows Server 2008 R2 Enterprise Edition (Aktivierung auch gleich erledigen)
  2. Primären DNS-Suffix eintragen
  3. Unter C: ein Verzeichnis ADCS mit zwei Unterverzeichnissen „Database“ und „Logs“ anlegen
  4. Serverrolle Active Directory Zertifikatsdienste (Active Directory Certificate Services) installieren
  5. Bei Rollendiesten „Zertifizierungsstelle“ auswählen
  6. Installationstyp „Eigenständig
  7. Zertifizierungsstellentyp „Stammzertifizierungsstelle
  8. Privater Schlüssel „Neuen privaten Schlüssel erstellen
  9. Kryptografiediensteanbieter: „RSA#Microsoft Key Storage Provider
    1. Schlüsselzeichenlänge „4096“ (meine Empfehlung)
    2. Hashalgorithmus „SHA1
  10. Allgemeiner Name dieser Zertifizierungsstelle „F1NaLByte Root Authority“ (denkt euch euren eigenen aus 😉 )
  11. Gültigkeitsdauer, da es sich um eine Offline Root CA handelt, kann diese zwischen 20 und 30 Jahren liegen. Wenn dieses Zertifikat kompromitiert werden sollte, verliert es ohnehin seine Gültigkeit.
  12. Zertifikatdatenbank, auswählen des im Vorfeld angelegenten Database-Verzeichnis für die Datenbank und Logs-Verzeichnis für die Logs.

Restliche Abfragen mit Standardwerten bestätigen. Daraufhin ist die Rolle installiert.

Konfiguration Sperrlistenverteilungspunkt

Nun müssen die Sperrlisteninformationen angepasst werden, dass ist wichtig! Hier sind zunächst alle Einträge mit „ldap“ und „file“ zu löschen, siehe Bild.

Das ganze sollte, nach geänderter Konfiguration, folgendermaßen aussehen:

Eintragen einer verfügbaren URL

Konfiguration Stelleninformationen

Zuletzt sollte ebenfalls der Zugriff auf die Stelleninformationen angepasst werden.

Konfiguration des Zugriffs auf die Stelleninformationen

Veröffentlichung der Sperrliste

Nächster Schritt ist die Konfiguration für das Veröffentlichungsintervall der Sperrliste. Da ich mit dieser Root CA nur meine Sub CA autorisiere, kann das Intervall ziemlich hoch eingestellt werden. Dies sollte aber im Einzelfall betrachtet werden. Bei Ausstellung von mehrere SubCA, sollte man das Intervall entsprechend der Anforderungen anpassen. In meinem Fall habe ich mich für 2 Jahre entschieden.

 

Konfiguration der Zertifikatssperrliste
Zertifikatssperrliste Konfiguration

Nun muss noch die Zertifikatssperrliste veröffentlicht werden: Veröffentlichung der Zertifikatssperrliste

Ist der „File-Pfad“ nicht verändert worden, so befindet sich die veröffentlichte Sperrliste nun an folgendem Ort: „C:WindowsSystem32CertSrvCertEnroll

Speicherort der Sperrliste

Diese beiden Dateien können nun mit dem Root- Zertifikat exportiert werden. Die beiden Dateien müssen unter der konfigurierten URL auf dem Webserver zur Verfügung gestellt werden.

Damit ist die Konfiguration der Offline Root CA abgeschlossen und alle notwendigen Dateien stehen zur Verfügung. Der nächste Schritt wäre die Erstellung einer untergeordneten Online CA (SubCA) die, beispielsweise, im Active-Directory veröffentlicht ist.

IIS 7 / 7.5 Hosting mehrere SSL-Seiten auf einer IP

Mit dem Webservern kann man auf Port 80 mehrere Domänen auf einer IP-Adresse, anhand des Hostnamen, hosten. Dies ist allerdings bei HTTPS-Verbindungen schwierig, da der Hostname ja durch das Zertifikat bereits ausgestellt wird und mehrere Hostnamen nicht zusammen mit einem Port und einer IP laufen können.
Es gibt allerdings einen Weg, wie man mehrere SSL-Verbindungen mit einem Webserver und einer IP realisieren kann.

Vorraussetzungen:

  • Ein Wildcard-Zertifikat (*.domain.de)
  • IP-Adresse für das Hosting mehrere Webseiten
  • Min. 2 Webseiten auf Port 80 mit Hostnamen (SSL-Hostname wird nachgetragen)

Um das ganze nun zu realisieren:

  • Eine Commando-Zeile mit administrativen Rechten aufrufen
  • Ins Verzeichnis C:WindowsSystem32inetsrv wechseln
  • Folgendes Kommando eingeben (ersetzen von {Sitename}, {IP} und {Hostheader} mit den gewünschten Werten)
    • appcmd set site /site.name:{SITENAME} /+bindings [protocol='https',bindingInformation='{IP}:443:{HOSTHEADER}']
    • appcmd set site /site.name:IIS Seitenname /+bindings.[protocol=’https‘,bindingInformation=’*:80:www.domain.de‘]
  • Zertifikat im IIS Manager prüfen, kann geändert werden, allerdings kann der Hostheader nicht angepasst werden

Mit diesem wenigen Handgriffen könnt ihr nun mehrere Webseiten, über HTTPS, auf einem Webserver zugänglich machen.

Um eine bestehende SSL-Verbindung zu ändern:

  • appcmd set site /site.name:{SITENAME} /bindings.[protocol='https',bindingInformation='{IP}:443:{HOSTHEADER}'].bindingInformation:{NEWIP}:443:{NEWHOSTHEADER}
  • appcmd set site /site.name:“Default Web Site“ /bindings.[protocol=’https‘,bindingInformation=’10.0.1.100:443:web1.f1nalbyte.de‘].bindingInformation:*:443:web1.f1nalbyte.de

siehe auch: http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html oder http://toastergremlin.com/?p=308

Sharepoint 2010 Installation

Vor einigen Tagen wurde die Installation des Sharepoint Servers 2010 in einer dreistüfigen Farm vorgenommen. Dabei verlief die Installation nach der Dokumentation auf technet ab und war relativ unspektakulär. Viel wichtiger ist die Vorbereitung der benötigten Dienstkonten und die Anpassung der Rechte z.B. für den Sharepoint Farmadministrator auf dem SQL-Server.
Für den großteil der Dienste wurden einige Dienstkonten im AD angelegt. Diese wurden im Sharepoint eingetragen und dort wurde auch gleich Gebrauch von der neuen Funktion „Managed Accounts“ gemacht. Hierrüber lassen sich die Dienstkonten für den Sharepoint-Server zentral verwalten und zudem wird automatisch ein Passwortwechsel, basierend auf den Kennwortrichtlinien, vorgenommen.
Auf eine bebilderte Anleitung verzichte ich an dieser Stelle, da es hier zu schon genügend gibt und ich, wie bereits oben erwähnt, rein nach der TechNet Doku vorgegangen bin.

Ein nettes Feature ist auf jeden Fall die Statusanzeige der Sharepoint-Farm auf der Seite der Zentraladministration. Nach Abschluss der Installation wurden hier noch einige Warnungen (z.B. doppelt verwendete Dienstkonten, Dienstkonten in der Gruppe der lokalen Admins, usw.) angezeigt, die nach den vorhandenen Informationen, bereinigt wurden.

Zunächst wurde ein weiteres Zertifikat für die Zentraladministration beantragt. Danach wurde eine Teamwebseite angelegt, auf der ein DMS eingerichtet wird, welches die neuen Funktionen von Sharepoint 2010 nutzen soll, wie z.B. Metadaten Service und die Navigation zu Dokumenten über die vorhandenen Metadaten. Ausserdem sollen die bisher vorhandenen Daten, nach und nach, auf den Sharepoint wandern und die neu angelegten Dokumente direkt im Sharepoint erstellt werden.

Das Backup der SQL-Datenbanken ist bereits im DPM 2010 eingerichtet. Die Sicherung der Sharepoint-Farm an sich, ist ein weiterers Thema, was die nächsten Tage angegangen wird.

Windows 7 Remotedesktop Zertifikat anpassen

Um das zu verwendende Zertifikat für z.B. Server 2008 anzupassen, kann man hier das Tool tsconfig.msc.

Dies ist allerdings in den Client-Versionen nicht verfügbar. Standardmässig verwendet Windows 7 ein selbst signiertes Zertfikat für die Remotedesktop Verbindung, welches natürlich nicht von einer authorisierten Zertifikatsverwaltung ausgestellt ist.

Um diesen Fehler zu vemeiden und das von der (falls vorhanden) eigenen Zertifizierungsstelle, ausgestellte Zertifkat zu verwenden, sind mehrere Schritte notwendig:

  1. Öffnen der Zertifikatsverwaltug auf dem Client und auswählen des Zertifikats, welches für die Remotedesktopverbindung genutzt werden soll.
  2. Um Remotedesktop das korrekte Zertifikat zur Verwendung mitzuteilen, muss sich der SHA1Hash (Fingerabdruck) notiert werden.
  3. Nun starten wir „Regedit“  und navigieren zu folgendem Schlüssel „HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp“ und hier legen wir einen neuen „SSLCertificateSHA1Hash“ , binärischen Wert (REG_BINARY) an.
  4. Als Wert geben wir den oben notierten Fingerabdruck des zu verwendenden Zertifikats ein
  5. Leider war das noch nicht alles, da die Remotedesktopdienste unter Windows 7 im Sicherheitsaccount „Netzwerkdienst“ laufen, muss dieser noch entsprechend berechtigt werden, dass Zertifikat einzulesen, dazu starten wir zunächs ein Managementkonsole „mmc.exe“ und fügen unter Snap-In „Zertifikate“ hinzu, im erscheinenden Auswahlfenster wählen wir „Computer“ aus, klicken auf weiter, lassen „Lokalen Computer“ aktiviert und bestätigen die Auswahl mit einem Klick auf „Fertigstellen
  6. Nun navigieren wir zum Fenster „Zertifikate -> Eigene Zertifikate -> Zertifikate“ und starten einen Rechtsklick auf das Zertifikat im Kontext wählen wir „Alle Aufgaben -> Private Schlüssel verwalten
  7. Im erscheinenden Fenster wählen wir „Hinzufügen“ und geben den „Netzwerkdienst“ an und geben diesem die Berechtigung „Lesen

Die nächste Remotedesktopverbindung sollte nun mit dem angegebenen Zertifikat starten, dies Funktioniert direkt nach dem nächsten Versuch einer Remoteverbindung mit dem Windows 7 Client

Die Informationen stammen aus einem Technet Forum und haben bei mir einwandfrei funlktioniert.

Exchange 2007 – Zertifikat anfordern

  1. Management-Shell Exchange als Administrator öffnen
  2. New-ExchangeCertificate -GenerateRequest -SubjectName „c=DE, o=domain, cn=oldmail.domain.de“ -DomainName oldmail.domain.de, owa,servername, server.domain.de, autodiscover.domain.de, autodiscover.domain.de, -IncludeAutodiscover -PrivateKeyExportable $true -Path c:newe2007cert.req
  3. Die Anforderung an die Zertifizierungsstelle einsenden
  4. Das signierte Zertifikat als Base64-Datei speichern
  5. Zertifikat importieren Import-ExchangeCertificate -Path c:newe2007certsigniert.cer
  6. Zertifikat einschalten Enable-ExchangeCertificate
    -Thumbprint <fingerabdruck des Zertifikats>
    -Services SMTP,IMAP,POP,UM,IIS
  7. Dienste mit dem Zertifikat verknüpfen und aktivieren Enable-ExchangeCertificate
    -Thumbprint <fingerabdruck des Zertifikats>
    -Services SMTP,IMAP,POP,UM,IIS

Somit die Zeritifkatsanforderung und Aktivierung abgeschlossen, dass Zertifikat ist ab sofort auf den angewendeten Services gültig

SAN Zertifikate mit der eigenen CA

Folgender Befehl wurde auf Zertifikatsserver ausgeführt:

certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Ergebnis:

S:DomainTools>certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

SYSTEMCurrentControlSetServicesCertSvcConfigurationF1NaL-CAPolicyModulesC
ertificateAuthority_MicrosoftDefault.PolicyEditFlags:

Alter Wert:
  EditFlags REG_DWORD = 11014e (1114446)
    EDITF_REQUESTEXTENSIONLIST — 2
    EDITF_DISABLEEXTENSIONLIST — 4
    EDITF_ADDOLDKEYUSAGE — 8
    EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)
    EDITF_ENABLEAKIKEYID — 100 (256)
    EDITF_ENABLEDEFAULTSMIME — 10000 (65536)
    EDITF_ENABLECHASECLIENTDC — 100000 (1048576)

Neuer Wert:
  EditFlags REG_DWORD = 15014e (1376590)
    EDITF_REQUESTEXTENSIONLIST — 2
    EDITF_DISABLEEXTENSIONLIST — 4
    EDITF_ADDOLDKEYUSAGE — 8
    EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)
    EDITF_ENABLEAKIKEYID — 100 (256)
    EDITF_ENABLEDEFAULTSMIME — 10000 (65536)
    EDITF_ATTRIBUTESUBJECTALTNAME2 — 40000 (262144)
    EDITF_ENABLECHASECLIENTDC — 100000 (1048576)
CertUtil: -setreg-Befehl wurde erfolgreich ausgeführt.
Der Dienst „CertSvc“ muss neu gestartet werden, damit die Änderungen wirksam wer
den.