KomuraSoft LLC
Contatti
Menu

Guida pratica all'archivio certificati di Windows — Utente o computer, dove metterlo?

· · Certificato, Windows, Sicurezza, PKI, TLS, PowerShell, Applicazioni aziendali, Sistemi informativi

«Nell’aggiornamento del terminale di verifica online dell’idoneità, dopo aver rimesso il certificato client sul PC nuovo non ci si collega più», «sulla macchina di sviluppo si arriva all’API della banca, ma una volta fatto servizio Windows dice «certificato non trovato»», «non si capisce quale sia quello vero, tra i certificati che si vedono in certmgr.msc e quelli che si vedono in certlm.msc» — Quando si fa, su commissione, un’integrazione Web API con certificato client, questo tipo di richiesta arriva con regolarità.

Verifica online dell’idoneità nelle strutture sanitarie, domanda elettronica, API bancarie, EDI con i partner. I certificati client, un tempo toccati solo dai responsabili di infrastruttura delle grandi aziende, oggi li trattano il personale IT delle PMI e gli sviluppatori di app aziendali. E gli incidenti intorno ai certificati, in realtà, si concentrano in pochi schemi. Sbagliare il posto in cui metterlo, dimenticare i permessi della chiave privata, dimenticare la scadenza — questi tre.

Questo articolo è rivolto agli sviluppatori di app aziendali che usano certificati client e al personale IT a cui è affidato il lavoro di sostituzione dei certificati. Con asse il giudizio «archivio utente o archivio del computer», organizza in un colpo solo dalla struttura dell’archivio certificati di Windows, alla concessione dei permessi sulla chiave privata, all’inventario delle scadenze con PowerShell, fino al codice di uso da .NET. Il contenuto si basa su fonti primarie di Microsoft Learn ad agosto 2026.

1. Prima di tutto, la conclusione

  • L’archivio certificati di Windows è in due famiglie: «utente (CurrentUser)» e «computer (LocalMachine)». L’archivio utente è una cosa distinta per ciascun account (sotto HKEY_CURRENT_USER nel Registro), l’archivio del computer è comune a tutto il PC (sotto HKEY_LOCAL_MACHINE).12
  • Anche gli strumenti di gestione sono due. certmgr.msc apre l’archivio dell’utente corrente, certlm.msc quello del computer locale. Da PowerShell sono Cert:\CurrentUser e Cert:\LocalMachine.34
  • Dove metterlo lo si decide in base a «chi è il programma che usa quel certificato». Per un’app di un utente interattivo l’archivio utente, per un’esecuzione non presidiata di servizio Windows, IIS, Task Scheduler l’archivio del computer è il principio (tabella di decisione del capitolo 3).
  • La causa di «in sviluppo funzionava, una volta fatto servizio non si trova» è quasi una sola. Un certificato che lo sviluppatore ha messo nel proprio archivio utente non si vede dal CurrentUser di un servizio che gira con un altro account (capitolo 3).
  • Certificato e chiave privata sono cose distinte. Metterlo nell’archivio del computer non basta: di solito l’account del servizio non può leggere la chiave privata. Si concede il permesso di lettura all’account di esecuzione con «Gestisci chiavi private» di certlm.msc.5
  • All’importazione di un pfx, la chiave privata per default non è esportabile. Import-PfxCertificate importa in una forma in cui la chiave privata non si può riesportare, a meno di specificare -Exportable. Non è un incidente: è il valore predefinito desiderabile.6
  • La scadenza si previene con l’automazione dell’inventario. Si possono estrarre in modo meccanico i certificati che scadono entro i giorni specificati, come Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 60.4
  • Se si mette in hardcode l’impronta (thumbprint) nel codice o nella configurazione, a ogni rinnovo del certificato muore. Un certificato nuovo ha necessariamente un’impronta diversa. Esternalizzare la configurazione + un periodo di parallelismo vecchio/nuovo è la base della progettazione (capitoli 5 e 7).

Mappa della conoscenza di questo articolo

L’archivio certificati di Windows è in due famiglie, utente (CurrentUser) e computer (LocalMachine), e dove mettere un certificato client lo decide «chi è il programma che gira». Un servizio Windows eseguito senza presidio è un insieme di archivio del computer e concessione dei permessi sulla chiave privata; la scadenza del certificato e l’impronta in hardcode sono le cause classiche dei guasti di connessione da certificato.

