Windows-Zertifikatspeicher in der Praxis — Benutzer oder Computer, wohin damit?

„Beim Wechsel des Terminals für die Online-Anspruchsprüfung haben wir das Clientzertifikat auf den neuen PC übertragen, und jetzt kommt keine Verbindung mehr zustande.“ „Auf dem Entwicklungsrechner erreichen wir die Bank-API, aber als Windows-Dienst heißt es, das Zertifikat sei 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 Clientzertifikaten im Custom Software Development baut, kommt diese Art von Frage regelmäßig.

Online-Anspruchsprüfung im Gesundheitswesen, elektronische Anträge, Bank-APIs, EDI mit Geschäftspartnern. Clientzertifikate, 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 auf wenige 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 Clientzertifikate verwenden, und an IT-Verantwortliche, denen der Austausch von Zertifikaten übertragen wird. Im Zentrum steht die Entscheidung Benutzer- oder Computerspeicher; von dort aus werden Struktur des Windows-Zertifikatspeichers, Rechte am privaten Schlüssel, Bestandsaufnahme ablaufender Zertifikate mit PowerShell und der Verwendungscode aus .NET in einem Zug durchgearbeitet. Die Inhalte stützen sich auf Primärquellen von Microsoft Learn mit Stand August 2026.

1. Zuerst die Kernaussage

