Windows-Zertifikatspeicher in der Praxis — Benutzer oder Computer, wofür entscheiden Sie sich?

„Beim Wechsel des Terminals für die Online-Anspruchsprüfung haben wir das Client-Zertifikat auf den neuen PC übertragen, und jetzt kommt keine Verbindung mehr zustande.“ „Auf dem Entwicklungsrechner erreichen wir die Bank-API problemlos, aber sobald es ein Windows-Dienst wurde, heißt es ‚Zertifikat nicht gefunden‘.“ „Ich weiß nicht einmal, welches Zertifikat das echte ist — das, das certmgr.msc zeigt, oder das, das certlm.msc zeigt.“ — wenn man Web-API-Anbindungen mit Client-Zertifikaten im Auftrag entwickelt, kommt diese Art von Frage regelmäßig auf.

Online-Anspruchsprüfung im Gesundheitswesen, elektronische Anträge, Bank-APIs, EDI mit Geschäftspartnern. Client-Zertifikate, früher das Revier der Infrastrukturabteilungen großer Konzerne, werden heute von IT-Verantwortlichen und Fachanwendungsentwicklern in kleinen und mittleren Unternehmen selbst gehandhabt. Und Vorfälle rund um Zertifikate lassen sich tatsächlich auf eine Handvoll Muster reduzieren: den falschen Speicher wählen, die Berechtigung für den privaten Schlüssel vergessen und den Ablauf vergessen — diese drei.

Dieser Artikel richtet sich an Entwickler von Fachanwendungen, die Client-Zertifikate verwenden, sowie an IT-Verantwortliche, denen der Austausch von Zertifikaten übertragen wird. Im Zentrum steht die Entscheidung „Benutzerspeicher oder Computerspeicher“, ausgehend davon arbeiten wir die Struktur des Windows-Zertifikatspeichers, die Vergabe von Berechtigungen für private Schlüssel, die Bestandsaufnahme ablaufender Zertifikate mit PowerShell und den Verwendungscode aus .NET in einem Zug durch. Die Inhalte basieren auf Primärquellen von Microsoft Learn mit Stand August 2026.

1. Das Wichtigste zuerst

• Der Windows-Zertifikatspeicher besteht aus zwei Systemen: „Benutzer“ (CurrentUser) und „Computer“ (LocalMachine). Der Benutzerspeicher ist pro Konto separat (unter HKEY_CURRENT_USER in der Registry), der Computerspeicher ist für den gesamten PC gemeinsam (unter HKEY_LOCAL_MACHINE).¹²
• Es gibt auch zwei Verwaltungswerkzeuge. certmgr.msc öffnet den Speicher des aktuellen Benutzers, certlm.msc den des lokalen Computers. Aus PowerShell heraus sind das Cert:\CurrentUser und Cert:\LocalMachine.³⁴
• Welcher Speicher gewählt wird, entscheidet sich danach, „unter wessen Konto das Programm läuft, das das Zertifikat verwendet“. Für eine interaktive Anwendung gilt in der Regel der Benutzerspeicher, für unbeaufsichtigte Ausführung — Windows-Dienst, IIS, Aufgabenplanung — der Computerspeicher (Entscheidungstabelle in Kapitel 3).
• „Es funktionierte während der Entwicklung, wurde aber als Dienst nicht mehr gefunden“ hat fast immer eine Ursache. Ein Zertifikat, das ein Entwickler in seinen eigenen Benutzerspeicher gelegt hat, ist vom CurrentUser eines unter einem anderen Konto laufenden Dienstes aus unsichtbar (Kapitel 3).
• Ein Zertifikat und sein privater Schlüssel sind zwei verschiedene Dinge. Ein Zertifikat lediglich in den Computerspeicher zu legen bedeutet noch nicht, dass das Dienstkonto den privaten Schlüssel lesen kann — das ist der Normalfall. Gewähren Sie dem Ausführungskonto über „Privaten Schlüssel verwalten“ in certlm.msc Lesezugriff.⁵
• Beim Import einer pfx ist der private Schlüssel standardmäßig nicht exportierbar. Import-PfxCertificate importiert den privaten Schlüssel in einer Form, die sich nicht erneut exportieren lässt, sofern Sie nicht -Exportable angeben. Das ist kein Fehler, sondern der gewünschte Standardwert.⁶
• Den Ablauf verhindern Sie durch eine automatisierte Bestandsaufnahme. Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 60 extrahiert maschinell Zertifikate, die innerhalb der angegebenen Anzahl an Tagen ablaufen.⁴
• Einen Fingerabdruck fest in Code oder Konfiguration einzubetten, bringt Sie bei jeder Zertifikatserneuerung in Schwierigkeiten, weil sich der Fingerabdruck eines neuen Zertifikats immer ändert. Ihn in die Konfiguration auszulagern, kombiniert mit einer Übergangsphase mit altem und neuem Zertifikat, ist die grundlegende Bauweise (Kapitel 5 und 7).

2. Der Gesamtüberblick über Zertifikatspeicher — zwei Orte und logische Speicher

2.1. Zwei Systeme: Benutzer und Computer