Mappa della conoscenza della guida pratica all'archivio certificati di WindowsDiagramma che mostra le relazioni tra archivio certificati (utente/computer), certificato client, chiave privata, catena di certificati, CA radice e CA intermedia, scadenza e impronta e i guasti di connessione, procedura di sostituzione, registro e rischio dei certificati auto-firmatiusarichiederichiederichiederichiedepuò causarepuò causareverificato daconfigurato daconfigurato daverificato daverificato daverificato daverificato dasalvato inverificato dasalvato inusasalvato inconfigurato daprevieneprevienepuò causaresconsigliato persconsigliato perconsigliato pereredita il contenuto disalvato inpuò causareusarichiedeusapuò causaresconsigliato perrichiededeve precedereusamitigarichiedeconsigliato perconsigliato perArchivio certificatiCertificato clientServizio WindowsArchivio certificati del computerChiave privataPermessi di accesso alla chiave privataCatena di certificatiCertificato CA intermedioCertificato CA radiceScadenza del certificatoGuasto di connessione da certificatoHardcode dell'improntaCriteri di gruppoMicrosoft IntuneArchivio certificati dell'utentecertmgr.msccertlm.mscUnità Cert:File PFXcertutilCertificato di firma del codiceArchivio Editori attendibiliApp desktop dell'utente interattivoSostituzione del certificatoRegistro dei certificatiCertificato auto-firmato ad hocRischio di abuso del punto di partenza della fiduciaSelezione (ricerca) del certificatoArchivio «Personale» (My)Scambio di archivioPool di applicazioni IISEsecuzione non presidiata di Task SchedulerImportazione come esportabileRischio di fuoriuscita della chiave privataConcessione del controllo completo a EveryoneRegistrazione preventiva del certificato presso la contropartePassaggio al certificato nuovoClasse X509StoreRicerca di certificati con validOnlyAttributo Key UsageEsternalizzazione dell'impronta nella configurazioneOutput a registro del certificato scelto

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 41, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Panoramica dell’archivio certificati — Due luoghi e archivi logici

2.1. Le due famiglie: utente e computer

L’archivio certificati di Windows si divide in due grandi «luoghi».1

  • Archivio certificati del computer (computer locale, LocalMachine): uno per quel PC, comune a tutti gli utenti e servizi sul PC. L’entità è sotto HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates nel Registro.2
  • Archivio certificati dell’utente (utente corrente, CurrentUser): una cosa distinta per ciascun account utente. L’entità è sotto HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, cioè una parte del profilo utente.2

C’è anche un archivio per account di servizio3, e l’entità è una chiave di Registro per nome di servizio.2 Ciò che in pratica va fissato per primo sono i primi due.

C’è una specifica importante. Ciascun archivio logico dell’archivio utente, escluso «Personale», eredita e mostra il contenuto dell’archivio omonimo dell’archivio del computer.1 Per esempio, se mettete il certificato di una CA interna in «Autorità di certificazione radice attendibili» dell’archivio del computer, quel certificato compare anche in «Autorità di certificazione radice attendibili» di tutti gli utenti. Detto al contrario, solo l’archivio «Personale» non viene ereditato, quindi un certificato client (ciò che si mette nell’archivio Personale) dovete decidere da soli «da chi deve essere visibile». Questa asimmetria è il protagonista di tutto l’articolo.

Archivio del computer e archivio dell'utenteL'archivio del computer è uno per PC e comune a tutti gli utenti e servizi, l'archivio dell'utente è una cosa distinta per ciascun account e, salvo Personale, eredita e mostra il contenuto del computerUtente (CurrentUser)una cosa distinta per ciascun accountComputer (LocalMachine)uno per PC, comune a tutti gli utenti e servizisi vede ereditando il contenutoereditaereditaPersonale (My)non ereditato = si decide da soli dove metterloAutorità di certificazione radice attendibili (Root)Autorità di certificazione intermedie (CA)Editori attendibili (TrustedPublisher)Personale (My)Autorità di certificazione radice attendibili (Root)Autorità di certificazione intermedie (CA)Editori attendibili (TrustedPublisher)

Figura 1: L’archivio dell’utente, salvo Personale, eredita e mostra il contenuto dell’archivio del computer; dove mettere i certificati client lo si decide da soli.

2.2. I principali archivi logici

All’interno di ciascun luogo, il contenuto è diviso in archivi logici per ruolo. Sono le cartelle che si vedono in certmgr.msc / certlm.msc; da PowerShell o da riga di comando si usa il nome interno in inglese.24

Nome visualizzato Nome interno Che cosa ci si mette
Personale My Certificati usati da sé (questo PC, questo utente). Certificati client e certificati server stanno qui. Qui si associa anche la chiave privata
Autorità di certificazione radice attendibili Root Certificati CA radice che sono il punto di partenza della fiducia. Ciò che sta sotto una CA messa qui «è attendibile»
Autorità di certificazione intermedie CA Certificati CA intermedi che collegano radice e foglia. Materiale per costruire la catena
Editori attendibili TrustedPublisher Certificati che si considerano attendibili come emittente di software firmato (capitolo 8)

2.3. Tre finestre sullo stesso archivio — certmgr.msc / certlm.msc / unità Cert:

Ci sono tre mezzi per guardare lo stesso archivio.34

  • certmgr.msc: console di gestione che apre l’archivio dell’utente corrente.
  • certlm.msc: console di gestione che apre l’archivio del computer locale.
  • Unità Cert: di PowerShell: si può operare sull’archivio come su un file system, nella gerarchia Cert:\CurrentUser\... e Cert:\LocalMachine\.... I certificati si identificano per impronta.

Se aggiungete a mano lo snap-in Certificati a mmc.exe, scegliete il bersaglio tra tre tipi: «Account utente», «Account computer», «Account servizio». Un utente che non è amministratore può gestire solo l’archivio del proprio account utente.3

