it-swarm-eu.dev

Checkliste zum Aufbau einer Offline Root & Intermediate Certificate Authority (CA)

Microsoft erlaubt einer Zertifizierungsstelle, Cryptography Next Generation (CNG) und weist auf Inkompatibilitätsprobleme hin für Clients zu verwenden, die diese Suite nicht unterstützen.

Hier ist ein Bild der Standard-Kryptografieeinstellungen für eine 2008 R2-Zertifizierungsstelle. Dieser Computer ist eine nicht domänenverbundene eigenständige Zertifizierungsstelle:

Default Cryptography settings

Hier sind die installierten Anbieter. Die CNG-Anbieter sind mit einem # gekennzeichnet

enter image description here

Meine Absicht ist es, eine Allzweck-Offline-Stammzertifizierungsstelle und dann mehrere Zwischenzertifizierungsstellen zu haben, die einem bestimmten Zweck dienen (nur MSFT gegen Unix gegen SmartCards usw.).

Was sind die idealen Einstellungen für ein Stammzertifikat mit einem Ablauf von 5, 10 und 15 Jahren?

  1. CSP
  2. Unterzeichnungszertifikat
  3. Länge des Schlüsselzeichens

Da es sich um eine RootCA handelt, wirken sich alle Parameter auf die CPU mit geringer Leistung (mobile Geräte) aus.

25

Hinweis: Dies ist ein (sehr, sehr langes) Kompendium verschiedener Empfehlungen und Maßnahmen, die Microsoft, NIST und andere angesehene PKI- und Kryptographie-Experten angegeben haben. Wenn Sie etwas sehen, das auch nur die geringste Überarbeitung erfordert, lassen Sie es mich wissen.

Bevor ich mit der Konfiguration der Zertifizierungsstelle und ihrer Subs beginne, ist es gut zu wissen, dass, obwohl für CryptoAPI von MSFT ein selbstsignierter Stamm erforderlich ist, einige Nicht-MSFT-Software möglicherweise RFC 3280 folgt und zulässt, dass jede Zertifizierungsstelle zu Validierungszwecken der vertrauenswürdige Stamm ist. Ein Grund kann sein, dass die Nicht-MSFT-Software eine geringere Schlüssellänge bevorzugt.

Hier einige Konfigurationshinweise und Anleitungen zum Einrichten eines CA ROOT und der Subs:

Speichern des privaten Schlüssels der Zertifizierungsstelle

  • Am besten: Speichern Sie den Schlüssel auf einem HSM, der die Schlüsselzählung unterstützt. Jedes Mal, wenn der private Schlüssel der Zertifizierungsstelle verwendet wird, wird der Zähler erhöht. Dies verbessert Ihr Überwachungsprofil. Suchen Sie nach FIPS140 Level 3 oder 4

  • Gut: Speichern Sie den privaten Schlüssel auf einer Smartcard. Obwohl mir keine Smart Card bekannt ist, die Schlüsselzählung bietet, aktiviert die Schlüsselzählung kann zu unerwarteten Ergebnissen im Ereignisprotokoll führen

  • Akzeptabel: Speichern Sie den privaten Schlüssel in Windows DPAPI. Stellen Sie sicher, dass diese Schlüssel und der Schlüsselregistrierungsagent nicht in Roaming Credentials landen. Siehe auch: Auflisten von DPAPI- und Roaming-Anmeldeinformationen

Schlüssellänge

  • Verwenden Sie 1024 nicht als Schlüssellänge ... NIST hat es 2011 auslaufen lassen. MSFT wird es niemals zu Ihrem Trusted Root CA Store hinzufügen, da es nicht die akzeptierten technischen Mindestkriterien erfüllt .

  • Stammzertifizierungsstellen das unterstützt ältere Apps sollten niemals größer als 2048 Bit sein. Grund: MSFT-Support sieht viele Fälle, in denen Java-Apps oder Netzwerkgeräte unterstützen nur Schlüsselgrößen von 2048 Byte . Speichern Sie die höheren Bitlängen in Zertifizierungsstellen, die für einen bestimmten Zweck eingeschränkt sind (Windows- oder Netzwerkgeräte) usw.

  • Das NIST empfiehlt 2048 oder 3072 Bit. ECC wird unterstützt, kann jedoch Probleme mit der Geräteinteroperabilität verursachen.

  • Planen Sie die bestmögliche Verschlüsselung (Schlüssellänge) in der gesamten PKI ein, ansonsten erwarten Sie gemischte Sicherheitsvorteile .

  • Mobile Clients haben Probleme (hohe CPU) oder Inkompatibilität mit großen Schlüsseln

Ablauf

Der Algorithmus und die Schlüssellänge können einen Einfluss darauf haben, wie lange Zertifikate gültig sein sollen, da sie effektiv bestimmen, wie lange ein Angreifer-Crack dauern kann. Je stärker die Kryptografie ist, desto länger sind Sie möglicherweise darauf vorbereitet, Zertifikate gültig zu haben