• Der Windows-Zertifikatspeicher besteht aus zwei Systemen: Benutzer (CurrentUser) und Computer (LocalMachine). Der Benutzerspeicher ist je Konto getrennt (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 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).
• Dass es in der Entwicklung funktionierte und als Dienst nicht mehr gefunden wird, hat fast immer eine Ursache. Ein Zertifikat, das ein Entwickler in den eigenen Benutzerspeicher gelegt hat, ist vom CurrentUser eines unter einem anderen Konto laufenden Dienstes 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. Erteilen Sie dem Ausführungskonto über Privaten Schlüssel verwalten in certlm.msc Leserecht.⁵
• 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 Tage 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).

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (41 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

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 HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates.²
• Der Zertifikatspeicher des Benutzers (aktueller Benutzer, CurrentUser): Dieser ist für jedes Benutzerkonto getrennt. Er liegt physisch unter HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, also als Teil des Benutzerprofils.²

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

Ein wichtiges Verhalten: 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 CA 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 Clientzertifikat — das gehört in Eigene Zertifikate — selbst entscheiden müssen, wer es sehen können muss. Diese Asymmetrie ist der Dreh- und Angelpunkt des 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/>Je Konto getrennt"]
        CUMY["Eigene Zertifikate (My)<br/>Nicht geerbt - Sie entscheiden selbst, wohin"]
        CUROOT["Vertrauenswürdige Stammzertifizierungsstellen (Root)"]
        CUCA["Zwischenzertifizierungsstellen (CA)"]
        CUTP["Vertrauenswürdige Herausgeber (TrustedPublisher)"]
    end
    LMROOT -.->|"Inhalt erscheint durch Vererbung"| CUROOT
    LMCA -.->|"geerbt"| CUCA
    LMTP -.->|"geerbt"| CUTP

2.2. Die wichtigsten logischen Speicher

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

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

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

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

Wenn Sie das Zertifikatsnap-in in mmc.exe manuell hinzufügen, wählen Sie das Ziel aus drei Arten: Benutzerkonto, Computerkonto und Dienstkonto. Ein Benutzer ohne Administratorrechte kann nur den Speicher des eigenen Benutzerkontos verwalten.³

Der erste Schritt jeder Fehlersuche ist, „welchen Speicher die App betrachtet“ und „welchen Speicher Sie betrachten“ zur Deckung zu bringen. certmgr.msc anzustarren, während ein Dienst ausfällt, führt nie zur Antwort, weil Sie am falschen Ort suchen.

3. Welchen Speicher wählen — eine Entscheidungstabelle nach der Ausführungsform

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

Im Zweifel: was unbeaufsichtigt läuft, in den Computerspeicher, was ein Mensch bedient, in den Benutzerspeicher.

3.1. Anatomie des Klassikers — „in der Entwicklung ging es, als Dienst nicht mehr gefunden“

Dieser Vorfall lässt sich mit den folgenden Schritten genau reproduzieren.

1. Der Entwickler importiert die pfx per Doppelklick. Der Standard des Assistenten ist Aktueller Benutzer, das Zertifikat landet also im Benutzerspeicher des Entwicklerkontos.
2. Die App in der Entwicklung läuft aus Visual Studio, also unter dem Entwicklerkonto; StoreLocation.CurrentUser findet das Zertifikat. Es funktioniert.
3. Auf dem Produktionsserver wird es als Windows-Dienst registriert. Der Dienst läuft unter NETWORK SERVICE oder einem eigenen Konto.
4. Das CurrentUser, das der Dienstcode öffnet, ist der Benutzerspeicher des Dienstkontos. Der ist leer. „Zertifikat nicht gefunden“.

flowchart TB
    subgraph DEV["Entwicklungsrechner"]
        D1["pfx per Doppelklick importieren<br/>Standard des Assistenten ist Aktueller Benutzer"] --> D2["landet im Benutzerspeicher<br/>des Entwicklerkontos"]
        D2 --> D3["Aus Visual Studio ausführen<br/>= läuft unter dem Entwicklerkonto"]
        D3 --> D4["CurrentUser öffnen findet es<br/>-> es funktioniert"]
    end
    subgraph PROD["Produktionsserver"]
        P1["Als Windows-Dienst registrieren<br/>Ausführungskonto ist NETWORK SERVICE o. ä."] --> P2["Das CurrentUser des Codes ist<br/>der Benutzerspeicher des Dienstkontos"]
        P2 --> P3["der ist leer<br/>-> Zertifikat nicht gefunden"]
    end
    D4 -.->|"dieselbe App bereitstellen"| P1

Der Punkt ist, dass der Benutzerspeicher „so oft existiert, wie es Konten gibt“. Öffnet ein Administrator certmgr.msc und bestätigt „es ist doch drin“, ist das der Speicher des Administrators, nicht der des Dienstkontos. Die Abhilfe ist keine ad-hoc-Kopie, sondern erneutes Ablegen im Computerspeicher und Ausrichten des Codes auf StoreLocation.LocalMachine. Und die Rechtevergabe des nächsten Kapitels gehört dazu.

4. Privater Schlüssel und Zugriffsrechte — der zweite Klassiker

4.1. Zertifikat und privater Schlüssel sind verschiedene Dinge

Was in der Liste des Zertifikatspeichers sichtbar ist, ist das Zertifikat (öffentliche Information), nicht der private Schlüssel selbst. Für die Clientauthentifizierung braucht es die Signatur mit dem privaten Schlüssel, daher sind „in der Liste sichtbar“ und „verwendbar“ verschiedene Probleme. Wer das vermischt, landet bei schwer lesbaren Ausfällen: „das Zertifikat ist da, aber der TLS-Handshake scheitert“, „interne Fehler der Art Access Denied“.

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

Das Paar aus Zertifikat und privatem Schlüssel wird als pfx (PKCS #12) übergeben und mit Import-PfxCertificate in den Speicher übernommen.⁶

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

Wichtig: ohne -Exportable lässt sich der übernommene private Schlüssel nicht erneut exportieren — das ist das Standardverhalten.⁶ Alles exportierbar zu importieren, „damit man später umziehen kann“, legt einen weiteren Weg an, den privaten Schlüssel mitzunehmen. Bewahren Sie die Original-pfx sicher auf; auf dem Speicher nicht exportierbar ist die Grundlage — das ist unsere Empfehlung. Original-pfx und ihr Kennwort werden oft im Klartext liegen gelassen. Die Einordnung steht in „Geheimnisse in Windows-Apps speichern — Klartextkonfiguration mit DPAPI vermeiden“ und „Anmeldeinformationen in PowerShell sicher behandeln“.

4.3. Rechte am privaten Schlüssel für Dienstkonten

Der private Schlüssel eines Zertifikats im Computerspeicher ist standardmäßig in der Regel nur für Administratoren und SYSTEM lesbar. Deshalb kann ein Dienst unter LocalSystem den privaten Schlüssel mit den Standardeinstellungen lesen; bei NETWORK SERVICE, einem eigenen Dienstkonto, einer IIS-Anwendungspool-ID und anderen Konten müssen Sie dem Ausführungskonto ausdrücklich Leserecht erteilen. Das geht über die Benutzeroberfläche des Zertifikatsnap-ins.⁵

1. Öffnen Sie certlm.msc (oder das Zertifikatsnap-in mit Ziel Computerkonto).
2. Unter Eigene Zertifikate → Zertifikate das betreffende Zertifikat rechtsklicken und unter Alle Aufgaben Privaten Schlüssel verwalten öffnen.
3. Auf der Registerkarte Sicherheit das Ausführungskonto (NETWORK SERVICE, eigenes Dienstkonto, IIS-Anwendungspool-ID usw.) hinzufügen und Lesen erlauben.⁵

Vollzugriff ist nicht nötig. Für die Signatur reicht Lesen. Umgekehrt, Everyone Vollzugriff zu geben, weil es nicht läuft, senkt den privaten Schlüssel auf die Behandlung eines Klartextkennworts — das ist unbedingt zu vermeiden. Ablage im Computerspeicher und Rechte am privaten Schlüssel gehören immer zusammen — das in die Anleitung zu schreiben, beseitigt diese Vorfallreihe.

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

5.1. Bestandsaufnahme mit PowerShell

Die Gültigkeit steht in der Eigenschaft NotAfter. Mit Get-ChildItem gegen das Laufwerk Cert: lässt sie sich maschinell erfassen.⁴

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

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

-ExpiringInDays liefert Zertifikate, die innerhalb der angegebenen Tage ablaufen; 0 liefert bereits abgelaufene.⁴ Machen Sie daraus eine monatliche geplante Aufgabe über alle Server und bündeln Sie das Ergebnis in E-Mail oder Verzeichnis — allein das verhindert Vorfälle der Art „ab Montagmorgen geht die Anspruchsprüfung nicht mehr durch, weil ein Zertifikat abgelaufen ist“ weitgehend.

5.2. Austauschverfahren — Übergangsphase und die Falle des Fingerabdrucks

Die Erneuerung ist nicht „löschen und einsetzen“, sondern „hinzufügen, dann umschalten, prüfen, dann löschen“.

1. Das neue Zertifikat (pfx) in denselben Speicher importieren. Weil der Fingerabdruck anders ist, können alt und neu im selben Speicher koexistieren.
2. Die Rechte am privaten Schlüssel des neuen Zertifikats erteilen (Kapitel 4). Beim Update wird das leicht vergessen. Die Rechte hängen am privaten Schlüssel je Zertifikat; nach dem Austausch muss die Vergabe wiederholt werden.
3. Die Meldung an das Gegenstellensystem (wenn die API eine Vorabregistrierung des Zertifikats braucht) noch unter dem alten Zertifikat erledigen und eine Übergangsphase sichern, in der beides angenommen wird. Schalten Sie zuerst um, lehnt die Gegenseite das neue Zertifikat ab und der Produktionsverkehr steht.
4. Die Konfiguration der App auf das neue Zertifikat umstellen und das Verhalten prüfen.
5. Nach ausreichender Zeit das alte Zertifikat löschen.

flowchart LR
    I["1. Neue pfx in denselben Speicher<br/>importieren (alt und neu koexistieren)"] --> P["2. Rechte am privaten Schlüssel<br/>des neuen Zertifikats erteilen"]
    P --> R["3. Bei der Gegenseite vorab registrieren<br/>(Betrieb unter dem alten Zertifikat fortsetzen)"]
    R --> SW["4. Fingerabdruck in der Konfiguration<br/>umschreiben, umschalten und prüfen"]
    SW --> DEL["5. Nach der Übergangsphase<br/>das alte Zertifikat löschen"]

Die größte Falle dabei ist der in Konfiguration oder Code geschriebene Fingerabdruck. Der Fingerabdruck ist je Zertifikat eindeutig, nach der Erneuerung ändert er sich immer. Bleibt irgendwo der alte Fingerabdruck, entsteht „das Zertifikat ist erneuert, aber es verbindet nicht“. Wo der Fingerabdruck steht (App-Konfiguration, IIS-Bindung, Skript, Meldung an die Gegenseite), im Verzeichnis zu führen, ist zuverlässig.

5.3. Ein Zertifikatsverzeichnis lohnt sich

Verzeichnis heißt zunächst ein Excel-Blatt. Mindestens die Spalten Verwendung / Aussteller / Subject / Fingerabdruck / Ort (Servername + Speicher) / Konten mit Recht am privaten Schlüssel / Ablauf / Link zum Updateverfahren / Verantwortliche anlegen und mit der Bestandsaufnahme aus 5.1 abgleichen. Zertifikatsvorfälle sind oft kein Technikproblem, sondern „niemand hat eine Liste“ — das Verzeichnis wirkt am stärksten.

6. Prüfung und Lesen von Fehlern — Kette und Verteilung der Stammzertifikate

6.1. Grundlagen der Kettenprüfung und certutil

Fehler der Art „dieses Zertifikat wird nicht vertraut“ bedeuten, dass die Kette (Zertifizierungspfad) vom Blattzertifikat zur Stamm-CA irgendwo reißt. Zum Eingrenzen eignet sich certutil.⁷

flowchart TB
    LEAF["Blattzertifikat<br/>(Client- oder Serverzertifikat)"] --> INT["Zwischen-CA-Zertifikat<br/>Ort: Zwischenzertifizierungsstellen (CA)"]
    INT --> ROOT["Stamm-CA-Zertifikat<br/>Ort: Vertrauenswürdige Stammzertifizierungsstellen (Root)"]
    INT -.->|"nicht zu erhalten<br/>(weder Vorlage noch AIA noch Speicher)"| E1["Kette lässt sich nicht aufbauen<br/>(Klassiker 1)"]
    ROOT -.->|"nicht verteilt"| E2["Fehler nicht vertraut<br/>(Klassiker 2)"]
    LEAF -.->|"abgelaufen"| E3["Fehler der Gültigkeitsdauer<br/>(Klassiker 3)"]

:: Kette einer Zertifikatdatei aufbauen und prüfen (inkl. Abruf der Widerrufs-URL)
certutil -urlfetch -verify client.cer

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

:: Inhalt des Speichers ausgeben (-user wechselt zum Benutzerspeicher)
certutil -store My
certutil -user -store My

certutil -verify prüft Zertifikat, CRL und Kette und baut ohne Angabe einer CACertFile eine vollständige Kette auf.⁷ Die Ausgabe ist lang, aber man liest, auf welcher Ebene das Vertrauen reißt und ob Widerrufsinformationen ankommen. Typische Ursachen sind: (1) das Zwischen-CA-Zertifikat ist nicht zu erhalten (der TLS-Partner sendet es nicht, es kommt auch nicht über AIA, und es liegt nicht in Zwischenzertifizierungsstellen), (2) die Stamm-CA der internen CA ist nicht in Vertrauenswürdige Stammzertifizierungsstellen verteilt, (3) das Zertifikat selbst ist abgelaufen. Eine Zwischen-CA kann auch durch Vorlage vom Partner oder automatischen Abruf über AIA gelöst werden; die Ablage im Speicher ist eines der Mittel, es sicher zu machen.

6.2. Verteilung interner CA- und selbstsignierter Stammzertifikate über GPO/Intune

Nutzen Sie eine interne CA oder selbstsignierte Zertifikate zur Prüfung, müssen deren Stammzertifikate auf die PCs. Nicht einzeln von Hand, sondern über den Verteilungsmechanismus.

• Active-Directory-Umgebung (GPO): Importieren Sie das Zertifikat unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien öffentlicher Schlüssel in Vertrauenswürdige Stammzertifizierungsstellen, dann wird es an die Ziel-PCs verteilt.⁸
• Intune-verwaltete Umgebung: Mit dem Profil Vertrauenswürdige Zertifikate Stamm- und Zwischen-CA-Zertifikate verteilen. Unter Windows lässt sich der Zielspeicher wählen (Computer Stamm/Zwischen, Benutzer Zwischen).⁹

Wie in 2.1: liegt der Stamm im Computerspeicher, vertrauen alle Benutzer ihm.¹ Deshalb auch das umgekehrte Risiko. Ein selbstsigniertes Zertifikat in Vertrauenswürdige Stammzertifizierungsstellen zu legen pflanzt auf diesem PC einen neuen Vertrauensanker. Leakt der private Schlüssel, ist das die Basis, Zertifikate für beliebige Sites oder Software auszustellen. Für den Dauerbetrieb eine interne CA mit geschütztem privatem Schlüssel aufbauen oder zu einem öffentlichen CA-Zertifikat wechseln; selbstsignierte Stämme nur auf die Prüfumgebung und mit Frist — das ist der Grundsatz.

7. Sicht des Entwicklers — den Speicher aus .NET richtig nutzen

7.1. Suche nach Fingerabdruck mit X509Store

Aus .NET öffnen Sie den Speicher mit X509Store und holen das 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}, " +
            $"Ort={store.Location}\\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"Das Zertifikat ist da, aber kein privater Schlüssel ist verknüpft " +
            $"(Import aus .cer o. ä.): Fingerabdruck={thumbprint}, Ort={store.Location}\\{store.Name}");

    return cert;
}