Il primo passo di un’indagine di problema è far coincidere «quale archivio sta guardando l’app» e «quale archivio state guardando voi». Indagare l’incidente di un servizio guardando certmgr.msc non dà mai una risposta, perché il posto che si guarda è diverso.

3. Dove metterlo — Tabella di decisione secondo la forma di esecuzione del programma

Il criterio di giudizio è uno. Con l’account di chi gira il programma che usa quel certificato?

Forma di esecuzione Account di esecuzione Archivio in cui metterlo Note
App desktop avviata da un utente interattivo L’utente connesso in persona Utente (Cert:\CurrentUser\My) Serve un’introduzione per ciascun account di chi lo usa. Se su un PC condiviso lo usano più persone, si considera anche l’archivio del computer
Servizio Windows LocalSystem / NETWORK SERVICE / account di servizio dedicato Computer (Cert:\LocalMachine\My) Per chi non è LocalSystem (NETWORK SERVICE, account dedicato ecc.) è obbligatoria la concessione del permesso di lettura della chiave privata (capitolo 4). LocalSystem legge con il permesso SYSTEM predefinito
App Web su IIS Identità del pool di applicazioni Computer Come sopra
Esecuzione non presidiata di Task Scheduler (esegui indipendentemente dall’accesso dell’utente) Account specificato nell’attività Computer raccomandato Si può far girare anche nell’archivio utente dell’account di esecuzione, ma aumenta solo la verifica di visibilità di profilo e archivio, con pochi vantaggi
Domanda elettronica e autenticazione Web nel browser L’utente connesso in persona Utente Naturale anche nel senso di non farlo usare a nessuno oltre a chi lo ha ricevuto

Se esitati, ciò che gira senza presidio è l’archivio del computer, ciò che opera una persona è l’archivio utente.

3.1. Anatomia dell’incidente classico — «In sviluppo funzionava, una volta fatto servizio non si trova»

Questo incidente si riproduce con precisione con i passi seguenti.

  1. Lo sviluppatore, sul proprio PC, importa il pfx con un doppio clic. Il predefinito della procedura guidata è «utente corrente», quindi il certificato entra nell’archivio utente dell’account dello sviluppatore.
  2. L’app in sviluppo gira da Visual Studio, cioè con l’account dello sviluppatore, quindi aprendo StoreLocation.CurrentUser il certificato si trova. Funziona.
  3. Sul server di produzione si registra come servizio Windows. Il servizio gira con NETWORK SERVICE o con un account dedicato.
  4. Il CurrentUser che apre il codice del servizio è l’archivio utente dell’account di esecuzione del servizio. Lì è vuoto. «Certificato non trovato».
In sviluppo funzionava, una volta fatto servizio non si trovaUn certificato messo nell'archivio utente dello sviluppatore non è visibile dal CurrentUser di un servizio che gira con un altro accountServer di produzioneMacchina di svilupposi colloca lo stesso programmaIl CurrentUser che apre il codice èl'archivio utente dell'account del servizioRegistrazione come servizio Windowsl'account di esecuzione è NETWORK SERVICE ecc.Lì è vuoto→ «certificato non trovato»Entra nell'archivio utentedell'account dello sviluppatoreImportazione del pfx con doppio clicil predefinito della procedura guidata è «utente corrente»Esecuzione da Visual Studio= gira con l'account dello sviluppatoreAprendo CurrentUser si trova→ funziona

Figura 2: L’archivio utente dello sviluppatore e quello dell’account di servizio sono distinti; funzionare in sviluppo non garantisce di trovarlo in produzione.

Il punto è che l’archivio utente «esiste in tanti esemplari quanti sono gli account». Anche se l’amministratore apre certmgr.msc e conferma «c’è, no?», quello è l’archivio dell’amministratore stesso, non l’archivio dell’account del servizio. La correzione non è una copia improvvisata: è metterlo di nuovo nell’archivio del computer e allineare anche il codice a StoreLocation.LocalMachine. E fino alla concessione dei permessi del capitolo successivo è un insieme.

4. Chiave privata e diritti di accesso — Il secondo incidente classico

4.1. Certificato e chiave privata sono cose distinte

Ciò che si vede nell’elenco dell’archivio certificati è il certificato (informazione pubblica), non la chiave privata in sé. Nell’autenticazione client ciò che serve davvero è il trattamento di firma con la chiave privata, quindi «si vede in elenco» e «si può usare» sono problemi distinti. Se si confondono, si arriva a incidenti poco leggibili all’occhio: «il certificato c’è ma l’handshake TLS fallisce», «esce un errore interno di famiglia Access Denied».

4.2. La pratica dell’importazione pfx — L’esportabilità è una decisione