Ein Ansatz besteht darin, die längste Gültigkeit zu ermitteln, die Sie für Endentitätszertifikate benötigen, diese für die ausstellenden Ca zu verdoppeln und sie dann für die Root-Ca erneut zu verdoppeln (in zwei Ebenen). Mit diesem Ansatz würden Sie jedes Ca-Zertifikat routinemäßig erneuern, wenn die Hälfte seiner Lebensdauer erreicht ist. Dies liegt daran, dass ein Ca-Zertifikat keine Zertifikate mit einem Ablaufdatum nach dem des Ca-Zertifikats selbst ausstellen kann.

Geeignete Werte können nur von Ihrer Organisation und Sicherheitsrichtlinie bestimmt werden. In der Regel hat ein Root-CA jedoch eine Zertifikatslebensdauer von 10 oder 20 Jahren.

Wenn Sie Bedenken hinsichtlich der Kompatibilität haben, legen Sie das Ablaufdatum unter 2038 fest. Dies liegt an Systemen, die Daten seit dem 1. Januar 1970 über eine vorzeichenbehaftete 32-Bit-Ganzzahl als Sekunden codieren. Lesen Sie hier mehr über dieses Problem.

Einen Hash auswählen

Vor allem:

  • Windows 2003 und XP-Clients benötigen möglicherweise einen Patch für SHA2-Algorithmen , der SHA256, SHA384 und SHA512 enthält. Weitere technische Informationen

  • Authenticode und S/MIME mit SHA2-Hashing werden auf XP oder 2003) nicht unterstützt

  • "In Bezug auf die SHA-224-Unterstützung bietet SHA-224 weniger Sicherheit als SHA-256, benötigt jedoch die gleiche Menge an Ressourcen. Außerdem wird SHA-224 im Allgemeinen nicht von Protokollen und Anwendungen verwendet. Die Suite B-Standards der NSA enthalten diese ebenfalls nicht." Quelle

  • "Verwenden Sie die SHA2-Suite nirgendwo in der CA-Hierarchie, wenn Sie planen, XP entweder dem Zertifikat zu vertrauen, das Zertifikat zu validieren, das Zertifikat für die Kettenvalidierung zu verwenden oder ein Zertifikat von der Zertifizierungsstelle zu erhalten. Obwohl XP SP3 die Validierung von Zertifikaten ermöglicht, die SHA2 in der CA-Hierarchie verwenden, und KB 968730 die eingeschränkte Registrierung von Zertifikaten ermöglicht, die von einer CA mit SHA2 signiert wurden, blockiert jede Verwendung diskreter Signaturen = XP vollständig. "( Quelle )

Auswahl eines kryptografischen Anbieters

Generierung von zufälligen Seriennummern aktivieren

Ab 2012 ist dies erforderlich, wenn Sie MD5 als Hash verwenden. Es ist immer noch ein gute Idee, wenn SHA1 oder höher verwendet wird. Weitere Informationen finden Sie unter dieses Windows 2008R2 "How to" .

Erstellen Sie eine Certificate Practice Statement

Eine Zertifikatspraktikerklärung ist eine Erklärung der Praktiken, mit denen die IT die von ihr ausgestellten Zertifikate verwaltet. Es wird beschrieben, wie die Zertifikatrichtlinie der Organisation im Kontext der Systemarchitektur der Organisation und ihrer Betriebsverfahren interpretiert wird. Die IT-Abteilung ist für die Erstellung und Pflege der Zertifikatspraxiserklärung verantwortlich. ( Quelle )

HINWEIS: In einigen Situationen, z. B. wenn digitale Signaturen für verbindliche Verträge verwendet werden, kann die Erklärung zur Zertifikatspraxis auch als rechtliche Erklärung zum bereitgestellten Sicherheitsniveau und zu den Sicherheitsvorkehrungen angesehen werden, mit denen das Sicherheitsniveau festgelegt und aufrechterhalten wird .

Für Unterstützung beim Schreiben einer CPS-Anweisung hier ist eine von Microsoft erstellte "Job Aid"

Best Practice: Obwohl es möglich ist, Freiformtext in dieses Feld einzufügen (siehe notice unten), besteht die ideale Lösung darin, eine URL zu verwenden. Auf diese Weise kann die Richtlinie aktualisiert werden, ohne dass die Zertifikate erneut ausgestellt werden. Außerdem wird ein unnötiges Aufblähen des Zertifikatspeichers verhindert.

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.Microsoft.com/policy/isspolicy.asp"

Zertifikatrichtlinien

Dies ist eine selbst definierte OID], die das Maß an Vertrauen beschreibt, das in Ihr Zertifikat gesetzt werden sollte (hoch, mittel, niedrig usw.). Dies wird auch als Ausstellungsrichtlinien oder Assurance-Richtlinien (in MSFT) bezeichnet. . Siehe diese StackExchange-Antwort , wie dieses Feld richtig verwendet wird.

Stellen Sie sicher, dass Anwendungsrichtlinien und EKU-Richtlinien übereinstimmen

Anwendungsrichtlinien ist eine optionale Microsoft-Konvention. Wenn Sie Zertifikate ausstellen, die sowohl Anwendungsrichtlinien- als auch EKU-Erweiterungen enthalten, stellen Sie sicher, dass die beiden Erweiterungen identische Objektkennungen enthalten.

CRL-Prüfung aktivieren