Die Entscheidung aus Kapitel 3 mündet hier. Code, der als Dienst läuft, verwendet StoreLocation.LocalMachine, eine interaktive App StoreLocation.CurrentUser. Achten Sie außerdem auf das dritte Argument validOnly von Find. true liefert nur gültige Zertifikate, die die Prüfung bestehen.¹¹ Das schützt vor abgelaufenen Zertifikaten; selbstsignierte Testzertifikate, deren Kette nicht vertraut wird, fallen aber auch auf die Seite „nicht gefunden“. Wenn „es ist drin, wird aber nicht gefunden“, verdächtigen Sie auch das. Und die Fehlermeldung bei Nichtfinden muss wie oben angeben, welchen Speicher Sie durchsucht haben. Die Untersuchungszeit des Vorfalls aus Kapitel 3 ändert sich um Größenordnungen.

7.2. Ein Clientzertifikat an HttpClient hängen

Das geholte Zertifikat fügen Sie HttpClientHandler.ClientCertificates hinzu und legen es dem Server vor. Diese Sammlung ist die Menge der Zertifikate, die bei zertifikatsbasierter Clientauthentifizierung dem Server vorgelegt werden.¹²

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

var client = new HttpClient(handler);
// Danach wie ein gewöhnlicher HttpClient verwenden