La coppia certificato e chiave privata si passa in un file pfx (PKCS #12) e si importa nell’archivio con Import-PfxCertificate.6

$pwd = Get-Credential -UserName '(inserire la password sotto)' -Message 'Password del PFX'
Import-PfxCertificate -FilePath C:\certs\client.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd.Password

Qui l’importante è il comportamento predefinito: finché non aggiungete -Exportable, la chiave privata importata non si può riesportare.6 Mettere tutto come esportabile «per poterlo migrare dopo» è aggiungere un percorso di fuoriuscita della chiave privata. Fate un’operazione in cui conservate in sicurezza il pfx originale, e sull’archivio la chiave privata non esportabile è la base — questa è la nostra raccomandazione. Inoltre, proprio la conservazione del pfx originale e della sua password tende a essere lasciata in chiaro. Il modo di pensarla è organizzato in «Memorizzazione di segreti nelle app Windows: evitare la configurazione in testo normale con DPAPI» e «Gestire le credenziali in modo sicuro in PowerShell».

4.3. Concedere i permessi sulla chiave privata all’account di servizio

Sulla chiave privata di un certificato messo nell’archivio del computer, per default, di solito non possono leggere se non amministratori e SYSTEM. Per questo un servizio che gira con LocalSystem legge la chiave privata così com’è, ma se gira con un account diverso — NETWORK SERVICE, account di servizio dedicato, identità del pool di applicazioni IIS — si concede in modo esplicito il permesso di lettura all’account di esecuzione. La procedura si fa dall’interfaccia dello snap-in Certificati.5

  1. Aprite certlm.msc (o lo snap-in Certificati con bersaglio account computer).
  2. In «Personale» → «Certificati», clic destro sul certificato di destinazione e, da «Tutte le attività», aprite «Gestisci chiavi private».
  3. Nella scheda «Sicurezza» aggiungete l’account di esecuzione (NETWORK SERVICE, account di servizio dedicato, identità del pool di applicazioni IIS, ecc.) e consentite «Lettura».5

Il controllo completo non serve. Se si usa solo per firmare, la lettura basta. Al contrario, concedere a Everyone il controllo completo perché «non funziona» è abbassare la chiave privata a un trattamento da password in chiaro: evitatelo in assoluto. Collocare nell’archivio del computer e concedere i permessi sulla chiave privata sono sempre un insieme — scrivetelo nella procedura, e questa famiglia di incidenti sparisce.

5. Prevenire gli incidenti di scadenza — Inventario, sostituzione, registro

5.1. Fare inventario con PowerShell

La data di scadenza del certificato sta nella proprietà NotAfter. Si fa inventario in modo meccanico con Get-ChildItem sull’unità Cert:.4

# Elencare «Personale» dell'archivio del computer in ordine di scadenza
Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter |
    Format-Table Thumbprint, Subject, NotAfter

# Estrarre solo ciò che scade entro 60 giorni (0 dà i già scaduti)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 60

-ExpiringInDays è il parametro che restituisce «i certificati che scadono entro i giorni specificati»; 0 dà i certificati già scaduti.4 Fatene un’attività pianificata mensile su tutti i server e concentrate il risultato in una mail o in un registro — da solo, gli incidenti del tipo «scaduto, e dal lunedì mattina la verifica dell’idoneità non passa» si prevengono quasi del tutto.

5.2. La procedura di sostituzione — Il periodo di parallelismo e la trappola dell’impronta

Il rinnovo di un certificato non è «eliminare e mettere» ma «aggiungere, poi passare, confermare e poi togliere».

  1. Importate il certificato nuovo (pfx) nello stesso archivio. L’impronta è diversa, quindi vecchio e nuovo possono coesistere nello stesso archivio.
  2. Concedete i permessi sulla chiave privata del certificato nuovo (capitolo 4). In aggiornamento, ciò che si dimentica facilmente è qui. I permessi sono per ciascuna chiave privata del certificato, quindi se sostituite il certificato rifate anche la concessione.
  3. La comunicazione al sistema di destinazione (se l’API richiede la registrazione preventiva del certificato) si fa prima, continuando a operare con il certificato vecchio, e si assicura un periodo di parallelismo in cui si accettano sia il vecchio sia il nuovo. Se passate prima, il lato di destinazione rifiuta il certificato nuovo e la comunicazione di produzione si ferma.
  4. Passate la configurazione dell’app al certificato nuovo e confermate il funzionamento.
  5. Dopo un periodo sufficiente, eliminate il certificato vecchio.
Il rinnovo del certificato si fa aggiungendo e poi passandoSi mette il pfx nuovo nello stesso archivio, si concedono i permessi, si registra in anticipo presso la controparte, poi si passa l'impronta e dopo il periodo di parallelismo si elimina il certificato vecchio1. Importare il pfx nuovonello stesso archivio (coesistenza vecchio/nuovo)2. Concedere i permessi sullachiave privata del certificato nuovo3. Registrazione preventiva presso la controparte(si continua a operare con il certificato vecchio)4. Riscrivere l'impronta della configurazione,passare e confermare il funzionamento5. Dopo il periodo di parallelismoeliminare il certificato vecchio

Figura 3: La sostituzione del certificato è nell’ordine aggiungere → permessi → registrazione preventiva → cambiare la configurazione → eliminare il vecchio; non dimenticate l’aggiornamento dell’impronta.

In quell’occasione la trappola più grande è l’impronta scritta in un file di configurazione o nel codice. L’impronta è univoca per ciascun certificato, quindi se rinnovate cambia per forza. Se anche un solo posto resta a riferire la vecchia impronta, succede «il certificato l’abbiamo rinnovato, ma non ci si collega». Il modo sicuro è gestire a registro dove è scritta l’impronta (configurazione dell’app, binding IIS, script, comunicazione alla controparte).

5.3. Perché tenere un registro dei certificati

Registro, ma per cominciare basta un foglio Excel. Come minimo fate le colonne uso / emittente / soggetto / impronta / posto in cui sta (nome del server + archivio) / account che ha i permessi sulla chiave privata / scadenza / collegamento alla procedura di rinnovo / responsabile, e confrontatele con il risultato dell’inventario di 5.1. La realtà degli incidenti da certificato non è un problema di tecnica: è il problema «nessuno ha un elenco», quindi il registro è ciò che funziona di più.

6. Verifica e lettura dei fallimenti — Catena e distribuzione della radice

6.1. Basi della verifica di catena e certutil

Un errore di famiglia «questo certificato non è attendibile» è lo stato in cui la catena (percorso di certificazione) dalla foglia alla CA radice è rotta da qualche parte. Per il triage è comodo certutil.7

Tre cause classiche in cui si interrompe la verifica di catenaL'errore di fiducia nasce da una di tre cause classiche: la CA intermedia non si ottiene, la radice non è stata distribuita, o la foglia è scadutanon si ottiene(né presentazione, né AIA, né archivio)non è stato distribuitoscadutoCertificato foglia(certificato client, certificato server)Certificato CA intermedioposto: archivio Autorità di certificazione intermedie (CA)Certificato CA radiceposto: Autorità di certificazione radice attendibili (Root)La catena non si può costruire(causa classica 1)Errore «non è attendibile»(causa classica 2)Errore di periodo di validità(causa classica 3)

Figura 4: La catena si interrompe se manca la CA intermedia o la radice, o per il periodo di validità; lo strato si determina con certutil.

:: Costruire e verificare la catena di un file di certificato (con ottenimento URL della verifica di revoca)
certutil -urlfetch -verify client.cer

:: Se l'app di destinazione usa l'archivio utente, verificare nello stesso contesto con -user
certutil -user -urlfetch -verify client.cer

:: Fare il dump del contenuto dell'archivio (con -user è l'archivio utente)
certutil -store My
certutil -user -store My