Normalerweise überprüft eine Windows Server 2003-Zertifizierungsstelle immer die Sperrung aller Zertifikate in der PKI-Hierarchie (mit Ausnahme des Stammzertifizierungsstellenzertifikats), bevor ein Endentitätszertifikat ausgestellt wird. Verwenden Sie zum Deaktivieren dieser Funktion den folgenden Befehl auf der Zertifizierungsstelle und starten Sie den Zertifizierungsstellendienst neu:

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

CRL-Verteilungspunkt

Spezielle Anleitung für Stammzertifizierungsstellen

  • Dies ist in einer Stammzertifizierungsstelle optional und bei falscher Ausführung möglicherweise wird Ihr privater Schlüssel verfügbar gemacht .

  • Alle CRL-Veröffentlichungen werden manuell von einer Offline-RootCA zu allen anderen Unter-CAs durchgeführt. Eine Alternative ist verwenden Sie ein Audiokabel, um die Einwegkommunikation zu erleichtern von der Root zu den Sub-CAs

  • Es ist durchaus akzeptabel, dass die Stammzertifizierungsstelle für jedes ausgestellte Zertifikat unterschiedliche CRL-Speicherorte an untergeordnete Zertifizierungsstellen ausstellt.

  • Eine CRL im Stammverzeichnis ist eine bewährte Methode, wenn zwei PKIs einander vertrauen und die Richtlinienzuordnung durchgeführt wird. Dadurch kann das Zertifikat widerrufen werden.

Es ist ziemlich wichtig, die CRL "richtig" zu machen, da es an jeder Anwendung liegt, die CRL-Prüfung durchzuführen. Beispielsweise erzwingt die Smartcard-Anmeldung auf Domänencontrollern immer die Sperrprüfung und lehnt ein Anmeldeereignis ab, wenn die Sperrprüfung nicht durchgeführt werden kann oder fehlschlägt.

Hinweis Wenn ein Zertifikat in der Kette nicht validiert werden kann oder als widerrufen eingestuft wird, nimmt die gesamte Kette den Status dieses einen Zertifikats an.

  • Eine selbstsignierte Stammzertifizierungsstelle sollte keine CDPs auflisten. Die meisten Windows-Anwendungen aktivieren das Flag CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT nicht und ignorieren daher das CDP ( dies ist der Standardüberprüfungsmodus ). Wenn das Flag aktiviert ist und der CDP für das selbstsignierte Stammzertifikat leer ist, wird kein Fehler zurückgegeben.

  • Verwenden Sie kein HTTPS und LDAPS. Diese URLs werden nicht mehr als Verteilungspunktreferenzen unterstützt. Grund dafür ist, dass HTTPS- und LDAPS-URLs Zertifikate verwenden, die möglicherweise widerrufen werden oder nicht. Der Sperrprüfungsprozess kann zu Sperrschleifen führen, wenn HTTPS- oder LDAPS-URLs verwendet werden. Um festzustellen, ob das Zertifikat widerrufen wurde, muss die CRL abgerufen werden. Die CRL kann jedoch nur abgerufen werden, wenn der Sperrstatus der von HTTPS oder LDAPS verwendeten Zertifikate ermittelt wurde.

  • Erwägen Sie die Verwendung von HTTP anstelle von LDAP. Obwohl AD DS die Veröffentlichung von CRLs auf allen Domänencontrollern in der Gesamtstruktur ermöglicht), implementieren Sie HTTP anstelle von LDAP für die Veröffentlichung von Sperrinformationen. Nur HTTP ermöglicht die Verwendung von ETag - und Cache-Control: Max-age - Header bieten eine bessere Unterstützung für Proxys und aktuellere Sperrinformationen. Darüber hinaus bietet HTTP eine bessere heterogene Unterstützung, da HTTP von den meisten Linux-, UNIX- und Netzwerkgeräte-Clients unterstützt wird.

  • Ein weiterer Grund, LDAP nicht zu verwenden, besteht darin, dass das Sperrfenster kleiner sein soll. Wenn Sie AD LDAP zum Replizieren von CA-Informationen verwenden, darf das Sperrfenster nicht kürzer sein als die Zeit, die alle Standorte in AD benötigen, um das CA-Update abzurufen. Oft kann diese Replikation bis zu 8 Stunden dauern ... das sind 8 Stunden, bis der Zugriff eines Smartcard-Benutzers widerrufen wird. 'Todo: Die neue empfohlene CRL-Aktualisierungszeit lautet: ????? `

  • Stellen Sie alle URLs hoch verfügbar (auch bekannt als LDAP für externe Hosts nicht). Windows verlangsamt den Validierungsprozess für bis zu 20 Sekunden und wiederholen Sie die fehlgeschlagene Verbindung wiederholt mindestens so oft wie alle 30 Minuten. Ich vermute, dass Pre-Fetching dazu führt, dass dies auch dann auftritt, wenn der Benutzer die Site nicht aktiv nutzt.

  • Überwachen Sie die Größe Ihrer CRL. Wenn das CRL-Objekt so groß ist, dass CryptoAPI das Objekt nicht innerhalb des zugewiesenen maximalen Zeitlimits herunterladen kann, ein Fehler "Sperrung offline" wird zurückgegeben und der Objektdownload wird beendet.