In der .NET-Core-Linie ist dokumentiert, dass ein Zertifikat mit Key-Usage-Attribut nur dann für den Request verwendet wird, wenn es Digital Signature enthält.¹² Wenn Sie die Ausstellung eines Clientzertifikats beauftragen, geben Sie den Zweck (Clientauthentifizierung) korrekt an. Außerdem führt ein falsches Erzeugungsmuster von HttpClient zu Socket-Erschöpfung und Problemen bei der DNS-Nachführung. Handler langlebig zu machen, ist wie in „HttpClient nicht in using einschließen“ behandelt.

7.3. Ein fest eingetragener Fingerabdruck stirbt beim Austausch

Die Suche nach Fingerabdruck ist zuverlässig, aber den Fingerabdruck in den Code zu legen erzwingt bei jeder Zertifikatserneuerung Build und Release. Die konstruktive Abhilfe hat drei Stufen.

• Mindestens: den Fingerabdruck in eine Konfigurationsdatei (appsettings usw.) auslagern, damit er ohne Release gewechselt werden kann. Die Konfigurationsstellen ins Verzeichnis aus 5.3 aufnehmen.
• Einen Schritt weiter: nach Subject oder Aussteller suchen und mit validOnly: true „unter diesem Namen das derzeit gültige mit dem spätesten NotAfter“ wählen. In der Übergangsphase wechselt es automatisch zum neuen Zertifikat. Es besteht das Risiko, ein unbeabsichtigtes Zertifikat gleichen Namens zu greifen, daher Ausstellerprüfung und Protokollausgabe zusammen. Und dieser automatische Wechsel gilt nur, wenn die Gegenseite keine Vorabregistrierung des Zertifikats braucht. Bei APIs mit Vorabregistrierung (5.2) kann ein nur importiertes, noch nicht registriertes Zertifikat den Verkehr stoppen; bleiben Sie bei der Auslagerung der Konfiguration und schalten erst nach bestätigter Registrierung um.
• Im Betrieb schließen: bei jedem Verfahren beim Start protokollieren, welches Zertifikat (Fingerabdruck, Ablauf) gewählt wurde. Diese eine Zeile wirkt in der Störungssuche und beim Abgleich mit dem Verzeichnis.