Der Windows-Zertifikatspeicher gliedert sich grob in zwei „Orte“.¹

• Der Zertifikatspeicher des Computers (lokaler Computer, LocalMachine): Es gibt ihn einmal pro PC, und er ist für alle Benutzer und Dienste auf diesem PC gemeinsam. Er liegt physisch unter dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates.²
• Der Zertifikatspeicher des Benutzers (aktueller Benutzer, CurrentUser): Dieser ist für jedes Benutzerkonto separat. Er liegt physisch unter HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, also als Teil des Benutzerprofils.²

Daneben gibt es auch einen Speicher pro Dienstkonto,³ der physisch unter einem Registrierungsschlüssel pro Dienstname liegt.² Für die Praxis sind zunächst die beiden oben genannten Orte entscheidend.

Ein wichtiges Verhalten ist zu beachten. Jeder logische Speicher im Benutzerspeicher erbt — mit Ausnahme von „Eigene Zertifikate“ — den Inhalt des gleichnamigen Speichers im Computerspeicher und zeigt ihn an.¹ Fügen Sie beispielsweise das Zertifikat einer internen Zertifizierungsstelle den „Vertrauenswürdigen Stammzertifizierungsstellen“ des Computerspeichers hinzu, erscheint es auch in den „Vertrauenswürdigen Stammzertifizierungsstellen“ jedes Benutzers. Umgekehrt gilt: Nur der Speicher „Eigene Zertifikate“ wird nicht geerbt, sodass Sie bei einem Client-Zertifikat — das gehört in den Speicher „Eigene Zertifikate“ — selbst entscheiden müssen, „wer es sehen können muss“. Diese Asymmetrie ist der eigentliche Dreh- und Angelpunkt dieses gesamten Artikels.

flowchart TB
    subgraph LM["Computer (LocalMachine)<br/>Einmal pro PC, gemeinsam für alle Benutzer und Dienste"]
        LMMY["Eigene Zertifikate (My)"]
        LMROOT["Vertrauenswürdige Stammzertifizierungsstellen (Root)"]
        LMCA["Zwischenzertifizierungsstellen (CA)"]
        LMTP["Vertrauenswürdige Herausgeber (TrustedPublisher)"]
    end
    subgraph CU["Benutzer (CurrentUser)<br/>Für jedes Konto separat"]
        CUMY["Eigene Zertifikate (My)<br/>*Nicht geerbt = Sie entscheiden selbst, wo Sie ablegen"]
        CUROOT["Vertrauenswürdige Stammzertifizierungsstellen (Root)"]
        CUCA["Zwischenzertifizierungsstellen (CA)"]
        CUTP["Vertrauenswürdige Herausgeber (TrustedPublisher)"]
    end
    LMROOT -.->|"Inhalt wird geerbt angezeigt"| CUROOT
    LMCA -.->|"Geerbt"| CUCA
    LMTP -.->|"Geerbt"| CUTP

2.2. Die wichtigsten logischen Speicher

Innerhalb jedes Orts ist der Inhalt in nach Rolle getrennte logische Speicher unterteilt. Das sind die Ordner, die Sie in certmgr.msc / certlm.msc sehen; aus PowerShell oder der Befehlszeile heraus verwenden Sie die englischen internen Namen.²⁴

2.3. Drei Fenster auf dieselben Daten — certmgr.msc / certlm.msc / das Cert:-Laufwerk

Es gibt drei Wege, dieselben Speicher zu betrachten.³⁴

• certmgr.msc: eine Verwaltungskonsole, die den Speicher des aktuellen Benutzers öffnet.
• certlm.msc: eine Verwaltungskonsole, die den Speicher des lokalen Computers öffnet.
• Das PowerShell-Laufwerk Cert:: erlaubt es, die Hierarchien Cert:\CurrentUser\... und Cert:\LocalMachine\... wie ein Dateisystem zu behandeln. Zertifikate werden über den Fingerabdruck identifiziert.

Wenn Sie das Zertifikat-Snap-In manuell zu mmc.exe hinzufügen, wählen Sie das Ziel aus drei Arten: „Eigenes Benutzerkonto“, „Computerkonto“ und „Dienstkonto“. Ein Benutzer ohne Administratorrechte kann nur den Speicher seines eigenen Benutzerkontos verwalten.³

Der erste Schritt jeder Fehlersuche besteht darin, abzugleichen, „welchen Speicher die Anwendung betrachtet“ und „welchen Speicher Sie selbst betrachten“. certmgr.msc anzustarren, während Sie einen Dienstfehler untersuchen, führt nie zu einer Antwort, weil Sie am falschen Ort suchen.

3. Wofür entscheiden Sie sich — eine Entscheidungstabelle nach Ausführungsform des Programms

Es gibt nur ein Kriterium: Unter wessen Konto läuft das Programm, das das Zertifikat verwendet?

Im Zweifel gilt: Unbeaufsichtigt laufende Programme nutzen den Computerspeicher, von Menschen bediente Programme den Benutzerspeicher.

3.1. Anatomie des klassischen Fehlers — „Es funktionierte während der Entwicklung, wurde aber als Dienst nicht mehr gefunden“