Hinweis: Die CRL-Verteilung über HTTP mit ETAG-Unterstützung kann bei Verwendung von Windows 2003/IIS6 zu Problemen mit IE6 führen, bei denen die Verbindung TCP) kontinuierlich zurückgesetzt wird.

  • (Optional) Neueste CRL aktivieren : Diese unkritische Erweiterung listet die Emittenten und Standorte auf, von denen die Delta-CRLs abgerufen werden sollen. Wenn das Attribut "Freshest CRL" weder in der CRL noch im Zertifikat vorhanden ist, wird die Basis-CRL als reguläre CRL behandelt, nicht als Teil eines Basis-CRL/Delta-CRL-Paares.

Die Microsoft-Zertifizierungsstelle fügt die Erweiterung "Freshest CRL" nicht in ausgestellte Zertifikate ein. Es ist jedoch möglich, einem ausgestellten Zertifikat die Erweiterung "Freshest CRL" hinzuzufügen. Sie müssten Code schreiben, um ihn zur Anforderung hinzuzufügen, ein benutzerdefiniertes Richtlinienmodul zu schreiben oder certutil –setextension Für eine ausstehende Anforderung zu verwenden. Weitere Informationen zur erweiterten Zertifikatsregistrierung finden Sie in der Dokumentation zur erweiterten Registrierung und Verwaltung von Zertifikaten auf der Microsoft-Website

Warnung Wenn Delta-CRLs in einer Zertifizierungsstelle aktiviert sind, müssen sowohl die Basis-CRL als auch die Delta-CRL überprüft werden, um den Sperrstatus des Zertifikats zu ermitteln. Wenn einer der beiden oder beide nicht verfügbar sind, meldet die Verkettungsmaschine, dass der Widerrufsstatus nicht ermittelt werden kann, und eine Anwendung kann das Zertifikat ablehnen.

CRL-Dimensionierung und Wartung (CRL-Partitionierung)

Die CRL vergrößert sich für jedes widerrufene Zertifikat um 29 Byte. Dementsprechend werden widerrufene Zertifikate aus der CRL entfernt, wenn das Zertifikat sein ursprüngliches Ablaufdatum erreicht.

Da durch das Erneuern eines CA-Zertifikats eine neue/leere CRL generiert wird, können ausstellende CAs in Betracht ziehen, die CA alle 100-125K-Zertifikate mit einem neuen Schlüssel zu erneuern, um eine angemessene CRL-Größe beizubehalten. Diese Emissionsnummer basiert auf der Annahme, dass ungefähr 10 Prozent der ausgestellten Zertifikate vor ihrem natürlichen Ablaufdatum widerrufen werden. Wenn die tatsächliche oder geplante Widerrufsrate für Ihr Unternehmen höher oder niedriger ist, passen Sie die Schlüsselerneuerungsstrategie entsprechend an. Weitere Informationen

Ziehen Sie auch in Betracht, die CRL häufiger zu partitionieren, wenn der Ablauf mehr als ein oder zwei Jahre beträgt, da die Wahrscheinlichkeit eines Widerrufs zunimmt.

Der Nachteil hierbei sind längere Startzeiten, da jedes Zertifikat vom Server validiert wird.

Vorsichtsmaßnahmen für die CRL-Sicherheit

Wenn Sie eine CRL verwenden, signieren Sie die CRL nicht mit MD5. Es ist auch eine gute Idee, Randomisierung hinzufügen zum CRL-Signaturschlüssel hinzuzufügen.

Zugriff auf Autoritätsinformationen

