Windows Certificate Store practical guide — user या computer, कहाँ रखें

«Online eligibility confirmation terminal update पर client certificate नए PC में फिर रखा तो connection टूट गया।» «Development machine पर bank API जुड़ता है, Windows service बनाते «certificate नहीं मिला»।» «certmgr.msc में दिखता certificate और certlm.msc में दिखता — कौन सा असली?» — Client certificates वाले Web API integration Custom Software Development में करते ये बातें नियमित आती हैं।

चिकित्सा संस्थानों की online eligibility confirmation, electronic application, bank API, व्यापारिक भागीदार EDI। कभी बड़े उद्यम के infrastructure कर्मी ही छूते client certificates अब SMEs के IT कर्मी और business-app developers सँभालते हैं। Certificate incidents वास्तव में कुछ patterns में सिमटती हैं। रखने का स्थान गलत, private key access rights भूलना, expiry भूलना — ये तीन।

यह लेख client certificates use करने वाले business-app developers और certificate बदलने का काम सौंपे IT कर्मियों के लिए है। «User store या computer store» निर्णय धुरी पर Windows certificate store structure से private key access rights, PowerShell expiry inventory, .NET से use code तक एक साथ व्यवस्थित करता है। सामग्री अगस्त 2026 तक Microsoft Learn primary sources पर है।

1. निष्कर्ष पहले

• Windows certificate store «user (CurrentUser)» और «computer (LocalMachine)» दो परिवार हैं। User store account-दर-account अलग (registry HKEY_CURRENT_USER के नीचे), computer store पूरे PC पर shared (HKEY_LOCAL_MACHINE के नीचे)।¹²
• Management tools भी दो। certmgr.msc वर्तमान user, certlm.msc Local Computer store खोलता है। PowerShell से Cert:\CurrentUser और Cert:\LocalMachine।³⁴
• कहाँ रखें «वह certificate use करने वाला program किसके रूप में चलता है» से तय। Interactive user app तो user store; Windows service, IIS, Task Scheduler unattended तो computer store मूल (अध्याय 3 decision table)।
• «Development में चला, service बनाते नहीं मिला» का कारण लगभग एक। Developer ने अपने user store में रखा certificate दूसरे account से चलती service के CurrentUser से नहीं दिखता (अध्याय 3)।
• Certificate और private key अलग वस्तुएँ हैं। Computer store में रखने भर से service account private key नहीं पढ़ सकता। certlm.msc «Manage Private Keys» से execution account को read access दें।⁵
• pfx import पर private key default non-exportable हो जाती है। Import-PfxCertificate -Exportable बिना private key पुनः export न कर सकने रूप में लेता है। यह incident नहीं, वांछित default है।⁶
• Expiry inventory automation से रोकें। Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 60 जैसे निर्दिष्ट दिनों में expire certificates यंत्रवत निकाल सकते हैं।⁴
• Thumbprint code या config में hardcode करें तो certificate update हर बार मरता है। नया certificate thumbprint अवश्य बदलता है। Config बाहर + पुराना-नया parallel अवधि design का मूल है (अध्याय 5, 7)।

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 41, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. Certificate store का पूरा चित्र — दो स्थान और logical stores

2.1. User और computer दो परिवार

Windows certificate store बड़े रूप में दो «स्थान» में बँटता है।¹

• Computer (Local Computer, LocalMachine) certificate store: उस PC पर एक, PC पर सब users और services के लिए shared। वस्तु registry HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates के नीचे।²
• User (Current User, CurrentUser) certificate store: User account-दर-account अलग। वस्तु HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates के नीचे, अर्थात user profile का भाग।²

इसके अतिरिक्त service account इकाई stores भी हैं³, वस्तु service नाम की registry key।² व्यवहार में पहले ये दो पकड़ें।

एक महत्त्वपूर्ण spec। User store के प्रत्येक logical store, «Personal» छोड़, computer store के समान नाम store की सामग्री inheritance में दिखाते हैं।¹ उदाहरण: Computer store «Trusted Root Certification Authorities» में internal CA certificate रखें तो सब users के «Trusted Root Certification Authorities» में भी दिखता है। उलटा, «Personal» store ही inheritance नहीं लेता, इसलिए client certificate (= Personal store में रखने वाली वस्तु) «किससे दिखना चाहिए» स्वयं तय करना पड़ता है। यही विषमता इस लेख की नायिका है।