Dieser Fehler lässt sich mit folgender Schrittfolge exakt reproduzieren.

1. Ein Entwickler importiert eine pfx auf seinem eigenen PC per Doppelklick. Der Assistent verwendet standardmäßig „Aktueller Benutzer“, sodass das Zertifikat in den Benutzerspeicher des Entwicklerkontos gelangt.
2. Die Anwendung läuft während der Entwicklung aus Visual Studio heraus, also unter dem Entwicklerkonto, weshalb StoreLocation.CurrentUser das Zertifikat findet. Es funktioniert.
3. Sie wird auf dem Produktionsserver als Windows-Dienst registriert. Der Dienst läuft unter NETWORK SERVICE oder einem dedizierten Konto.
4. Das CurrentUser, das der Code des Dienstes öffnet, ist der Benutzerspeicher des Ausführungskontos des Dienstes. Der ist leer. „Zertifikat nicht gefunden.“

flowchart TB
    subgraph DEV["Entwicklungsrechner"]
        D1["pfx per Doppelklick importieren<br/>Assistent verwendet standardmäßig „Aktueller Benutzer“"] --> D2["Landet im Benutzerspeicher<br/>des Entwicklerkontos"]
        D2 --> D3["Ausführung aus Visual Studio<br/>= läuft unter dem Entwicklerkonto"]
        D3 --> D4["CurrentUser öffnen findet es<br/>→ funktioniert"]
    end
    subgraph PROD["Produktionsserver"]
        P1["Als Windows-Dienst registriert<br/>Ausführungskonto z. B. NETWORK SERVICE"] --> P2["Das vom Code geöffnete CurrentUser ist<br/>der Benutzerspeicher des Dienstkontos"]
        P2 --> P3["Der ist leer<br/>→ „Zertifikat nicht gefunden“"]
    end
    D4 -.->|"Gleiches Programm bereitgestellt"| P1

Der entscheidende Punkt ist, dass der Benutzerspeicher „so oft existiert wie es Konten gibt“. Öffnet ein Administrator certmgr.msc und sagt „es ist doch eindeutig vorhanden?“, betrachtet er nur seinen eigenen Speicher, nicht den des Dienstkontos. Die Abhilfe ist keine improvisierte Kopie, sondern erneut in den Computerspeicher importieren und den Code auf StoreLocation.LocalMachine ausrichten. Und das ist zusammen mit der im nächsten Kapitel behandelten Berechtigungsvergabe eine einzige zusammengehörige Aufgabe.

4. Private Schlüssel und Zugriffsrechte — der zweite klassische Fehler

4.1. Ein Zertifikat und sein privater Schlüssel sind zwei verschiedene Dinge

Was in der Liste des Zertifikatspeichers zu sehen ist, ist das Zertifikat (öffentliche Information), nicht der private Schlüssel selbst. Was die Client-Authentifizierung tatsächlich benötigt, ist eine Signaturoperation mit dem privaten Schlüssel, sodass „in der Liste sichtbar“ und „nutzbar“ zwei verschiedene Fragen sind. Wer das verwechselt, bekommt schwer zu diagnostizierende Störungen wie „das Zertifikat ist da, aber der TLS-Handshake schlägt fehl“ oder „es kommt ein unklarer Access-Denied-Fehler“.

4.2. Der pfx-Import in der Praxis — Exportierbarkeit ist eine Entscheidung