certutil -verify verifica certificato, CRL e catena e, se non si specifica CACertFile, costruisce e verifica una catena completa.7 L’output è lungo, ma si legge a quale strato si è rotta la fiducia e se si ottengono le informazioni di revoca. Le cause tipiche sono tre: (1) il certificato CA intermedio non si ottiene (la controparte TLS non lo invia, non si ottiene nemmeno dalle informazioni AIA del certificato, e non è nemmeno nell’archivio «Autorità di certificazione intermedie»); (2) la radice della CA interna non è distribuita in «Autorità di certificazione radice attendibili»; (3) la scadenza del certificato stesso. La CA intermedia si risolve anche con la presentazione dalla controparte o con l’ottenimento automatico via AIA, quindi collocarla nell’archivio va visto come «uno dei mezzi per renderlo certo».

6.2. La distribuzione della radice di una CA interna o di un auto-firmato è con GPO/Intune

Se usate una CA interna o un certificato auto-firmato per verifica, dovete distribuire quel certificato radice a ciascun PC. Non lo mettete a mano uno per uno: lo caricate sul meccanismo di distribuzione.

  • Ambiente Active Directory (GPO): se importate il certificato in «Autorità di certificazione radice attendibili» sotto Configurazione computer\Criteri\Impostazioni di Windows\Impostazioni di sicurezza\Criteri chiave pubblica dei Criteri di gruppo, viene distribuito ai PC di destinazione.8
  • Ambiente gestito con Intune: si distribuiscono certificati CA radice/intermedi con un profilo «Certificato attendibile». Su Windows si può scegliere l’archivio di destinazione (radice/intermedio del computer, intermedio dell’utente).9

Come detto in 2.1, se lo mettete nella radice dell’archivio del computer, è attendibile per tutti gli utenti.1 Proprio per questo va guardato in faccia anche il rischio inverso. Un’operazione che mette un certificato auto-firmato in «Autorità di certificazione radice attendibili» è piantare su quel PC un nuovo punto di partenza della fiducia. Se quella chiave privata fuoriesce, diventa il piede per emettere certificati che si spacciano per qualunque sito o software. Se la rendete permanente, la linea è alzare una CA interna con la chiave privata protetta in modo adeguato, o avvicinarsi a un certificato di una CA pubblica; una radice auto-firmata per principio è «limitata all’ambiente di verifica, con scadenza».

7. Il punto di vista dello sviluppatore — Usare correttamente l’archivio da .NET

7.1. Cercare per impronta con X509Store