8. Verhältnis zu Codesignaturzertifikaten — der Speicher Vertrauenswürdige Herausgeber

Bisher ging es um Zertifikate für die Kommunikation (TLS), aber im Zertifikatspeicher wohnt noch eine Welt — Codesignatur. Der in 2.2 genannte Speicher Vertrauenswürdige Herausgeber (TrustedPublisher) ist die Nahtstelle; dort werden Herausgeberzertifikate signierter Software als vertrauenswürdig eingetragen. Er existiert an Benutzer- und Computerort,¹⁰ etwa um den Herausgeber intern verteilter Apps per GPO in TrustedPublisher jedes PCs zu legen.

Wer als Verteilende Seite Codesignatur und die SmartScreen-Warnung („Von Windows geschützt“) behandeln muss, findet das in „Warum unter Windows Von Windows geschützt erscheint“. Das Wissen dieses Artikels (zwei Speichersysteme, Stammverteilung) bleibt die Voraussetzung.

9. Zusammenfassung

• Der Zertifikatspeicher hat die zwei Systeme Benutzer (CurrentUser) und Computer (LocalMachine). certmgr.msc / certlm.msc / das Laufwerk Cert: sind drei Fenster auf dasselbe. Der erste Schritt der Untersuchung ist, zu klären, von welchem Speicher die Rede ist.
• Der Ort richtet sich danach, als wer das Programm läuft. Unbeaufsichtigte Ausführung (Dienst, IIS, Aufgabe) in den Computerspeicher, interaktive Apps in den Benutzerspeicher — das ist der Grundsatz.
• „In der Entwicklung ging es, in der Produktion nicht gefunden“ kommt daher, dass der Benutzerspeicher des Entwicklers und der des Dienstkontos verschieden sind. Computerspeicher plus StoreLocation.LocalMachine löst es.
• Ablage im Computerspeicher und Leserecht über Privaten Schlüssel verwalten gehören zusammen. Die erneute Vergabe beim Update nicht vergessen.
• Der pfx-Import ist standardmäßig nicht exportierbar. -Exportable nur, wenn wirklich nötig. Auch die Aufbewahrung von Original-pfx und Kennwort gehört in den Entwurf.
• Ablauf verhindern Sie durch regelmäßige Bestandsaufnahme mit Get-ChildItem Cert: ... -ExpiringInDays und ein Zertifikatsverzeichnis. Der Austausch folgt „hinzufügen → umschalten → prüfen → löschen“; auf vergessene Fingerabdrücke in der Konfiguration achten.
• Die Kette grenzt certutil -urlfetch -verify ein. Den Stamm einer internen CA über GPO/Intune verteilen; selbstsignierte Stämme nur in der Prüfumgebung und befristet.
• Im Code den Fingerabdruck in die Konfiguration auslagern und das gewählte Zertifikat protokollieren. Allein das verändert die Behandlung zertifikatsbedingter Störungen.