Ein Zertifikat samt privatem Schlüssel wird als pfx-Datei (PKCS #12) übergeben und lässt sich mit Import-PfxCertificate in den Speicher importieren.⁶

$pwd = Get-Credential -UserName '(Passwort unten eingeben)' -Message 'PFX-Passwort'
Import-PfxCertificate -FilePath C:\certs\client.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd.Password

Wichtig ist hier das Standardverhalten: Solange Sie nicht -Exportable angeben, lässt sich der importierte private Schlüssel nicht erneut exportieren.⁶ Alles „für den Fall einer späteren Migration“ als exportierbar zu importieren, schafft einen zusätzlichen Weg, über den der private Schlüssel abfließen kann. Bewahren Sie die ursprüngliche pfx sicher auf und behandeln Sie den privaten Schlüssel im Speicher grundsätzlich als nicht exportierbar — das ist unsere Empfehlung. Zu beachten ist, dass gerade die Aufbewahrung der ursprünglichen pfx und ihres Passworts dazu neigt, im Klartext liegen zu bleiben. Die Überlegungen dazu haben wir in „Vertrauliche Daten in Windows-Anwendungen speichern — Klartextkonfiguration mit DPAPI vermeiden“ und „Anmeldeinformationen in PowerShell sicher handhaben“ zusammengestellt.

4.3. Berechtigungen für den privaten Schlüssel an ein Dienstkonto vergeben

Der private Schlüssel eines im Computerspeicher abgelegten Zertifikats ist standardmäßig normalerweise nur für Administratoren und SYSTEM lesbar. Ein unter LocalSystem laufender Dienst kann den privaten Schlüssel deshalb ohne weiteres Zutun lesen; läuft der Dienst dagegen unter einem anderen Konto — NETWORK SERVICE, einem dedizierten Dienstkonto, der Identität eines IIS-Anwendungspools und so weiter —, müssen Sie diesem Ausführungskonto explizit Lesezugriff gewähren. Die Schritte erfolgen über die Benutzeroberfläche des Zertifikat-Snap-Ins.⁵

1. certlm.msc öffnen (oder das auf das Computerkonto ausgerichtete Zertifikat-Snap-In).
2. Unter „Eigene Zertifikate“ → „Zertifikate“ das betreffende Zertifikat mit der rechten Maustaste anklicken und über „Alle Aufgaben“ „Privaten Schlüssel verwalten“ öffnen.
3. Auf der Registerkarte „Sicherheit“ das Ausführungskonto (NETWORK SERVICE, dediziertes Dienstkonto, IIS-Anwendungspool-Identität usw.) hinzufügen und „Lesen“ erlauben.⁵

Vollzugriff ist nicht nötig. Wird der Schlüssel nur zum Signieren verwendet, genügt Lesen. Umgekehrt: Everyone Vollzugriff zu gewähren, nur weil „es sonst nicht funktioniert“, setzt den privaten Schlüssel auf das Sicherheitsniveau eines Klartextpassworts herab — vermeiden Sie das unbedingt. Die Ablage im Computerspeicher und die Vergabe der Berechtigung für den privaten Schlüssel sind stets eine einzige zusammengehörige Aufgabe — allein das in einem Handbuch festzuhalten, beseitigt diese ganze Fehlerklasse.

5. Ablaufvorfälle vermeiden — Bestandsaufnahme, Austausch und Verzeichnis

5.1. Bestandsaufnahme mit PowerShell

Das Ablaufdatum eines Zertifikats steht in der Eigenschaft NotAfter. Get-ChildItem gegen das Cert:-Laufwerk erlaubt eine maschinelle Bestandsaufnahme.⁴

# "Eigene Zertifikate" des Computerspeichers nach Ablaufdatum sortiert auflisten
Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter |
    Format-Table Thumbprint, Subject, NotAfter

# Nur Zertifikate extrahieren, die innerhalb von 60 Tagen ablaufen (0 liefert bereits abgelaufene)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 60

-ExpiringInDays ist ein Parameter, der „Zertifikate, die innerhalb der angegebenen Anzahl an Tagen ablaufen“ zurückgibt; bei 0 werden bereits abgelaufene Zertifikate angezeigt.⁴ Machen Sie daraus eine monatliche geplante Aufgabe, die über alle Server läuft, und sammeln Sie das Ergebnis per E-Mail oder in einem Verzeichnis — schon das verhindert nahezu alle Vorfälle der Art „montagmorgens geht die Anspruchsprüfung wegen eines abgelaufenen Zertifikats nicht durch“.

5.2. Das Austauschverfahren — die Übergangsphase und die Fingerabdruck-Falle

Die Erneuerung eines Zertifikats bedeutet nicht „löschen und neu einspielen“, sondern „hinzufügen, dann umschalten, dann prüfen, dann löschen“.

1. Das neue Zertifikat (pfx) in denselben Speicher importieren. Weil der Fingerabdruck unterschiedlich ist, können altes und neues Zertifikat im selben Speicher koexistieren.
2. Die Berechtigung für den privaten Schlüssel des neuen Zertifikats vergeben (Kapitel 4). Das wird bei der Erneuerung am leichtesten vergessen. Die Berechtigung ist an den jeweiligen privaten Schlüssel gebunden, sodass Sie sie bei jedem Zertifikatswechsel neu vergeben müssen.
3. Eine gegebenenfalls erforderliche Vorregistrierung beim Gegenüber-System (bei APIs, die eine vorherige Zertifikatsregistrierung verlangen) zuerst erledigen, während der Betrieb mit dem alten Zertifikat weiterläuft, und so eine Übergangsphase sichern, in der beide Zertifikate akzeptiert werden. Schalten Sie zuerst um, kann die Gegenseite das neue Zertifikat ablehnen und den Produktionsverkehr stoppen.
4. Die Konfiguration der Anwendung auf das neue Zertifikat umstellen und die Funktion prüfen.
5. Nach ausreichender Zeit das alte Zertifikat löschen.

flowchart LR
    I["1. Neue pfx in denselben<br/>Speicher importieren (alt und neu koexistieren)"] --> P["2. Berechtigung für den privaten<br/>Schlüssel des neuen Zertifikats vergeben"]
    P --> R["3. Vorregistrierung beim Gegenüber<br/>(Betrieb läuft weiter mit dem alten Zertifikat)"]
    R --> SW["4. Fingerabdruck in der Konfiguration<br/>umstellen, umschalten, prüfen"]
    SW --> DEL["5. Nach der Übergangsphase<br/>das alte Zertifikat löschen"]

Die größte Falle dabei ist der in Konfigurationsdateien oder Code geschriebene Fingerabdruck. Der Fingerabdruck ist pro Zertifikat eindeutig und ändert sich daher bei jeder Erneuerung zwangsläufig. Verweist auch nur eine einzige Stelle noch auf den alten Fingerabdruck, kommt es zu „das Zertifikat wurde erneuert, aber die Verbindung klappt nicht“. Verlässlich ist es, in einem Verzeichnis zu führen, wo der Fingerabdruck überall referenziert wird (Anwendungskonfiguration, IIS-Bindungen, Skripte, Registrierungen beim Gegenüber).

5.3. Ein Zertifikatsverzeichnis anlegen

Ein Verzeichnis muss nicht aufwendig sein — ein einziges Excel-Blatt reicht zum Einstieg. Legen Sie mindestens Spalten für Verwendungszweck / Aussteller / Subject / Fingerabdruck / Ablageort (Servername plus Speicher) / Konten mit Berechtigung für den privaten Schlüssel / Ablaufdatum / Link zum Erneuerungsverfahren / Verantwortliche Person an und gleichen Sie das mit dem Ergebnis der Bestandsaufnahme aus 5.1 ab. Zertifikatsvorfälle sind in der Praxis kein technisches Problem, sondern das Problem, dass „niemand eine vollständige Liste hat“ — genau deshalb wirkt ein Verzeichnis am zuverlässigsten.

6. Prüfung und das Lesen von Fehlern — Kette und Stammzertifikatsverteilung

6.1. Grundlagen der Kettenprüfung und certutil

Fehler der Art „diesem Zertifikat wird nicht vertraut“ bedeuten, dass die Kette (der Zertifizierungspfad) vom Endzertifikat bis zur Stamm-CA irgendwo unterbrochen ist. Zur Eingrenzung ist certutil praktisch.⁷

flowchart TB
    LEAF["Endzertifikat<br/>(Client- oder Serverzertifikat)"] --> INT["Zwischen-CA-Zertifikat<br/>Ablageort: Speicher der Zwischenzertifizierungsstellen (CA)"]
    INT --> ROOT["Stamm-CA-Zertifikat<br/>Ablageort: Vertrauenswürdige Stammzertifizierungsstellen (Root)"]
    INT -.->|"nicht zu beschaffen<br/>(weder Präsentation noch AIA noch Speicher)"| E1["Kette kann nicht aufgebaut werden<br/>(klassische Ursache 1)"]
    ROOT -.->|"nicht verteilt"| E2["Fehler „Nicht vertrauenswürdig“<br/>(klassische Ursache 2)"]
    LEAF -.->|"abgelaufen"| E3["Fehler zur Gültigkeitsdauer<br/>(klassische Ursache 3)"]

:: Kette einer Zertifikatsdatei aufbauen und prüfen (inklusive Abruf der Sperrprüfungs-URL)
certutil -urlfetch -verify client.cer

:: Verwendet die Zielanwendung den Benutzerspeicher, mit -user im selben Kontext prüfen
certutil -user -urlfetch -verify client.cer

:: Inhalt eines Speichers ausgeben (mit -user den Benutzerspeicher)
certutil -store My
certutil -user -store My

certutil -verify prüft Zertifikat, CRL und Kette und baut, sofern keine CA-Zertifikatsdatei angegeben ist, eine vollständige Kette auf und prüft sie.⁷ Die Ausgabe ist lang, lässt aber erkennen, auf welcher Ebene das Vertrauen unterbrochen ist und ob sich Sperrinformationen abrufen ließen. Typische Ursachen sind: (1) Das Zwischen-CA-Zertifikat lässt sich nicht beschaffen (die TLS-Gegenstelle sendet es nicht, es lässt sich auch nicht über die AIA-Informationen des Zertifikats abrufen, und es liegt auch nicht im Speicher „Zwischenzertifizierungsstellen“); (2) der Stamm der internen Zertifizierungsstelle wurde nicht an „Vertrauenswürdige Stammzertifizierungsstellen“ verteilt; (3) das Zertifikat selbst ist abgelaufen. Da sich das Zwischen-CA-Zertifikat auch über die Präsentation durch die Gegenstelle oder den automatischen Abruf per AIA lösen lässt, betrachten Sie die Ablage im Speicher als „eine Möglichkeit, es sicherzustellen“, nicht als die einzige.

6.2. Interne CA und selbstsignierte Stammzertifikate über GPO/Intune verteilen

Nutzen Sie eine interne Zertifizierungsstelle oder ein selbstsigniertes Testzertifikat, müssen Sie dessen Stammzertifikat an jeden PC verteilen. Statt es einzeln von Hand einzuspielen, nutzen Sie einen Verteilmechanismus.

• Active-Directory-Umgebung (GPO): Importieren Sie das Zertifikat über die Gruppenrichtlinie unter Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies in „Vertrauenswürdige Stammzertifizierungsstellen“, wird es an die Ziel-PCs verteilt.⁸
• Intune-verwaltete Umgebung: Ein Profil „Vertrauenswürdiges Zertifikat“ verteilt das Stamm- oder Zwischen-CA-Zertifikat. Unter Windows lässt sich der Zielspeicher wählen (Computer-Stamm/-Zwischenzertifikate, Benutzer-Zwischenzertifikate).⁹

Wie in 2.1 erläutert, wird ein im Stamm des Computerspeichers abgelegtes Zertifikat von allen Benutzern als vertrauenswürdig eingestuft.¹ Genau deshalb sollten Sie auch das umgekehrte Risiko klar sehen. Ein selbstsigniertes Zertifikat in „Vertrauenswürdige Stammzertifizierungsstellen“ zu legen bedeutet, auf diesem PC einen neuen Vertrauensanker zu pflanzen. Gelangt dessen privater Schlüssel in falsche Hände, wird er zum Sprungbrett für Zertifikate, die eine beliebige Website oder Software vortäuschen. Für einen dauerhaften Betrieb ist es sinnvoller, entweder eine interne Zertifizierungsstelle mit angemessen geschütztem privatem Schlüssel aufzubauen oder auf ein Zertifikat einer öffentlichen Zertifizierungsstelle zu setzen — ein selbstsignierter Stamm gehört als Grundsatz „nur in Testumgebungen, mit befristeter Gültigkeit“.

7. Aus Entwicklersicht — den Speicher aus .NET korrekt verwenden

7.1. Mit X509Store nach dem Fingerabdruck suchen

Aus .NET heraus öffnen Sie einen Speicher mit X509Store und beziehen ein Zertifikat mit Find.¹⁰¹¹

using System.Security.Cryptography.X509Certificates;

static X509Certificate2 GetClientCertificate(string thumbprint)
{
    using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
    store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);

    var found = store.Certificates.Find(
        X509FindType.FindByThumbprint, thumbprint, validOnly: true);

    if (found.Count == 0)
        throw new InvalidOperationException(
            $"Zertifikat nicht gefunden: Fingerabdruck={thumbprint}, " +
            $"Speicherort={store.Location}\\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"Zertifikat vorhanden, aber kein privater Schlüssel zugeordnet " +
            $"(z. B. Import aus einer .cer-Datei): Fingerabdruck={thumbprint}, Speicherort={store.Location}\\{store.Name}");

    return cert;
}