Da .NET si apre l’archivio con X509Store e si ottiene il certificato con Find.1011

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(
            $"Certificato non trovato: impronta={thumbprint}, " +
            $"luogo={store.Location}\\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"Il certificato c'è ma la chiave privata non è associata (importazione " +
            $"da .cer ecc.): impronta={thumbprint}, luogo={store.Location}\\{store.Name}");

    return cert;
}

Il giudizio del capitolo 3 si collega direttamente qui. Codice che gira come servizio: StoreLocation.LocalMachine; app interattiva: StoreLocation.CurrentUser. Un’altra cosa: attenzione al terzo argomento validOnly di Find. true restituisce solo i certificati validi che hanno passato la verifica.11 È un’assicurazione per non prendere un certificato scaduto; d’altra parte anche un certificato auto-firmato di test la cui catena non è attendibile cade dal lato «non trovato», quindi quando «c’è ma non si trova» sospettate anche qui. Inoltre, nel messaggio di errore quando non si trova, mettete sempre quale archivio avete cercato, come nell’esempio sopra. Il tempo di indagine dell’incidente del capitolo 3 cambia di un ordine di grandezza.

7.2. Caricare un certificato client su HttpClient

Il certificato ottenuto si aggiunge a HttpClientHandler.ClientCertificates e si presenta al server. Questa raccolta è l’insieme dei certificati presentati al server nell’autenticazione client basata su certificato.12

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

var client = new HttpClient(handler);
// Da qui si usa come un HttpClient ordinario

Inoltre, in .NET Core e successive, se il certificato ha un attributo Key Usage, è documentato che se non include «Digital Signature» non viene usato per l’invio della richiesta.12 Se vi trovate nella posizione di chiedere l’emissione di un certificato client, comunicate correttamente l’uso (autenticazione client). Inoltre HttpClient, se si sbaglia il pattern di creazione, provoca esaurimento dei socket e problemi di inseguimento DNS. Il progetto di rendere longevo anche il gestore è come in «Non racchiudere HttpClient in un using».

7.3. Il problema dell’impronta in hardcode che muore alla sostituzione

La ricerca per impronta è certa, ma se incorporate l’impronta nel codice a ogni rinnovo del certificato servono build e rilascio. La correzione in progettazione è in tre tappe.

  • Il minimo: esternalizzare l’impronta in un file di configurazione (appsettings ecc.) e poterla sostituire senza un rilascio. Il punto di configurazione va sul registro di 5.3.
  • Un passo avanti: cercare per nome del soggetto o emittente, combinare con validOnly: true e scegliere «tra quelli attualmente validi con quel nome, quello con NotAfter più lontano». Nel periodo di parallelismo vecchio/nuovo passa da solo al certificato nuovo. C’è però il rischio di prendere un certificato omonimo non voluto, quindi si mettono in coppia la conferma dell’emittente e l’output a registro. Inoltre questo passaggio automatico si regge solo se la controparte non richiede la registrazione preventiva del certificato. In un’API che richiede la registrazione preventiva (5.2), potrebbe passare da sola a un certificato appena importato e non ancora registrato e fermare la comunicazione, quindi restate sul modo di esternalizzazione della configurazione, passando dopo aver confermato il completamento della registrazione.
  • Chiudere in operazione: in qualunque modo, all’avvio lasciate a registro «quale certificato (impronta, scadenza) avete scelto». Sia in indagine di incidente sia nel confronto con il registro, questa riga funziona.

8. Il rapporto con i certificati di firma del codice — L’archivio «Editori attendibili»

Fin qui abbiamo trattato i certificati per la comunicazione (TLS), ma nell’archivio certificati coabita un altro mondo — la firma del codice. L’archivio «Editori attendibili (TrustedPublisher)» uscito nella tabella di 2.2 è il punto di contatto: è il posto in cui si registra come attendibile il certificato dell’emittente di software firmato. Esiste sia nel luogo utente sia in quello del computer10, e si usa in un’operazione in cui si distribuisce con GPO l’emittente di un’app distribuita internamente nel TrustedPublisher di ciascun PC.

Se, come «lato che distribuisce» l’app, avete bisogno di affrontare la firma del codice o l’avviso SmartScreen («Windows ha protetto il PC»), è in un altro articolo, «Perché Windows mostra «Windows ha protetto il PC»». Le conoscenze di questo articolo (le due famiglie di archivio, la distribuzione della radice) si usano così com’è come premesse.