flowchart TB
    accTitle: Computer store और user store
    accDescr: Computer store PC पर एक है और सब users तथा services के लिए shared, user store account-दर-account अलग है और Personal छोड़ computer पक्ष की सामग्री inheritance में दिखाता है
    subgraph LM["Computer (LocalMachine)<br/>PC पर एक・सब users और services के लिए shared"]
        LMMY["Personal (My)"]
        LMROOT["Trusted Root Certification Authorities (Root)"]
        LMCA["Intermediate Certification Authorities (CA)"]
        LMTP["Trusted Publishers (TrustedPublisher)"]
    end
    subgraph CU["User (CurrentUser)<br/>Account-दर-account अलग"]
        CUMY["Personal (My)<br/>※Inheritance नहीं=रखने का स्थान स्वयं तय करें"]
        CUROOT["Trusted Root Certification Authorities (Root)"]
        CUCA["Intermediate Certification Authorities (CA)"]
        CUTP["Trusted Publishers (TrustedPublisher)"]
    end
    LMROOT -.->|"सामग्री inheritance में दिखती है"| CUROOT
    LMCA -.->|"Inheritance"| CUCA
    LMTP -.->|"Inheritance"| CUTP

चित्र 1: User store Personal छोड़ computer store की सामग्री inheritance में दिखाता है; client certificate रखने का स्थान स्वयं तय करना पड़ता है।

2.2. मुख्य logical stores

प्रत्येक स्थान के अंदर भूमिका अनुसार logical stores हैं। certmgr.msc / certlm.msc में दिखते फ़ोल्डर वही; PowerShell या commands से English internal नाम।²⁴

2.3. तीन खिड़कियाँ — certmgr.msc / certlm.msc / Cert: drive

एक ही store देखने के तीन साधन।³⁴

• certmgr.msc: वर्तमान user store खोलने वाला management console।
• certlm.msc: Local Computer store खोलने वाला management console।
• PowerShell Cert: drive: Cert:\CurrentUser\... और Cert:\LocalMachine\... hierarchy से store file system जैसा चला सकते हैं। Certificates thumbprint से पहचाने जाते हैं।

mmc.exe में Certificates snap-in हाथ से जोड़ें तो «My user account», «Computer account», «Service account» तीन में से लक्ष्य चुनें। जो admin नहीं वह केवल अपना user account store manage कर सकता है।³

समस्या जाँच का पहला कदम «app कौन सा store देख रहा है» और «आप कौन सा store देख रहे हैं» मिलाना है। certmgr.msc देखते service failure जाँचें तो देखने का स्थान अलग होने से उत्तर कभी नहीं आता।

3. कहाँ रखें — program execution रूप से decision table

निर्णय एक है। वह certificate use करने वाला program किस account से चलता है।

असमंजस हो तो unattended चलने वाले computer store, व्यक्ति चलाए user store।

3.1. तयशुदा incident का विच्छेदन — «development में चला, service बनाते नहीं मिला»

यह incident निम्न क्रम से ठीक reproduce होती है।

1. Developer अपने PC पर pfx डबल-क्लिक कर import करता है। Wizard default «Current User» है, इसलिए certificate developer account के user store में जाता है।
2. Development app Visual Studio से, अर्थात developer account से चलता है, StoreLocation.CurrentUser खोलें तो certificate मिलता है। चलता है।
3. Production server पर Windows service register करते हैं। Service NETWORK SERVICE या dedicated account से चलती है।
4. Service code खोलता CurrentUser service execution account का user store है। वह खाली। «Certificate नहीं मिला»।