Die Entscheidung aus Kapitel 3 setzt sich hier unmittelbar fort. Für Code, der in einem Dienst läuft, gilt StoreLocation.LocalMachine, für eine interaktive Anwendung StoreLocation.CurrentUser. Noch etwas verdient Beachtung: das dritte Argument von Find, validOnly. Bei true werden nur Zertifikate zurückgegeben, die die Validierung bestanden haben.¹¹ Das schützt davor, ein abgelaufenes Zertifikat zu erwischen, sorgt aber auch dafür, dass ein selbstsigniertes Testzertifikat mit nicht vertrauenswürdiger Kette in die Kategorie „nicht gefunden“ fällt — verdächtigen Sie also auch das, wenn etwas „vorhanden, aber nicht auffindbar“ ist. Sorgen Sie außerdem dafür, dass eine Fehlermeldung bei „nicht gefunden“ wie im obigen Beispiel immer angibt, welcher Speicher durchsucht wurde. Diese eine Angabe verändert die Untersuchungszeit eines Fehlers aus Kapitel 3 um eine Größenordnung.

7.2. Ein Client-Zertifikat an HttpClient anhängen

Das ermittelte Zertifikat fügen Sie HttpClientHandler.ClientCertificates hinzu und präsentieren es so dem Server. Diese Sammlung ist die Menge der Zertifikate, die bei einer zertifikatsbasierten Client-Authentifizierung dem Server präsentiert werden.¹²