9. Conclusione

  • L’archivio certificati è in due famiglie, utente (CurrentUser) e computer (LocalMachine). certmgr.msc / certlm.msc / unità Cert: sono tre finestre sullo stesso. Il primo passo di un’indagine è allineare «di quale archivio si sta parlando».
  • Dove metterlo lo si decide in base a «chi è il programma». L’esecuzione non presidiata (servizio, IIS, attività) è l’archivio del computer, l’app interattiva è l’archivio utente, per principio.
  • «In sviluppo funzionava, in produzione non si trova» ha come causa il fatto che l’archivio utente dello sviluppatore e l’archivio utente dell’account del servizio sono cose distinte. Si risolve allineando a archivio del computer + StoreLocation.LocalMachine.
  • Collocare nell’archivio del computer e concedere il permesso di lettura in «Gestisci chiavi private» sono un insieme. Non dimenticate di rifare la concessione in aggiornamento.
  • L’importazione pfx per default non è esportabile. -Exportable solo quando serve davvero. Includete nella progettazione anche la conservazione del pfx originale e della password.
  • La scadenza si previene con l’inventario periodico di Get-ChildItem Cert: ... -ExpiringInDays e con il registro dei certificati. La sostituzione è nell’ordine «aggiungere → passare → confermare → eliminare», attenzione alle impronte in configurazione non aggiornate.
  • Il triage della catena è certutil -urlfetch -verify. La radice di una CA interna si distribuisce con GPO/Intune, e un’operazione che mette un auto-firmato nella radice è limitata all’ambiente di verifica, con scadenza.
  • Nel codice esternalizzate l’impronta nella configurazione e lasciate a registro il certificato scelto. Da solo, la gestione degli incidenti da certificato cambia viso.

Articoli correlati

Aree di consulenza correlate

KomuraSoft LLC si occupa dello sviluppo di app aziendali che incorporano integrazioni Web API con certificato client (API bancarie, verifica online dell’idoneità ecc.), dell’indagine di incidenti del tipo «certificato non trovato» o «dopo il rinnovo non ci si collega», e dell’allestimento della procedura di sostituzione dei certificati. Si può partire da uno stadio del tipo «non sappiamo dove guardare nell’archivio».

