Windows Certificate Store / Windows Zertifikatsspeicher

Die Windows Zertifikatsverwaltung besteht aus einem logischen und einem physischen
Teil. Der logische Teil ist das operative Management über die GUI oder Certutil.exe
jeweils für den Benutzer, den Computer und einzelne Dienste –  der physische Teil
beschäftigt sich mit der sicheren Ablage von Zertifikaten und Schlüsseln.

  • Crypto API: Führt alle kryptografischen Vorgänge durch, ab Server 2008 durch
    Cryptography Next Generation (CNG) ersetzt
  • Cryptographic Service Provider (CSP): Software/Hardware die kryptografische Algorithmen zur Verschlüsselung/Entschlüsselung einsetzt.
  • Logical Personal Store Layer:
    • Eigene Zertifikate (Personal Store): Hier sollten die Zertifikate, die sich auf den Anwender/PC beziehen, abgelegt werden – die zugehörigen privaten Schlüssel befinden sich im Benutzerprofil bzw. auf einer Smartcard/Token.
    • Vertrauenswürdige Stammzertifizierungsstellen (Trusted Root CertificationAuthorities): Hier sollten sich nur CA Zertifikate vertrauenswürdiger Zertifizierungsstellen (in der Regel RootCA Zertifikate) befinden. Allen hier aufgeführten Zertifikate und ihren ausgestellten Zertifikaten wird als Trust Anchor automatisch vertraut.
    • Organisationsvertrauen (Enterprise Trust): Hier befinden sich Certificate TrustLists (Liste von self-signed Zertifikaten die von einer Root signiert wurden), die über Gruppenrichtlinien bezogen werden können. Wenn die CA, die die Liste signiert hatte, die Gültigkeitsprüfung besteht, so gelten alle in der Liste enthaltenen CA Zertifikate als Trust Anchor.
    • Zwischenzertifizierungsstellen (Intermediate CAs): Enthält die CA Zertifikate von Intermediate CAs, sowie deren Sperrlisten (CRLs) – sie gelten nicht als TrustAnchor.
    •  Active Directory Benutzerobjekt (Active Directory User Object):  Enthält alle Zertifikate des Benutzers die in Active Directory veröffentlicht wurden
    • Vertrauenswürdige Herausgeber (Trusted Publishers): Enthält CodesignaturZertifikate denen automatisch ohne eine Warnmeldung vertraut wird.
    • Nicht vertrauenswürdige Zertifikate (Untrusted Certificates):  Hier befindensich Zertifikate, denen niemals vertraut werden soll. Microsoft verwendet diesenOrdner, um mit Windows Update CA Zertifikate bekannt zu machen, deren Sicherheit kompromittiert wurde. Dies ist nötig, da Root Zertifikate nicht direkt gesperrt werden können. Hier befinden sich auch die gehackten DigiNotar Zertifikate.
    • Drittanbieter-Stammzertifizierungsstellen (Third-Party Root Certification Authorities): Hier sollten nur Drittanbieter Root Zertifikate und CRLs aufgenommen werden. Diese können je nach Gruppenrichtlinieneinstellungen als Trust Anchors definiert werden.
    • Vertrauenswürdige Personen (Trusted People): Explizites Vertrauen bestimmter Endanwender bzw. selbstsignierter Zertifikate als Trust Anchors. Wird z.B. für S/MIME in Outlook verwendet, wenn einem bestimmten Kontakt unabhängig von seiner PKI Struktur direkt vertraut werden soll.
    • Andere Personen (Other People): Ablage für Zertifikate fremder Endentitäten, die sich zu einer Trusted Root verketten.
    • Zertifikatregistrierungsanforderungen (Certificate Enrollment Requests):Enthält Certificate Request Dateien für die manuelle Zertifikatsanfrage.
    • Smartcard vertrauenswürdige Stämme (Smart Card Trusted Roots):Hier befinden sich die Trusted Root CAs einer Smartcard, wenn die Karte eingelegt wird.

    Logical Layer Windows Zertifikatsverwaltung öffnen:
    MMC – Datei – SnapIn hinzufügen – Zertifikate – hinzufügen – Eigenes Benutzerkonto bzw. Computerkonto wählen

  • Physical Store Layer eines Benutzers/Computers/Dienste
  • Jeder Ordner im Logical Store kann wiederum physisch in Ablage-Container unterteilt werden:
    • Registrierung (Registry): Benutzerspezifischer Teil der Computerregistry, also Teil des Benutzerprofils. Hier werden die logischen Zertifikate eines Benutzers abgelegt. Alle Zertifikate die physisch im Benutzerprofil vorhanden sind, können dann automatisch auf andere PCs mitgenommen werden, falls ein Roaming Profile eingerichtet wurde.
      Pfad ab Vista/Server 2008: %Systemdrive%\Users\username\AppData\Roaming\Microsoft\SystemCertificates\My
    • Lokaler Computer (Local Computer): Die hier abgelegten Zertifikate beziehen sich auf alle Benutzer die sich am Computer anmelden. Pfad: HKLM\software\Microsoft\systemcertificates\my
    • Gruppenrichtlinie: Hier werden Zertifikate abgelegt, die über Gruppenrichtlinien verteilt werden.
      Machine Registry: HKLM\software\policies\Microsoft\systemcertificates
      User Registry: HKCU\software\policies\Microsoft\usercertificates
    • Benutzerzertifikat (User Certificate): Hier sind die Zertifikate abgelegt, die in Active Directory im Bezug zum Benutzerkonto veröffentlicht wurden (LDAP Pointer)
    • Unternehmen (Enterprise): Root CAs, die bei der Installation innerhalb einer Active Directory Struktur im Verzeichnisdienst registriert wurden
      HKLM\software\Microsoft\enterprisecertificates

    Physikalischer Zertifikatsspeicher in Windows: MMC – SnapIn hinzufügen – Zertifikate – Ansicht – Optionen – Physikalischer Zertifikatspeicher anhaken

    Physikalischer Zertifikatsspeicher in Windows

    Physikalischer Zertifikatsspeicher