var handler = new HttpClientHandler();
handler.ClientCertificates.Add(GetClientCertificate(thumbprint));

var client = new HttpClient(handler);
// Ab hier wie ein gewöhnliches HttpClient verwenden

Bei .NET Core ist in der Dokumentation ausdrücklich festgehalten, dass ein Zertifikat, sofern es ein Attribut für den Schlüsselverwendungszweck (Key Usage) trägt, nur dann zum Senden der Anfrage verwendet wird, wenn dieses „Digital Signature“ enthält.¹² Werden Sie einmal in die Lage versetzt, die Ausstellung eines Client-Zertifikats zu beantragen, teilen Sie den Verwendungszweck (Client-Authentifizierung) korrekt mit. Beachten Sie außerdem, dass HttpClient bei falscher Verwendung Socket-Erschöpfung oder Probleme beim Nachverfolgen von DNS-Änderungen verursachen kann; das Design mit langlebigem Handler behandeln wir in „HttpClient sollte nicht mit using umschlossen werden“.

7.3. Das Problem des fest codierten Fingerabdrucks, der beim Austausch versagt

Die Suche über den Fingerabdruck ist zuverlässig, aber wird der Fingerabdruck im Code fest verankert, erfordert jede Zertifikatserneuerung einen Build und ein Release. Die konstruktive Antwort besteht aus drei Stufen.