Riferimenti

  1. Microsoft Learn, Local Machine and Current User Certificate Stores. Sul fatto che l’archivio certificati del computer è locale rispetto al PC, comune a tutti gli utenti e sta sotto HKEY_LOCAL_MACHINE; sul fatto che l’archivio certificati dell’utente è per ciascun account utente e sta sotto HKEY_CURRENT_USER; sul fatto che l’archivio utente, escluso l’archivio «Personale», eredita il contenuto dell’archivio del computer (un certificato aggiunto in «Autorità di certificazione radice attendibili» del computer compare anche nello stesso archivio di ciascun utente). ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, System Store Locations. Sulla posizione nel Registro di CERT_SYSTEM_STORE_CURRENT_USER / CERT_SYSTEM_STORE_LOCAL_MACHINE (rispettivamente Software\Microsoft\SystemCertificates sotto HKEY_CURRENT_USER / HKEY_LOCAL_MACHINE); sul fatto che gli archivi logici predefiniti sono MY, Root, Trust, CA; sul fatto che l’archivio per servizio sta in una chiave di Registro per nome di servizio (Software\Microsoft\Cryptography\Services\ServiceName\SystemCertificates); sul fatto che esiste a parte un archivio per la distribuzione con i Criteri di gruppo. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, How to: View certificates with the MMC snap-in. Sul fatto che certlm.msc gestisce i certificati del dispositivo locale (computer locale) e certmgr.msc quelli dell’utente corrente; sul fatto che i bersagli dello snap-in Certificati sono tre tipi, «account computer», «account utente», «account servizio»; sul fatto che un utente che non è amministratore può gestire solo i certificati del proprio account utente. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, about_Certificate_Provider. Sul fatto che l’unità Cert: di PowerShell è uno spazio di nomi gerarchico con due luoghi di archivio, CurrentUser e LocalMachine; sul fatto che con Get-ChildItem si possono enumerare archivi e certificati; sul fatto che il parametro -ExpiringInDays restituisce i certificati che scadono entro i giorni specificati (0 = già scaduti); sui parametri dinamici come -CodeSigningCert; sul fatto che la data di scadenza sta nella proprietà NotAfter; sul fatto che i certificati si identificano per impronta. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Microsoft Learn, How to Modify Private Key Permissions to Support Management Server or Streaming Server. Sulla procedura di aprire «Gestisci chiavi private» (Manage Private Keys) nello snap-in Certificati con bersaglio l’archivio certificati del computer locale, e nella scheda «Sicurezza» aggiungere all’account di esecuzione del servizio (es. Network Service) il permesso di accesso «Lettura». ↩ ↩2 ↩3

  6. Microsoft Learn, Import-PfxCertificate. Sul fatto che Import-PfxCertificate importa da un file PFX certificato e chiave privata nell’archivio specificato; sul fatto che se non si specifica l’interruttore -Exportable la chiave privata importata non si può esportare; sulla sintassi e gli esempi d’uso dei parametri -CertStoreLocation, -Password, -FilePath. ↩ ↩2 ↩3

  7. Microsoft Learn, certutil. Sul fatto che certutil -verify verifica certificato, CRL e catena di certificati e, se non si specifica un file di certificato CA, costruisce e verifica una catena completa; sul fatto che è disponibile l’opzione -urlfetch; sul fatto che certutil -store fa il dump dell’archivio certificati e con l’opzione -user accede all’archivio utente al posto di quello del computer. ↩ ↩2

  8. Microsoft Learn, Distribute Certificates to Client Computers by Using Group Policy. Sulla procedura di importare un certificato in «Autorità di certificazione radice attendibili» sotto «Configurazione computer\Criteri\Impostazioni di Windows\Impostazioni di sicurezza\Criteri chiave pubblica» dei Criteri di gruppo e distribuirlo ai computer client nel dominio; sui permessi necessari (equivalenti a Domain Admins / Enterprise Admins). ↩

  9. Microsoft Learn, Create trusted certificate profiles in Microsoft Intune. Sul fatto che il profilo «Certificato attendibile» di Intune è il meccanismo che distribuisce certificati CA radice o intermedi ai dispositivi gestiti; sul fatto che si usa per stabilire la fiducia nella CA radice come premessa dei profili di certificato SCEP/PKCS; sul fatto che su Windows si può scegliere come archivio di destinazione «Archivio certificati computer - Radice», «Archivio certificati computer - Intermedio», «Archivio certificati utente - Intermedio». ↩

  10. Microsoft Learn, X509Store Class. Sul fatto che X509Store si può costruire specificando StoreName e StoreLocation (CurrentUser / LocalMachine), si apre l’archivio con il metodo Open e OpenFlags (ReadOnly, OpenExistingOnly ecc.), e si ottiene la raccolta di certificati con la proprietà Certificates; sul fatto che i nomi di archivio standard includono My, Root, CA, TrustedPublisher ecc., e l’archivio TrustedPublisher esiste sia in CurrentUser sia in LocalMachine. ↩ ↩2

  11. Microsoft Learn, X509Certificate2Collection.Find(X509FindType, Object, Boolean) Method. Sul fatto che il metodo Find cerca certificati con X509FindType (FindByThumbprint ecc.) e un valore di ricerca; sul fatto che se il terzo argomento validOnly è true vengono restituiti solo i certificati validi che hanno passato la verifica. ↩ ↩2

  12. Microsoft Learn, HttpClientHandler.ClientCertificates Property. Sul fatto che la proprietà ClientCertificates è una X509CertificateCollection presentata al server nell’autenticazione client basata su certificato; sul fatto che in .NET Core, se il certificato ha un attributo Key Usage, deve includere «Digital Signature». ↩ ↩2

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Qual è la differenza tra certmgr.msc e certlm.msc?
Il bersaglio dell'archivio è diverso. certmgr.msc apre l'archivio certificati dell'utente attualmente connesso (utente corrente, CurrentUser); certlm.msc apre l'archivio certificati del computer (computer locale, LocalMachine). L'archivio del computer è comune a tutti gli utenti e servizi sul PC, e per gestirlo servono i privilegi di amministratore. Un utente che non è amministratore può gestire solo il proprio archivio utente. In entrambi i casi il contenuto è diviso in archivi logici come «Personale» e «Autorità di certificazione radice attendibili», e da PowerShell si vede la stessa struttura come Cert:\CurrentUser e Cert:\LocalMachine.
Un certificato client va nell'archivio utente o in quello del computer?
Lo si decide in base a «chi» è il programma che usa il certificato. Per un'app desktop avviata da un utente interattivo, la base è l'archivio utente di chi lo usa (Cert:\CurrentUser\My). Per un programma eseguito senza presidio — servizio Windows, pool di applicazioni IIS, Task Scheduler — lo si mette nell'archivio del computer (Cert:\LocalMachine\My) e si concede all'account di esecuzione il permesso di lettura della chiave privata. L'archivio utente è una cosa distinta per ciascun account, quindi un certificato che uno sviluppatore ha messo nel proprio archivio utente non è visibile a un servizio che gira con un altro account. Questa è la causa classica di «in sviluppo funzionava, in produzione non si trova».
Cosa confermare quando un servizio Windows non trova o non può usare un certificato?
La conferma è in due tappe. Prima: «quale archivio sta guardando». Se il codice apre StoreLocation.CurrentUser, quello è l'archivio utente dell'account di esecuzione del servizio, distinto dall'archivio che l'amministratore sta guardando con certmgr.msc. Si sposta il certificato nell'archivio del computer e si allinea anche il codice a StoreLocation.LocalMachine. Seconda: «si può leggere la chiave privata». Vedere il certificato in elenco e poter usare la chiave privata sono cose distinte; sulla chiave privata dell'archivio del computer, per default, di solito possono accedere solo amministratori e SYSTEM. Da certlm.msc, sul certificato di destinazione, aprite «Gestisci chiavi private» e concedete «Lettura» all'account di esecuzione del servizio (NETWORK SERVICE ecc.).
Come trovare in anticipo con PowerShell la scadenza di un certificato?
Si fa inventario con Get-ChildItem sull'unità Cert:. Per esempio, Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter elenca l'archivio Personale dell'archivio del computer in ordine di scadenza. Con il parametro -ExpiringInDays si estraggono solo «i certificati che scadono entro i giorni specificati»; 0 dà i certificati già scaduti. Se ne fate un'operazione mensile su tutti i server e confrontate il risultato con il registro dei certificati, gli incidenti del tipo «scaduto, e da stamattina non ci si collega» si prevengono quasi del tutto.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Contattaci
Torna al blog