Verwandte Artikel

• Warum unter Windows „Von Windows geschützt“ erscheint
• Geheimnisse in Windows-Apps speichern — Klartextkonfiguration mit DPAPI vermeiden
• Anmeldeinformationen in PowerShell sicher behandeln — Klartextkennwörter aus Skripten verbannen
• HttpClient nicht in using einschließen — HTTP-Kommunikation in C#-Fachanwendungen
• Was geschieht, wenn die My-Number-Gesundheitskarte vorgehalten wird — Online-Anspruchsprüfung und ORCA

Verwandte Beratungsleistungen

Die KomuraSoft LLC entwickelt Fachanwendungen mit Clientzertifikat-Web-API-Anbindung (Bank-APIs, Online-Anspruchsprüfung usw.), untersucht Vorfälle der Art „Zertifikat nicht gefunden“ oder „nach der Erneuerung keine Verbindung“ und richtet Austauschverfahren für Zertifikate ein. Es reicht, sich zu melden, wenn unklar ist, welchen Speicher man betrachten soll.

• 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 öffnen unterschiedliche Speicher. certmgr.msc öffnet den Zertifikatspeicher des angemeldeten Benutzers (aktueller Benutzer, CurrentUser), certlm.msc den des Computers (lokaler Computer, LocalMachine). Der Computerspeicher ist für alle Benutzer und Dienste auf dem PC gemeinsam, und seine Verwaltung erfordert Administratorrechte. Ein Benutzer ohne Administratorrechte kann nur den eigenen Benutzerspeicher verwalten. In beiden ist der Inhalt in logische Speicher wie Eigene Zertifikate und Vertrauenswürdige Stammzertifizierungsstellen unterteilt; aus PowerShell sieht man dieselbe Struktur als Cert:\CurrentUser und Cert:\LocalMachine.