• Minimal: Den Fingerabdruck in eine Konfigurationsdatei (z. B. appsettings) auslagern, sodass sich der Austausch ohne Release durchführen lässt. Die Konfigurationsstelle im Verzeichnis aus 5.3 vermerken.
• Einen Schritt weiter: Nach Subject-Name oder Aussteller suchen, kombiniert mit validOnly: true, um „unter diesem Namen aktuell gültig, mit dem am weitesten in der Zukunft liegenden NotAfter“ auszuwählen. So wechselt die Anwendung während der Übergangsphase automatisch auf das neue Zertifikat. Da dabei das Risiko besteht, ein unbeabsichtigtes, gleichnamiges Zertifikat zu erwischen, kombinieren Sie das mit einer Prüfung des Ausstellers und einer Protokollierung. Beachten Sie außerdem, dass dieser automatische Wechsel nur funktioniert, wenn das Gegenüber keine Vorregistrierung des Zertifikats verlangt. Bei einer API, die eine Vorregistrierung benötigt (5.2), kann ein ungewollter Wechsel auf ein lediglich importiertes, aber nicht registriertes Zertifikat die Kommunikation zum Erliegen bringen — bleiben Sie in diesem Fall bei der ausgelagerten Konfigurationsvariante und wechseln Sie erst nach bestätigter Registrierung um.
• Betrieblich absichern: Protokollieren Sie unabhängig von der gewählten Methode beim Start, welches Zertifikat (Fingerabdruck und Ablaufdatum) ausgewählt wurde. Diese eine Protokollzeile zahlt sich sowohl bei der Störungssuche als auch beim Abgleich mit dem Verzeichnis aus.

8. Der Bezug zu Codesignatur-Zertifikaten — der Speicher „Vertrauenswürdige Herausgeber“

Bisher ging es um Zertifikate für die Kommunikation (TLS), doch der Zertifikatspeicher beherbergt noch eine zweite Welt — die Codesignatur. Der Speicher „Vertrauenswürdige Herausgeber“ (TrustedPublisher) aus der Tabelle in 2.2 ist genau die Schnittstelle: dort wird das Herausgeberzertifikat signierter Software als vertrauenswürdig registriert. Er existiert sowohl im Benutzer- als auch im Computer-Ort¹⁰ und wird zum Beispiel dafür eingesetzt, den Herausgeber einer intern verteilten Anwendung per GPO an das TrustedPublisher jedes PCs zu verteilen.

Wenn Sie eine Anwendung „verteilend“ betreuen und sich mit Codesignatur oder der SmartScreen-Warnung („Windows hat Ihren PC geschützt“) befassen müssen, haben wir das in einem eigenen Artikel zusammengestellt: „Warum Windows „Windows hat Ihren PC geschützt“ anzeigt“. Das Wissen aus diesem Artikel (die zwei Speichersysteme, die Stammzertifikatsverteilung) lässt sich dort unmittelbar als Vorwissen verwenden.

9. Zusammenfassung

• Der Zertifikatspeicher besteht aus zwei Systemen: Benutzer (CurrentUser) und Computer (LocalMachine). certmgr.msc, certlm.msc und das Cert:-Laufwerk sind drei Fenster auf dieselbe Sache. Der erste Schritt jeder Untersuchung ist, sich darauf zu einigen, von welchem Speicher gerade die Rede ist.
• Wo ein Zertifikat abgelegt wird, entscheidet sich danach, „unter wessen Konto das Programm läuft“. Als Grundregel gilt: unbeaufsichtigte Ausführung (Dienste, IIS, Aufgaben) nutzt den Computerspeicher, interaktive Anwendungen den Benutzerspeicher.
• „Es funktionierte während der Entwicklung, wird aber in der Produktion nicht gefunden“ liegt daran, dass der Benutzerspeicher des Entwicklers und der des Dienstkontos zwei verschiedene Dinge sind. Die Lösung ist die Angleichung auf den Computerspeicher plus StoreLocation.LocalMachine.
• Die Ablage im Computerspeicher und die Vergabe von Lesezugriff über „Privaten Schlüssel verwalten“ sind eine einzige zusammengehörige Aufgabe. Bei einer Erneuerung nicht vergessen, die Berechtigung erneut zu vergeben.
• Der pfx-Import ist standardmäßig nicht exportierbar. Setzen Sie -Exportable nur dann, wenn Sie es wirklich brauchen. Beziehen Sie auch die Aufbewahrung der ursprünglichen pfx und ihres Passworts in Ihr Design ein.
• Den Ablauf verhindern Sie durch regelmäßige Bestandsaufnahme mit Get-ChildItem Cert: ... -ExpiringInDays und ein Zertifikatsverzeichnis. Erneuern Sie in der Reihenfolge „hinzufügen → umschalten → prüfen → löschen“ und achten Sie auf vergessene Fingerabdruck-Aktualisierungen in der Konfiguration.
• Grenzen Sie Kettenprobleme mit certutil -urlfetch -verify ein. Verteilen Sie den Stamm einer internen Zertifizierungsstelle über GPO oder Intune, und beschränken Sie das Ablegen selbstsignierter Zertifikate im Stammspeicher auf Testumgebungen mit befristeter Gültigkeit.
• Lagern Sie im Code den Fingerabdruck in die Konfiguration aus und protokollieren Sie das gewählte Zertifikat. Allein das verändert den Umgang mit zertifikatsbedingten Störungen spürbar zum Besseren.

Verwandte Artikel