Literatur:
Vgl. De Clercq, Jan.: „Windows Server 2003 Security Infrastructures“, K. 13.4.4. Windows Server 2003 Security Infrastructures

Dieser Beitrag wurde unter PKI: Anwendungen und Applikationen, PKI: Komponenten und Prozesse veröffentlicht. Setze ein Lesezeichen auf den Permalink.

8 Antworten auf Windows Certificate Store / Windows Zertifikatsspeicher

  1. Matthias sagt:

    Vielen Dank. Kennst du dich auch etwas mit dem Zugriff von Java auf die Windows Keystores aus?

    Ich habe eine Java Anwendung mit der ich auf ALLE Zertifikate auf dem PC zugreifen will (auslesen). Allerdings kann Java von Haus aus mittels SunMSCAPI nur auf die Keystores Windows-My (Eigene Zertifikate) und Windows-Root (Vertrauenswürdige Stammzertifizierungsstellen) zugreifen. Ich müsste aber wie gesagt auch auf die anderen zugreifen können. Hast du da ne Ahnung?

    Habe noch den BouncyCastle Provider gefunden. Allerdings sieht es da auch nicht danach aus, das ich auf alle Keystores zugreifen kann.

    Mit C# geht das soweit ich das gesehen habe. Dort kann man wenn ich es richtig gesehen habe auf alle Keystore zugreifen.

    Wie sieht das mit den Speicherorten der Zertifikate von oben aus. Sind die Orte für alle Windows Versionen (ab XP) gleich oder gibt es da auch Unterschiede? Kann ich die einzelnen verschlüsselten Zertifikate mit Java einlesen (z.B. %Systemdrive%\Users\username\AppData\Roaming\Microsoft\SystemCertificates\My) die liegen ja nicht im Klartext vor.

    Und hast du noch andere empfehlenwerte Bücher dazu? Außer dem von dir oben angegebenen?

    Hast du auch Ahnung wo die ganzen Zertifikate unter Unix liegen? Da gibt es eine solches Tool wie certmgr.msc nicht. Ich habe gesehen, das Zertifikate unter /etc/ssl/ liegen, aber sind das alle?

    Ich hoffe du kannst mir etwas weiterhelfen. Vielen Dank! 🙂

    • lkl-it sagt:

      Hallo,

      Zertifikate haben leider unter Unix keinen festen „Store“ – sie liegen oft als Base64 TextFiles im Filesystem oder eben auch in Java Keystores.
      Die Windows Speicherorte unterscheiden sich bei XP/Win2k (%SystemDrive%\Documents and Settings\\ApplicationData\Microsoft\SystemCertificates\My\Certificates) zu den höheren Versionen – auch vom Typ (vom CSP zu KSP) – dann aber nicht mehr.
      Die Windows Keystores sind mit einem Masterkey verschlüsselt, der wiederum schlußendlich mit dem Passwort des eigentlichen Benutzers verschlüsselt ist – ohne das PW jedes Nutzers wirst du die Keystores nicht auslesen können.
      Alle Ablageorte findest du auch hier:
      http://msdn.microsoft.com/en-us/library/windows/desktop/bb204778%28v=vs.85%29.aspx

      Im Detail kann ich dir beim Auslesen der Einzelstores (mit PWs) nicht helfen aber eine Buchempfehlung für Java geben:
      Beginning Cryptography with Java
      von David Hook – das ist zwar schon etwas älter vermittelt aber viele interessante Grundlagen.

      Freue mich auf Rückmeldung

  2. Matthias sagt:

    Vielen Dank für die Rückmeldung.

    Das bringt mich doch schon ein bisschen weiter. Hast du auch noch eine Empfehlung als Lektüre bzgl. „Die Windows Keystores sind mit einem Masterkey verschlüsselt, der wiederum schlußendlich mit dem Passwort des eigentlichen Benutzers verschlüsselt ist“. Ein Buch o.Ä. wo auf diese Thematik eingegangen wird?

    Okay dann fällt das Dateiweise einlesen der Windows Zertifikate flach, wenn diese mit Masterkey + User PW verschlüsselt sind. Mit dem Java Zugriff mittels: KeyStore ks = KeyStore.getInstance(„Windows-MY“); und KeyStore ks = KeyStore.getInstance(„Windows-Root“); kann ich zur Laufzeit zugreifen auf die 2 Keystores. Nur wie gesagt, muss ich an die restlichen Keystores auch dran.

    Dann muss ich mir das Buch mal besorgen und schauen ob mich das weiterbringt.

    Wenn du sonst noch was an Litertaur hast, wäre ich dir sehr dankbar.

  3. Matthias sagt:

    Dank Dir. Da Schau ich doch gleich mal rein. Wie ich sehe ist dieses Buch wohl sehr empfehlenswert: Windows Server 2003 Security Infrastructures zusammen mit dem Java Security Buch. Muss ich mal beide besorgen.

    Vielen Dank für deine Hilfe! 🙂

  4. Matthias sagt:

    Ich nochmal.

    Sind die Zertifikate die in der Registry gespeichert sind bzw. die auf der Festplatte (users/name/raoming/ms/…) auch zur Laufzeit verschlüsselt? d.h. wenn ich angemeldet bin? Habe mal versucht diese zu öffnen bzw. zu lesen. Einige Stellen kann man lesen ander sind mit cryptischen Zeichen belegt. Daher die Frage ob diese zur Laufzeit verschlüsselt sind oder nur irgendwie codiert gespeichert wurden?

    Diese müsste ich ja dann mit dem Symmetric Session Key entschlüsseln können theoretisch oder?

    • lkl-it sagt:

      Hallo – wenn du mit deinem User angemeldet bist kannst du natürlich auf deine Schlüssel und Zertifikat zugreifen. Dabei wirst du auch nicht mehr nach einem Passwort gefragt. Jegliche Applikation die im Kontext deines Benutzers läuft kann ebenfalls zur Laufzeit darauf zugreifen. Um dies zu verhindern gibt es die – Strong Private Key Protection – hier muss zusätzlich noch jedes Mal wenn ein Private Key verwendet werden soll ein Password oder zumindest eine Bestätigung eingegeben werden.
      Im Detail ist das alles hier erklärt:
      http://msdn.microsoft.com/en-us/library/ms995355.aspx

  5. Matthias sagt:

    ah ne habe es überlesen. Das dürfte mit der DPAPI gehen. Dort hab ich ja Zugriff auf die Encrypt()-Funktion.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.