flowchart TB
    accTitle: Development में चला, service बनाते नहीं मिला
    accDescr: Developer के user store में रखा certificate दूसरे account से चलती service के CurrentUser से नहीं दिखता
    subgraph DEV["Development machine"]
        D1["pfx डबल-क्लिक से import<br/>Wizard default «Current User»"] --> D2["Developer account के<br/>User store में जाता है"]
        D2 --> D3["Visual Studio से चलाएँ<br/>=Developer account से चलता है"]
        D3 --> D4["CurrentUser खोलें तो मिलता है<br/>→ चलता है"]
    end
    subgraph PROD["Production server"]
        P1["Windows service के रूप में register<br/>Execution account NETWORK SERVICE आदि"] --> P2["Code खोलता CurrentUser<br/>Service account का user store है"]
        P2 --> P3["वह खाली<br/>→«Certificate नहीं मिला»"]
    end
    D4 -.->|"वही program रखते हैं"| P1

चित्र 2: Developer का user store और service account का user store अलग हैं; development में चलना production में मिलने की गारंटी नहीं।

मुख्य बात: User stores «accounts की संख्या जितने» हैं। Admin certmgr.msc खोल «पड़ा है न?» पुष्टि करे तो वह admin स्वयं का store है, service account का नहीं। उपाय ad-hoc copy नहीं, computer store में फिर रखकर code भी StoreLocation.LocalMachine से मिलाना है। और अगले अध्याय का access देना एक सेट है।

4. Private key और access rights — दूसरी तयशुदा incident

4.1. Certificate और private key अलग वस्तुएँ हैं

Certificate store list में दिखता certificate (public जानकारी) है, private key स्वयं नहीं। Client authentication में वास्तव में चाहिए private key से signature, इसलिए «list में दिखना» और «use हो सकना» अलग समस्याएँ हैं। यहाँ मिलाएँ तो «certificate है पर TLS handshake विफल», «Access Denied परिवार internal error» जैसी दिखने में कठिन failures आती हैं।

4.2. pfx import व्यवहार — exportable या नहीं निर्णय है