• Warum Windows „Windows hat Ihren PC geschützt“ anzeigt
• Vertrauliche Daten in Windows-Anwendungen speichern — Klartextkonfiguration mit DPAPI vermeiden
• Anmeldeinformationen in PowerShell sicher handhaben — Klartextpasswörter aus Ihren Skripten verbannen
• HttpClient sollte nicht mit using umschlossen werden — HTTP-Kommunikation in C#-Fachanwendungen in der Praxis
• Was passiert, wenn man die My-Number-Versichertenkarte auflegt? — Die Online-Anspruchsprüfung und ihre Anbindung an das Abrechnungssystem, gelesen aus dem Quellcode von ORCA

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt die Entwicklung von Fachanwendungen mit Web-API-Anbindungen über Client-Zertifikate (Bank-APIs, Online-Anspruchsprüfung u. Ä.), die Untersuchung von Störungen der Art „Zertifikat nicht gefunden“ oder „nach der Erneuerung keine Verbindung mehr“, sowie den Aufbau eines geordneten Verfahrens zum Zertifikatsaustausch. Sie können sich auch schon melden, wenn Sie noch nicht wissen, wo im Speicher Sie überhaupt nachsehen müssen.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist der Unterschied zwischen certmgr.msc und certlm.msc?

Sie richten sich an unterschiedliche Speicher. certmgr.msc öffnet den Zertifikatspeicher des gerade angemeldeten Benutzers (der aktuelle Benutzer, CurrentUser), certlm.msc öffnet den Zertifikatspeicher des Computers (der lokale Computer, LocalMachine). Der Computerspeicher wird von allen Benutzern und Diensten auf dem PC gemeinsam genutzt, und seine Verwaltung erfordert Administratorrechte. Ein Benutzer ohne Administratorrechte kann nur seinen eigenen Benutzerspeicher verwalten. In beiden ist der Inhalt in logische Speicher wie „Eigene Zertifikate“ und „Vertrauenswürdige Stammzertifizierungsstellen“ unterteilt, und aus PowerShell heraus sehen Sie dieselbe Struktur als Cert:\CurrentUser und Cert:\LocalMachine.

Sollte ein Client-Zertifikat in den Benutzer- oder den Computerspeicher?

Das hängt davon ab, unter wessen Konto das Programm läuft, das das Zertifikat verwendet. Bei einer Desktopanwendung, die von einem interaktiven Benutzer gestartet wird, ist der Benutzerspeicher der nutzenden Person (Cert:\CurrentUser\My) die Grundregel. Bei einem unbeaufsichtigt laufenden Programm — einem Windows-Dienst, einem IIS-Anwendungspool oder der Aufgabenplanung — gehört es in den Computerspeicher (Cert:\LocalMachine\My), wobei dem Ausführungskonto Lesezugriff auf den privaten Schlüssel gewährt werden muss. Da der Benutzerspeicher für jedes Konto separat ist, ist ein Zertifikat, das ein Entwickler in seinen eigenen Benutzerspeicher gelegt hat, für einen Dienst, der unter einem anderen Konto läuft, unsichtbar. Das ist die klassische Ursache dafür, dass „es während der Entwicklung funktionierte, in der Produktion aber nicht gefunden wird“.

Was sollte ich prüfen, wenn ein Windows-Dienst ein Zertifikat nicht findet oder nicht verwenden kann?

Prüfen Sie zwei Dinge, in dieser Reihenfolge. Erstens: Welchen Speicher betrachtet der Code überhaupt? Öffnet der Code StoreLocation.CurrentUser, ist das der Benutzerspeicher des Ausführungskontos des Dienstes — nicht der Speicher, den ein Administrator sieht, wenn er certmgr.msc für sich selbst öffnet. Verschieben Sie das Zertifikat in den Computerspeicher und richten Sie den Code auf StoreLocation.LocalMachine aus. Zweitens: Lässt sich der private Schlüssel tatsächlich lesen? Im Zertifikatslisting sichtbar zu sein und nutzbar zu sein sind zwei verschiedene Dinge — standardmäßig können normalerweise nur Administratoren und SYSTEM auf den privaten Schlüssel im Computerspeicher zugreifen. Öffnen Sie in certlm.msc für das betreffende Zertifikat „Privaten Schlüssel verwalten“ und gewähren Sie dem Ausführungskonto des Dienstes (z. B. NETWORK SERVICE) „Lesen“.

Wie kann ich ablaufende Zertifikate mit PowerShell frühzeitig erkennen?

Mit Get-ChildItem gegen das Cert:-Laufwerk lässt sich eine Bestandsaufnahme durchführen. Zum Beispiel listet Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter die „Eigene Zertifikate“ des Computerspeichers nach Ablaufdatum sortiert auf. Mit dem Parameter -ExpiringInDays lassen sich zusätzlich nur „Zertifikate, die innerhalb der angegebenen Anzahl an Tagen ablaufen“ herausfiltern; bei 0 werden bereits abgelaufene Zertifikate angezeigt. Führen Sie das monatlich gegen alle Server aus und gleichen Sie das Ergebnis mit einem Zertifikatsverzeichnis ab, lassen sich Vorfälle der Art „ab Montagmorgen wegen abgelaufenem Zertifikat keine Verbindung mehr“ nahezu vollständig vermeiden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.