Sollte ein Clientzertifikat 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 ein interaktiver Benutzer startet, ist der Benutzerspeicher der nutzenden Person (Cert:\CurrentUser\My) die Grundlage. Bei unbeaufsichtigter Ausführung — Windows-Dienst, IIS-Anwendungspool oder Aufgabenplanung — gehört es in den Computerspeicher (Cert:\LocalMachine\My), und dem Ausführungskonto wird Leserecht am privaten Schlüssel erteilt. Weil der Benutzerspeicher je Konto getrennt ist, ist ein Zertifikat, das ein Entwickler in den eigenen Benutzerspeicher gelegt hat, für einen Dienst unter einem anderen Konto unsichtbar. Das ist die klassische Ursache dafür, dass es in der Entwicklung funktionierte und in der Produktion nicht gefunden wird.

Was 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? Öffnet er StoreLocation.CurrentUser, ist das der Benutzerspeicher des Ausführungskontos des Dienstes — nicht der Speicher, den ein Administrator in certmgr.msc für sich selbst sieht. Verschieben Sie das Zertifikat in den Computerspeicher und richten Sie den Code auf StoreLocation.LocalMachine aus. Zweitens: Lässt sich der private Schlüssel lesen? In der Liste sichtbar zu sein und verwendbar zu sein sind verschieden — standardmäßig können in der Regel nur Administratoren und SYSTEM auf den privaten Schlüssel im Computerspeicher zugreifen. Öffnen Sie in certlm.msc für das Zertifikat Privaten Schlüssel verwalten und erteilen Sie dem Ausführungskonto des Dienstes (etwa NETWORK SERVICE) Lesen.

Wie lassen sich ablaufende Zertifikate mit PowerShell früh finden?

Mit Get-ChildItem gegen das Laufwerk Cert: lässt sich eine Bestandsaufnahme machen. Zum Beispiel listet Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter die Eigenen Zertifikate des Computerspeichers nach Ablaufdatum. Mit -ExpiringInDays extrahieren Sie nur Zertifikate, die innerhalb der angegebenen Tage ablaufen; 0 liefert bereits abgelaufene. Führen Sie das monatlich gegen alle Server aus und gleichen Sie mit einem Zertifikatsverzeichnis ab, lassen sich Vorfälle der Art ab Montagmorgen keine Verbindung mehr wegen abgelaufenem Zertifikat weitgehend 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.