Certificate और private key pair pfx (PKCS #12) फ़ाइल से आता-जाता है, Import-PfxCertificate से store में लेते हैं।⁶

$pwd = Get-Credential -UserName '(password नीचे लिखें)' -Message 'PFX password'
Import-PfxCertificate -FilePath C:\certs\client.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd.Password

यहाँ महत्त्वपूर्ण: -Exportable बिना ली गई private key पुनः export नहीं हो सकती — यही default है।⁶ «बाद में migrate कर सकें» कहकर सब exportable रखना private key निकालने का एक और path जोड़ना है। मूल pfx सुरक्षित रखें, store पर private key non-exportable मूल — यही हमारी recommendation है। मूल pfx और उसका password plaintext में पड़े रहना आम है। सोच «Windows apps में secrets रखना — DPAPI से plaintext settings न रखें» और «PowerShell में credentials का सुरक्षित व्यवहार» में व्यवस्थित है।

4.3. Service account को private key access देना

Computer store में रखे certificate की private key default प्रायः Administrators और SYSTEM छोड़ नहीं पढ़ी जाती। इसलिए LocalSystem service default पर private key पढ़ती है; NETWORK SERVICE, dedicated service account, IIS app pool ID जैसे उनके अलावा account से चलाने पर execution account को स्पष्ट read access दें। प्रक्रिया Certificates snap-in UI से।⁵

1. certlm.msc (या Computer account लक्ष्य Certificates snap-in) खोलें।
2. «Personal» → «Certificates» पर लक्ष्य certificate दायाँ क्लिक, «All Tasks» से «Manage Private Keys» खोलें।
3. «Security» tab पर execution account (NETWORK SERVICE, dedicated service account, IIS app pool ID आदि) जोड़कर «Read» अनुमति दें।⁵

Full control नहीं चाहिए। Signature भर हो तो Read काफी। उलटा, न चले तो Everyone को Full control देना private key को plaintext password जितना गिराना है, कभी न करें। Computer store में रखना और private key access देना हमेशा एक सेट — प्रक्रिया में लिख देने भर से यह परिवार incidents मिटती हैं।

5. Expiry incidents रोकें — inventory, renewal, ledger

5.1. PowerShell से inventory

Certificate expiry NotAfter property में है। Cert: drive पर Get-ChildItem से यंत्रवत inventory।⁴

# Computer store «Personal» expiry क्रम में
Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter |
    Format-Table Thumbprint, Subject, NotAfter

# 60 दिनों में expire होने वाले ही (0 दें तो expire हो चुके)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 60

-ExpiringInDays «निर्दिष्ट दिनों में expire certificates» लौटाता है; 0 तो expire हो चुके।⁴ इसे मासिक scheduled task बना सब servers घुमाकर परिणाम email या ledger में इकट्ठा करें — «expiry से सोमवार सुबह eligibility confirmation नहीं» incident लगभग रुकती है।

5.2. Renewal प्रक्रिया — पुराना-नया parallel और thumbprint का जाल

Certificate update «मिटाकर रखना» नहीं, «जोड़कर बदलें, पुष्टि कर मिटाएँ» है।

1. नया certificate (pfx) उसी store में import करें। Thumbprint अलग होने से पुराना-नया एक store में साथ रह सकते हैं।
2. नए certificate की private key access दें (अध्याय 4)। Update पर सबसे आसानी से यही छूटता है। Access certificate की private key-दर-key लगता है; certificate बदला तो access भी दोहराना है।
3. दूसरे पक्ष प्रणाली को सूचना (certificate pre-registration चाहने API) पुराने certificate से operations जारी रखते पहले पूरी करें, पुराना-नया दोनों स्वीकार parallel अवधि सुनिश्चित करें। पहले बदलें तो दूसरा पक्ष नया certificate अस्वीकार कर production संचार रुकता है।
4. App config नए certificate पर बदलकर व्यवहार पुष्टि करें।
5. पर्याप्त अवधि बाद पुराना certificate मिटाएँ।

flowchart LR
    accTitle: Certificate update जोड़कर बदलें
    accDescr: नया pfx उसी store में डाल access दें, दूसरे पक्ष को pre-register कर thumbprint बदलें, parallel अवधि बाद पुराना certificate मिटाएँ
    I["1. नया pfx उसी store में<br/>Import (पुराना-नया साथ)"] --> P["2. नए certificate की<br/>Private key access दें"]
    P --> R["3. दूसरे पक्ष को pre-registration<br/>(पुराने certificate से operations जारी)"]
    R --> SW["4. Config thumbprint लिखकर<br/>बदलें・व्यवहार पुष्टि"]
    SW --> DEL["5. Parallel अवधि बाद<br/>पुराना certificate मिटाएँ"]

चित्र 3: Certificate बदलना जोड़ → access → pre-registration → config बदल → पुराना मिटाना क्रम है; thumbprint update न भूलें।

यहाँ सबसे बड़ा जाल config फ़ाइल या code में लिखा thumbprint है। Thumbprint certificate-दर-certificate unique, update अवश्य बदलता है। कहीं एक स्थान पुराना thumbprint देखता रहे तो «certificate update किया, connection नहीं» आता है। Thumbprint कहाँ लिखा है (app config, IIS binding, scripts, दूसरे पक्ष सूचना) ledger से manage करना पक्का है।

5.3. Certificate ledger की recommendation

Ledger कहते Excel एक पत्र काफी। न्यूनतम use / issuer / subject / thumbprint / स्थान (server नाम + store) / private key access account / expiry / update प्रक्रिया लिंक / जिम्मेदार स्तंभ बना 5.1 inventory परिणाम से मिलाएँ। Certificate incidents का सार तकनीक नहीं «किसी के पास list नहीं» समस्या है, इसलिए ledger सबसे काम करती है।

6. Verification और failure पढ़ना — chain और root distribution

6.1. Chain validation मूल और certutil

«यह certificate trusted नहीं» परिवार error अंत certificate से root CA तक chain (certification path) कहीं कटी अवस्था है। Isolation को certutil सुविधाजनक है।⁷

flowchart TB
    accTitle: Chain validation कटने के तीन तयशुदा कारण
    accDescr: Intermediate CA प्राप्त न हो, root distribute न हो, या अंत certificate expiry हो, इनमें से किसी से trust error आती है
    LEAF["End certificate<br/>(Client certificate・server certificate)"] --> INT["Intermediate CA certificate<br/>स्थान: Intermediate Certification Authorities (CA) store"]
    INT --> ROOT["Root CA certificate<br/>स्थान: Trusted Root Certification Authorities (Root)"]
    INT -.->|"प्राप्त नहीं<br/>(प्रस्तुति・AIA・store कोई नहीं)"| E1["Chain नहीं बनती<br/>(तयशुदा कारण 1)"]
    ROOT -.->|"Distribute नहीं"| E2["«Trusted नहीं» error<br/>(तयशुदा कारण 2)"]
    LEAF -.->|"Expiry"| E3["Validity period error<br/>(तयशुदा कारण 3)"]

चित्र 4: Chain intermediate CA या root न मिलने, या expiry से कटती है; certutil से परत तय करें।

:: Certificate फ़ाइल की chain बनाकर verify (revocation URL प्राप्ति सहित)
certutil -urlfetch -verify client.cer

:: लक्ष्य app user store use करे तो -user लगा उसी context में
certutil -user -urlfetch -verify client.cer

:: Store सामग्री dump (-user लगाएँ तो user store)
certutil -store My
certutil -user -store My

certutil -verify certificate, CRL, chain verify करता है; CACertFile न दें तो पूरी chain बनाकर verify करता है।⁷ Output लंबा है, पर किस परत पर trust कटा, revocation जानकारी मिली या नहीं पढ़ा जा सकता है। Classic कारण: (1) Intermediate CA certificate प्राप्त नहीं (TLS पक्ष ने नहीं भेजा, certificate AIA से भी नहीं मिला, «Intermediate Certification Authorities» store में भी नहीं), (2) Internal CA root «Trusted Root Certification Authorities» पर distribute नहीं, (3) Certificate स्वयं expiry। Intermediate CA पक्ष प्रस्तुति या AIA automatic प्राप्ति से भी हल हो सकता है, store रखना «पक्का करने का एक साधन» समझें।

6.2. Internal CA / self-signed root distribution GPO/Intune से

Internal CA या verification self-signed certificate use हो तो वह root certificate प्रत्येक PC पर बाँटना होगा। एक-एक हाथ से नहीं, distribution mechanism पर रखें।

• Active Directory वातावरण (GPO): Group Policy Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies के «Trusted Root Certification Authorities» में certificate import करें तो लक्ष्य PCs पर बँटता है।⁸
• Intune management वातावरण: «Trusted certificate» profile से root/intermediate CA certificates बाँटें। Windows पर distribution store (computer root/intermediate, user intermediate) चुन सकते हैं।⁹

2.1 अनुसार computer store root में रखें तो सब users trust करते हैं।¹ इसलिए उलटा जोखिम भी देखें। Self-signed certificate «Trusted Root Certification Authorities» में रखना उस PC पर नया trust anchor रोपना है। उसकी private key leak हो तो किसी भी site या software का रूप धारण certificate जारी करने की नींव मिलती है। स्थायी operations हो तो private key ठीक सुरक्षित internal CA बनाएँ या public CA certificate की ओर लाएँ; self-signed root «केवल verification वातावरण, expiry बाँधकर» मूल है।

7. Developer दृष्टि — .NET से store सही use

7.1. X509Store से thumbprint खोज

.NET से X509Store store खोल Find से certificate लेते हैं।¹⁰¹¹

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(
            $"Certificate नहीं मिला: thumbprint={thumbprint}, " +
            $"स्थान={store.Location}\\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"Certificate है पर private key जुड़ी नहीं (.cer से" +
            $"import आदि): thumbprint={thumbprint}, स्थान={store.Location}\\{store.Name}");

    return cert;
}

अध्याय 3 का निर्णय यहाँ सीधे लगता है। Service code हो तो StoreLocation.LocalMachine, interactive app StoreLocation.CurrentUser। एक और, Find का तीसरा तर्क validOnly ध्यान। true validation पार valid certificates ही लौटाता है।¹¹ Expiry समाप्त न पकड़ने का बीमा, दूसरी ओर chain untrusted test self-signed भी «नहीं मिला» ओर गिरता है; «पड़ा है पर नहीं मिला» हो तो यहाँ भी संदेह करें। नहीं मिले error message में उपरोक्त उदाहरण जैसा कौन सा store खोजा अवश्य रखें। अध्याय 3 incident जाँच समय अंकों में बदलता है।

7.2. HttpClient पर client certificate रखना

लिया certificate HttpClientHandler.ClientCertificates में जोड़कर server को प्रस्तुत करते हैं। यही collection certificate-based client authentication में server को प्रस्तुत certificates का समुच्चय है।¹²

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

var client = new HttpClient(handler);
// आगे सामान्य HttpClient के रूप में

.NET Core परिवार में certificate पर Key Usage property हो तो «Digital Signature» शामिल न हो request भेजने में use नहीं होता — document स्पष्ट है।¹² Client certificate जारी करने को कहें तो use (client authentication) सही बताएँ। HttpClient निर्माण pattern गलत हो तो socket समाप्त और DNS पीछा समस्याएँ। Handler सहित लंबा जीवन «HttpClient को using में न बाँधें» में जैसा।

7.3. Hardcode thumbprint बदलने पर मरने की समस्या

Thumbprint खोज पक्की है, पर thumbprint code में गाड़ें तो certificate update हर बार build और release चाहिए। Design में तीन चरण:

• न्यूनतम: Thumbprint config फ़ाइल (appsettings आदि) में बाहर निकालें, release बिना बदल सकें। Config स्थान 5.3 ledger में लिखें।
• एक कदम आगे: Subject name या issuer से खोज, validOnly: true मिलाकर «उस नाम का वर्तमान valid में NotAfter सबसे आगे» चुनें। पुराना-नया parallel में नया certificate अपने आप सवार होता है। पर समान नाम unintended certificate पकड़ने का जोखिम, issuer पुष्टि और log साथ रखें। यह automatic सवारी दूसरे पक्ष को certificate pre-registration न चाहिए तब ही बनती है। Pre-registration चाहने API (5.2) पर import भर unrelated certificate पर स्वयं बदलकर संचार रुक सकता है; registration पूरा देखकर बदलने वाला config-बाहर तरीका ही रखें।
• Operations से बाँधें: किसी भी तरीके, start पर «कौन सा certificate (thumbprint, expiry) चुना» log में रखें। Failure जाँच और ledger मिलान दोनों में यही एक पंक्ति काम करती है।

8. Code signing certificates से संबंध — «Trusted Publishers» store

यहाँ तक संचार (TLS) certificates थे; certificate store में एक और संसार — code signing — साथ रहता है। 2.2 तालिका का «Trusted Publishers (TrustedPublisher)» store वह जोड़ है; signed software के publisher certificates trusted register करने का स्थान। User और computer दोनों स्थानों पर है¹⁰; internally distributed apps के publisher को GPO से प्रत्येक PC TrustedPublisher पर बाँटना जैसे operations में।

App «बाँटने वाले» पक्ष से code signing और SmartScreen warning («Windows protected your PC») का उपाय चाहिए हो तो अलग लेख «Windows पर «Windows protected your PC» क्यों आता है» में। इस लेख का ज्ञान (store दो परिवार, root distribution) ज्यों का त्यों पूर्वापेक्षा ज्ञान है।

9. सारांश

• Certificate store user (CurrentUser) और computer (LocalMachine) दो परिवार। certmgr.msc / certlm.msc / Cert: drive एक ही वस्तु की तीन खिड़कियाँ। जाँच का पहला कदम «किस store की बात» मिलाना।
• रखने का स्थान «program किसके रूप में चलता है» से। Unattended (service, IIS, task) computer store, interactive app user store मूल।
• «Development में चला, production पर नहीं मिला» developer user store और service account user store अलग होने से। Computer store + StoreLocation.LocalMachine मिलाकर हल।
• Computer store रखना और «Manage Private Keys» से read access एक सेट। Update पर access दोहराना न भूलें।
• pfx import default non-exportable। -Exportable सच में चाहिए तब ही। मूल pfx और password रखना भी design में शामिल करें।
• Expiry Get-ChildItem Cert: ... -ExpiringInDays नियमित inventory और certificate ledger से रोकें। बदलना «जोड़ → बदल → पुष्टि → मिटा» क्रम, config thumbprint update न छूटे।
• Chain isolation certutil -urlfetch -verify। Internal CA root GPO/Intune से बाँटें; self-signed root में रखना केवल verification वातावरण, expiry सहित।
• Code में thumbprint config में बाहर, चुना certificate log में रखें। इतने से certificate failure जवाब बदल जाता है।

संबंधित लेख

• Windows पर «Windows protected your PC» क्यों आता है
• Windows apps में secrets रखना — DPAPI से plaintext settings न रखें
• PowerShell में credentials का सुरक्षित व्यवहार — plaintext passwords script से निकालें
• HttpClient को using में न बाँधें — C# business apps HTTP संचार व्यवहार
• My Number स्वास्थ्य कार्ड झुकाने पर क्या होता है — online eligibility confirmation और Lesacon जोड़ ORCA source से

संबंधित परामर्श क्षेत्र

KomuraSoft LLC client certificates वाले Web API integration (bank API, online eligibility confirmation आदि) जुड़े business apps development, «certificate नहीं मिला» «update बाद connection नहीं» प्रकार failure जाँच, certificate renewal प्रक्रिया व्यवस्थित करना सँभालता है। Store कहाँ देखें पता नहीं — उतने चरण का परामर्श ठीक है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

certmgr.msc और certlm.msc में क्या अंतर है?

लक्ष्य store अलग है। certmgr.msc sign-in user का certificate store (Current User) खोलता है; certlm.msc computer का certificate store (Local Computer, LocalMachine) खोलता है। Computer store PC पर सब users और services के लिए shared है, management को admin rights चाहिए। जो admin नहीं वह केवल अपना user store manage कर सकता है। दोनों की सामग्री «Personal», «Trusted Root Certification Authorities» जैसे logical stores में बँटी है; PowerShell से Cert:\CurrentUser और Cert:\LocalMachine के रूप में वही structure दिखती है।

Client certificate user store में रखें या computer में?

वह certificate use करने वाला program «किसके रूप में» चलता है, उसी से तय करें। Interactive user चलाए desktop app हो तो use करने वाले व्यक्ति का user store (Cert:\CurrentUser\My) मूल है। Windows service, IIS application pool, Task Scheduler से unattended चलने वाले programs हो तो computer store (Cert:\LocalMachine\My) में रखें और execution account को private key read access दें। User store account-दर-account अलग है, इसलिए developer ने अपने user store में रखा certificate दूसरे account से चलती service से नहीं दिखता। यही «development में चला, production पर नहीं मिला» incident का classic कारण है।

Windows service से certificate नहीं मिलता या use नहीं होता — क्या जाँचें?

जाँच दो चरण। पहला «कौन सा store देख रहा है»। Code StoreLocation.CurrentUser खोल रहा हो तो वह service execution account का user store है, admin certmgr.msc से देखता अपना store नहीं। Certificate computer store में ले जाएँ, code भी StoreLocation.LocalMachine से मिलाएँ। दूसरा «private key पढ़ी जा सकती है?»। List में दिखना और private key use करना अलग हैं; computer store की private key default प्रायः केवल Administrators और SYSTEM पढ़ते हैं। certlm.msc से लक्ष्य certificate पर «Manage Private Keys» खोलकर service execution account (NETWORK SERVICE आदि) को «Read» दें।

Certificate expiry PowerShell से पहले कैसे पकड़ें?

Cert: drive पर Get-ChildItem से inventory बनती है। उदाहरण Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter से computer store के Personal store expiry क्रम में। -ExpiringInDays से «निर्दिष्ट दिनों में expire होने वाले» ही निकलते हैं; 0 दें तो expire हो चुके। इसे मासिक सब servers पर चलाकर परिणाम certificate ledger से मिलाएँ — «expiry से सुबह से connection नहीं» incident लगभग रुकती है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।