In diesem Feld kann das Zertifikatvalidierungssubsystem bei Bedarf zusätzliche Zertifikate herunterladen, wenn diese nicht auf dem lokalen Computer gespeichert sind.

  • Eine selbstsignierte Stammzertifizierungsstelle sollte keine AIA-Standorte auflisten ( siehe Grund hier )

  • In der AIA-Erweiterung sind maximal fünf URLs für jedes Zertifikat in der Zertifikatkette zulässig. Darüber hinaus werden maximal 10 URLs für die gesamte Zertifikatkette unterstützt. Diese Begrenzung der Anzahl der URLs wurde hinzugefügt, um die potenzielle Verwendung von Verweisen auf "Authority Info Access" bei Denial-of-Service-Angriffen zu verringern.

  • Verwenden Sie keine HTTP [~ # ~] s [~ # ~] und LDAP [~ # ~] s [~ # ~] . Diese URLs werden nicht mehr als Verteilungspunktreferenzen unterstützt. Grund dafür ist, dass HTTPS- und LDAPS-URLs Zertifikate verwenden, die möglicherweise widerrufen werden oder nicht. Der Sperrprüfungsprozess kann zu Sperrschleifen führen, wenn HTTPS- oder LDAPS-URLs verwendet werden. Um festzustellen, ob das Zertifikat widerrufen wurde, muss die CRL abgerufen werden. Die CRL kann jedoch nur abgerufen werden, wenn der Sperrstatus der von HTTPS oder LDAPS verwendeten Zertifikate ermittelt wurde.

OCSP-Validierung aktivieren

Der OCSP-Responder befindet sich üblicherweise unter: http://<fqdn of the ocsp responder>/ocsp. Diese URL muss in der AIA aktiviert sein. Siehe diese Anweisungen für Windows.

Beachten Sie, dass die vollständige OCSP-Validierung standardmäßig deaktiviert ist (obwohl sie für EV-Zertifikate gemäß der Spezifikation aktiviert sein sollte). Wenn Sie die OCSP-Prüfung aktivieren erhöht die Latenz der ursprünglichen Verbindung

Sicherere Systeme möchten OCSP-Überwachung auf der Client- oder Serverseite aktivieren

OCSP-Cache-Dauer

Alle OCSP-Aktionen werden über das HTTP-Protokoll ausgeführt und unterliegen daher typischen HTTP-Proxy-Cache-Regeln.

Insbesondere definiert der Header Max-age Die maximale Zeit, die ein Proxyserver oder -client eine CRL- oder OCSP-Antwort zwischenspeichert, bevor mithilfe eines bedingten GET ermittelt wird, ob sich das Objekt geändert hat. Verwenden Sie diese Informationen, um den Webserver so zu konfigurieren, dass die entsprechenden Header festgelegt werden. Suchen Sie an anderer Stelle auf dieser Seite nach AD-IIS-spezifischen Befehlen dafür.

Definieren Sie eine Richtlinie in ausgestellten Zertifikaten

Die übergeordnete Zertifizierungsstelle definiert, ob CA-Zertifikatrichtlinien von Unterzertifizierungsstellen zugelassen werden sollen oder nicht. Diese Einstellung kann definiert werden, wenn ein Aussteller oder eine Anwendungsrichtlinie in eine Unterzertifizierungsstelle aufgenommen werden muss.

Beispielrichtlinien umfassen eine EKU für SmartCards, Authentifizierung oder SSL/Server-Authentifizierung.

  • Achten Sie auf Zertifikate ohne die Erweiterung Certificate Policies, Da dies den Richtlinienbaum komplizieren kann. Weitere Informationen finden Sie in RFC 5280

  • Beachten Sie, dass Richtlinienzuordnungen andere Richtlinien im Pfad ersetzen können

  • Es gibt eine spezielle Richtlinie namens anypolicy, die die Verarbeitung ändert

  • Es gibt Erweiterungen, die anypolicy ändern.

  • Wenn Sie Zertifikatrichtlinien verwenden, markieren Sie diese unbedingt als critical, da sonst das berechnete valid_policy_tree Leer wird. Verwandelt die Richtlinie in einen verherrlichten Kommentar.

Überwachen Sie die Durchsetzung der DN-Länge

Die ursprüngliche CCITT-Spezifikation für das OU-Feld besagt, dass es auf 64 Zeichen begrenzt sein sollte. Normalerweise erzwingt die Zertifizierungsstelle x.500-Namenslängenstandards für die Betrefferweiterung von Zertifikaten für alle Anforderungen. Es ist möglich, dass tiefe OU-Pfade die normalen Längenbeschränkungen überschreiten.

Zertifikatsübergreifende Verteilungspunkte

Diese Funktion hilft in Umgebungen, in denen zwei PKIs installiert sein müssen, eine für ältere Hardware/Software, die keine moderne Kryptografie unterstützt, und eine andere PKI für modernere Zwecke.

Beschränken Sie die EKU

Im Gegensatz zu RFC 5280, in dem es heißt: "Im Allgemeinen wird die EKU-Erweiterung nur in Endentitätszertifikaten angezeigt." Es ist eine gute Idee, Einschränkungen für die Verwendung des CA-Schlüssels zu setzen.

Ein typisches eigenständiges CA-Zertifikat enthält Berechtigungen zum Erstellen digitaler Signaturen, Zertifikatsignaturen und CRL-Signaturen als Schlüsselwerte. Dies ist Teil des Problems mit dem FLAME-Sicherheitsproblem.

Die Implementierung der MSFT-Smartcard erfordert eine der folgenden EKUs und möglicherweise einen Hotfix

  • Microsoft Smartcard EKU
  • Kryptografie mit öffentlichem Schlüssel für die PKINIT-Clientauthentifizierungsauthentifizierungs-EKU (Initial Authentication), wie in PKINIT RFC 4556 definiert

Es gibt auch interessante Einschränkungen bei der Validierung der EKU (Link tbd).

Wenn Sie an EKU-Einschränkungen interessiert sind, sollten Sie diese Antwort in Bezug auf OIDs und dies in Bezug auf kontrahierte Zertifikate sehen

Seien Sie vorsichtig mit den grundlegenden Einschränkungen "Pfad"

Die grundlegende Einschränkung sollte beschreiben, ob das Zertifikat eine "Endeinheit" ist oder nicht . Hinzufügen einer Pfadbeschränkung zu einer Zwischenzertifizierungsstelle funktioniert möglicherweise nicht wie erwartet, da dies eine ungewöhnliche Konfiguration ist und von Clients möglicherweise nicht berücksichtigt wird.

Qualifizierte Unterordnung für Zwischenzertifizierungsstellen

  • Um die Arten von Zertifikaten einzuschränken, die eine SubCA anbieten kann, siehe dieser Link und dieser

  • Wenn eine qualifizierte Unterordnung durchgeführt wird, kann das Widerrufen eines Cross-Signed-Root schwierig sein, da die Roots die CRLs nicht häufig aktualisieren.

Berechtigungsschlüsselkennung/Betreffschlüsselkennung

Hinweis Wenn die AKI-Erweiterung eines Zertifikats eine KeyID enthält, muss das Ausstellerzertifikat für CryptoAPI eine übereinstimmende SKI enthalten. Dies unterscheidet sich von RFC 3280, bei dem die SKI- und AKI-Übereinstimmung optional ist. (todo: Warum sollte sich jemand dafür entscheiden, dies umzusetzen?)

AKI matching to find key parent

Geben Sie dem Root und der CA einen aussagekräftigen Namen

Die Benutzer interagieren mit Ihrem Zertifikat, wenn sie es importieren, importierte Zertifikate überprüfen und Fehler beheben. Die von MSFT empfohlene Vorgehensweise und Anforderung ist, dass der Stamm einen aussagekräftigen Namen hat, der Ihre Organisation identifiziert, und nicht etwas Abstraktes und Gemeinsames wie CA1.

Dieser nächste Teil gilt für Namen von Intermediate/SubCAs, die für einen bestimmten Zweck eingeschränkt werden: Authentifizierung vs Signieren vs Verschlüsselung

Überraschenderweise interagieren Endbenutzer und Techniker, die die Nuancen von PKI nicht verstehen, häufiger mit den von Ihnen ausgewählten Servernamen als Sie denken, wenn Sie S/MIME oder digitale Signaturen (usw.) verwenden.

Ich persönlich halte es für eine gute Idee, die ausstellenden Zertifikate in etwas Benutzerfreundlicheres wie "Company Signer 1" Umbenennen, wo ich auf einen Blick erkennen kann

  • Von wem wird die Unterschrift kommen (Texas A & M oder ihr Rivale)
  • Was wird es verwendet? Verschlüsselung vs Signieren

Es ist wichtig, den Unterschied zwischen einer Nachricht, die zwischen zwei Parteien verschlüsselt wurde, und einer Nachricht, die signiert wurde, zu erkennen. Ein Beispiel, bei dem dies wichtig ist, ist, wenn ich den Empfänger dazu bringen kann, eine an ihn gesendete Erklärung zu wiederholen. Benutzer A könnte Benutzer B sagen "A, ich schulde Ihnen 100 $". Wenn B mit einem Echo dieser Nachricht mit dem falschen Schlüssel antwortete, haben sie eine fiktive 100-Dollar-Schuld effektiv digital notariell beglaubigt (statt nur zu verschlüsseln).

Hier ist ein Beispiel für einen Benutzerdialog für S/MIME . Erwarten Sie ähnliche Benutzeroberflächen für Brower-basierte Zertifikate. Beachten Sie, dass der Name des Ausstellers nicht benutzerfreundlich ist.

Select a SMIME certificate.. really?

Alternative Codierungen

Hinweis: Apropos Namen: Wenn ein Glied in der Kette eine alternative Codierung verwendet, können Clients das Ausstellerfeld für den Betreff möglicherweise nicht überprüfen. Windows normalisiert diese Zeichenfolgen während eines Vergleichs nicht. Stellen Sie daher sicher, dass die Namen der Zertifizierungsstelle aus binärer Sicht identisch sind (im Gegensatz zur RFC-Empfehlung).

Name matching to find key parent

Hochsicherheits-/Suite B-Bereitstellungen

  • Hier ist Informationen zu den in Windows 2008 und R2 unterstützten Suite B-Algorithmen

    ALGORITHMUS GEHEIMNIS TOP SECRET

    Verschlüsselung: Advanced Standard (AES) 128 Bit 256 Bit

    Digitale Signatur: Elliptische Kurve 256-Bit-Kurve des digitalen Signaturalgorithmus (ECDSA). 384-Bit-Kurve

    Schlüsselaustausch: Elliptische Kurve Diffie-Hellman (ECDH) 256-Bit-Kurve. 384-Bit-Kurve

    Hashing: Sicherer Hash-Algorithmus (SHA) SHA-256 SHA-384

  • Für die Suite B-Konformität können auch die Schlüsselgröße ECDSA_P384#Microsoft Software Key Service Provider Sowie 384 Und SHA384 Als Hash-Algorithmus ausgewählt werden, wenn die gewünschte Klassifizierungsebene streng geheim ist. Die Einstellungen, die der erforderlichen Klassifizierungsebene entsprechen, sollten verwendet werden. Optional ist auch ECDSA_P521 Verfügbar. Während die Verwendung einer 521-Bit-ECC-Kurve die kryptografischen Anforderungen von Suite B möglicherweise übersteigt, ist 521 aufgrund der nicht standardmäßigen Schlüsselgröße nicht Teil der offiziellen Suite B-Spezifikation.

PKCS # 1 v2.1

Microsoft CA DCOM-Ports schützen

Die Windows Server 2003-Zertifizierungsstelle erzwingt standardmäßig keine Verschlüsselung für die DCOM-Schnittstellen ICertRequest oder ICertAdmin. Normalerweise ist diese Einstellung nur in speziellen Betriebsszenarien erforderlich und sollte nicht aktiviert werden. Standardmäßig unterstützen nur Windows Server 2003-Computer die DCOM-Verschlüsselung auf diesen Schnittstellen. Beispielsweise erzwingen Windows XP-Clients standardmäßig keine Verschlüsselung bei Zertifikatanforderung an eine Windows Server 2003-Zertifizierungsstelle. Quelle

CNG-Speicher für private Schlüssel im Vergleich zu CSP-Speicher

Wenn Sie Certificate Template v3 registrieren, wird der private Schlüssel in den privaten CNG-Schlüsselspeicher auf dem Clientcomputer verschoben. Wenn Sie die Zertifikatvorlage v2 oder v1 registrieren, wird der private Schlüssel in den CSP-Speicher übernommen. Die Zertifikate sind in beiden Fällen für alle Anwendungen sichtbar, jedoch nicht für ihre privaten Schlüssel. Daher zeigen die meisten Anwendungen das Zertifikat als verfügbar an, können jedoch keine Daten mit dem zugehörigen privaten Schlüssel signieren oder entschlüsseln, es sei denn, sie unterstützen die CNG-Speicherung.

Mit der Zertifikats-MMC können Sie nicht zwischen CNG- und CSP-Speichern unterscheiden. Wenn Sie sehen möchten, welchen Speicher ein bestimmtes Zertifikat verwendet, müssen Sie CERTUTIL -repairstore my * (Oder CERTUTIL -user -repairstore my *) Verwenden und sich das Feld Provider ansehen. Wenn "... Key Storage Provider" angezeigt wird, handelt es sich um CNG, während alle anderen Anbieter CSP sind.

Wenn Sie die erste Zertifikatanforderung manuell erstellen (benutzerdefinierte Anforderung in MMC erstellen), können Sie zwischen "CNG-Speicher" und "Legacy-Schlüssel" wählen, wobei Legacy CSP bedeutet. Das Folgende ist meine erfahrungsbasierte Liste dessen, was CNG nicht unterstützt - Sie können nirgendwo eine maßgebliche Liste finden, daher ergibt sich dies aus meinen Untersuchungen im Laufe der Zeit:

  • EFS Wird in Windows 2008/Vista nicht unterstützt, wird in Windows 7/2008R2 unterstützt
  • benutzerverschlüsselungszertifikate
  • VPN/WiFi-Client (EAPTLS, PEAP-Client)

  • Windows 2008/7 Wird bei der Authentifizierung von Benutzer- oder Computerzertifikaten nicht unterstützt

  • TMG 2010-Serverzertifikate für Weblistener
  • Outlook 2003-Benutzer-E-Mail-Zertifikate für Signaturen oder Verschlüsselung
  • Kerberos Windows 2008/Vista- DC Zertifikate
  • System Center Operations Manager 2007 R2
  • System Center Configuration Manager 2007 R2
  • SQL Server 2008 R2-
  • Forefront Identity Manager 2010-Zertifikatverwaltung

Weitere Informationen zur CNG-Kompatibilität finden Sie hier (auf Tschechisch, obwohl Chrome behandelt die automatische Übersetzung gut)

Smartcards & ausstellende Zertifizierungsstellen

Wenn Sie Benutzern eine zweite Smartcard zur Authentifizierung geben möchten, verwenden Sie dafür eine zweite Aussteller-Zertifizierungsstelle. Grund: Windows 7-Anforderungen

Verwenden Sie den Windows-Befehl CERTUTIL -viewstore -enterprise NTAuth Zur Fehlerbehebung bei Smartcard-Anmeldungen. Der lokale NTAuth-Speicher ist das Ergebnis des letzten Downloads von Gruppenrichtlinien aus dem Active Directory-NTAuth-Speicher. Dies ist der Speicher, der von der Smartcard-Anmeldung verwendet wird. Daher kann das Anzeigen dieses Speichers hilfreich sein, um Fehler bei der Smartcard-Anmeldung zu beheben.

Außerbetriebnahme eines PKI-Baums

Wenn Sie zwei PKI-Bäume bereitstellen, um den Legacy-Baum irgendwann außer Betrieb zu setzen (wenn alle alten Geräte veraltet oder aktualisiert wurden), empfiehlt es sich möglicherweise, das Feld CRL Next Update auf Null zu setzen. Dies wird (sollte?) Die kontinuierliche Abfrage nach neuen CRLS an die Clients verhindern. Der Grund dafür ist, dass nach der Außerbetriebnahme der PKI keine Verwaltung mehr und keine widerrufenen Zertifikate mehr erfolgen. Alle verbleibenden Zertifikate verfallen einfach.

Weitere Informationen zur Stilllegung von PKI finden Sie hier

39

AD CS-spezifische Befehle

Dies ist eine Liste von Befehlen, die für die Konfiguration eines Windows 2008 R2-CA-Servers relevant sind. Ich habe sie aus dem anderen Beitrag entfernt, da diese Informationen zu lang wurden und nicht alle Befehle direkt mit dem Einrichten einer Zertifizierungsstelle zusammenhängen.

Dies ist eher der Abschnitt Wie, eher das "Was und Warum". Es enthält auch versionenspezifische Unterschiede zwischen CA-Versionen (2000 gegenüber 2003, gegenüber 2008).


Listen Sie auf, welche Registrierungsrichtlinien Flags bearbeiten

Einige Anforderungen vom Client werden möglicherweise automatisch entfernt basierend auf diesen versteckten Servereinstellungen.

C:\Users\ChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:\Windows\system32\CertLog
  DBLogDirectory           REG_SZ = C:\Windows\system32\CertLog
  DBTempDirectory          REG_SZ = C:\Windows\system32\CertLog
  DBSystemDirectory        REG_SZ = C:\Windows\system32\CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:\Users\ChrisLamont>certutil -getreg policy\editflags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

Die Lösung besteht darin, den Befehl certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE Auszuführen, der wiederum aktualisiert wird

     Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

So definieren Sie eine Richtlinie pro CA

Geben Sie die folgenden Befehle an einer Eingabeaufforderung ein, um eine Richtlinie in ausgestellte Zertifikate aufzunehmen:

 certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

Sie können die Einstellung mit deaktivieren

  certutil -v -setreg policy\EnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

So definieren Sie die Dauer des OCSP-Cache

Mit den folgenden Befehlen können Sie die Max-Age-Headereinstellung festlegen, ändern und löschen.

  appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']

Anzeigen der aktuellen benutzerdefinierten httpProtocol-Header

  appcmd list config /section:httpProtocol

So importieren Sie Offline-CA-Zertifikate in AD

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

So aktivieren Sie PKCS # 1 v1.21

Dies ist aktiviert, wenn die Datei CAPolicy.inf AlternateSignatureAlgorithm=1 Hat. Achten Sie auf Kompatibilitätsprobleme.

Schließlich sollte man wissen, dass die Installation von AD Certificate Services nicht so einfach ist wie das Hinzufügen der Rolle. Sie sollten dies überprüfen VBS-Installationsskript und sicherstellen, dass die Datei CAPolicy.inf nach Bedarf für Ihre Umgebung bearbeitet wird

So definieren Sie einen Cross Certificate Distribution Point

Windows AD-Zertifikatdienste aktivieren dies in der Datei CAPolicy.info mit dem Eintrag [CrossCertificateDistributionPointsExtension]

Sonstiges: AIA-Unterschiede beim Upgrade von Windows 2000 CA auf Windows 2003

Beachten Sie, dass sich das Verhalten zwischen Windows 2000- und 2003-Zertifizierungsstellen ändert. Die AKI-Erweiterung von Zertifikaten, die von Windows-Zertifizierungsstellen ausgestellt wurden, unterscheidet sich zwischen Windows 2000 und Windows Server 2003. Standardmäßig werden die folgenden Informationen in der AIA-Erweiterung von ausgestellten Zertifikaten gespeichert.

  • Windows 2000 Die AIA-Erweiterung der von der Zertifizierungsstelle ausgestellten Zertifikate umfasst den LDAP-DN der ausstellenden Zertifizierungsstelle (Ausstellername), die Seriennummer des Zertifikats der ausstellenden Zertifizierungsstelle und den Schlüssel-Hash des öffentlichen Schlüssels des Zertifizierungsstellenzertifikats.

  • Windows Server 2003 Die AIA-Erweiterung der von der Zertifizierungsstelle ausgestellten Zertifikate enthält nur einen Hash des öffentlichen Schlüssels der ausstellenden Zertifizierungsstelle, auch als Schlüssel-ID bezeichnet.

Die Verhaltensänderung ist auf Verkettungsfehler zurückzuführen, die auftreten können, wenn das Zertifikat einer Zertifizierungsstelle erneuert wird. Das standardmäßige Windows 2000-Verhalten kann zu unvollständigen Ketten führen, wenn das zum Signieren des ausgestellten Zertifikats verwendete CA-Zertifikat dem Client nicht zur Verfügung steht. Wenn beim Standardverhalten von Windows Server 2003 die Zertifizierungsstelle mit demselben Schlüsselpaar erneuert wurde, kann jedes Zertifizierungsstellenzertifikat für die ausstellende Zertifizierungsstelle, die dasselbe Schlüsselpaar verwendet, in die Zertifikatkette aufgenommen werden.

Sie können das alte Verhalten nachahmen, indem Sie diesen Befehl ausführen

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Zertifikate in AD auflisten

Dieser Befehl listet die in Active Directory veröffentlichten Zertifikate auf.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

ISIS MTT v1.1 PKI-Kompatibilität

Siehe dies KB-Artikel für Prozeduren , auch hier ist eine alternative CAPolicy.inf-Methode für ISIS MTT v1.1

4

ein Punkt auf der Checkliste wird oft übersehen:

  • BACKUPS
  • BACKUPS
  • BACKUPS

insb. Wenn Sie eine Zertifizierungsstelle implementieren.

Bei meiner vorherigen Antwort ist mir der Platz ausgegangen, aber ich denke, dies sind gültige und nützliche Informationen:

Widerruf

In den nächsten Abschnitten werden CRL und Zertifikate erläutert. Bevor Sie jedoch zu weit gehen, möchte ich Sie auf ein Problem aufmerksam machen, das sich auf die Produktion und die PKI-Vorgänge auswirken kann: Wenn Sie der Meinung sind, dass Ihre PKI das gleiche Zertifikat mit Microsoft PKI (Active Directory-Zertifikat) widerruft Services), dann ist das Widerrufsdatum das Datum des zweiten Widerrufs, nicht das erste. Wenn Sie jedoch Zertifikate auf Smartcards mit dem Microsoft-Produkt FIM CM (Forefront Identity Management - Zertifikatverwaltung) verwalten, werden Sie solche doppelten Widerrufe vornehmen. Quelle

1