Utilizzo dei certificati
Per programmare le funzionalità di protezione di Windows Communication Foundation (WCF) in genere si utilizzano i certificati digitali X.509. In particolare, questi certificati vengono utilizzati per autenticare client e server nonché per codificare e firmare digitalmente i messaggi. Questo argomento fornisce una breve descrizione delle funzionalità relative ai certificati e illustra come utilizzarle in WCF. Questo argomento contiene inoltre i collegamenti agli argomenti che trattano questi concetti in modo più dettagliato o che descrivono come eseguire attività comuni tramite l'utilizzo di WCF e dei certificati.
In breve, un certificato digitale è un componente dell'infrastruttura a chiave pubblica (PKI, Public Key Infrastructure). Questa infrastruttura è un sistema di certificati digitali, autorità di certificazione e altre autorità di registrazione che verificano e autenticano la validità di ogni parte coinvolta in una transazione elettronica basata sull'utilizzo di crittografia a chiave pubblica. Ogni certificato viene rilasciato da un'autorità di certificazione e presenta un insieme di campi che contengono determinati dati, ad esempio soggetto (l'entità alla quale viene rilasciato il certificato), date di validità, autorità emittente e chiave pubblica. In WCF, ognuna di queste proprietà viene elaborata come un'attestazione Claim. Esistono due tipi di attestazioni: di identità e di diritto. Per ulteriori informazioni, vedere Gestione di attestazioni e autorizzazioni con il modello di identità. Per ulteriori informazioni sull'implementazione di un'infrastruttura PKI, vedere Procedure consigliate per implementare un'infrastruttura PKI Microsoft Windows Server 2003 (il contenuto potrebbe essere in inglese).
Una delle funzionalità principali di un certificato è consentire l'autenticazione dell'identità del soggetto presso altre entità. Un certificato contiene inoltre la chiave pubblica associata alla chiave privata del soggetto. Chiunque può utilizzare la chiave pubblica per crittografare un messaggio. Tuttavia, per decrittografare tale messaggio, sono necessarie entrambe le chiavi. Pertanto, solo chi possiede la chiave privata è in grado di decrittografare il messaggio. La chiave pubblica può essere utilizzata per crittografare i messaggi destinati al proprietario del certificato. In quanto unico detentore della chiave privata, solo il proprietario è in grado di decrittografare questi messaggi.
I certificati devono essere rilasciati da un autorità di certificazione, che spesso è un'emittente di certificati di terze parti. Nei domini Windows è disponibile un'autorità di certificazione utilizzabile per rilasciare certificati ai computer appartenenti al dominio.
Per ulteriori informazioni sui certificati, vedere il documento informativo sui certificati (la pagina potrebbe essere in inglese).
Visualizzazione dei certificati
Quando si utilizzano i certificati, spesso è necessario visualizzarli e analizzarne le proprietà. A tale scopo è possibile ricorrere allo snap-in Microsoft Management Console (MMC), uno strumento di facile utilizzo. Per ulteriori informazioni, vedere Procedura: visualizzare certificati con lo snap-in MMC. Nella Panoramica di Httpcfg sono contenuti documenti aggiuntivi relativi alle procedure di utilizzo di questo strumento (il contenuto potrebbe essere in inglese).
Archivi certificati
I certificati vengono memorizzati in appositi archivi. Sono disponibili due posizioni principali di archiviazione, ognuna delle quali è composta da più sottoarchivi. Gli amministratori di un computer possono visualizzare entrambi gli archivi principali mediante lo snap-in MMC. Gli altri utenti, invece, sono in grado di visualizzare soltanto l'archivio utente corrente.
- Archivio locale del computer: contiene i certificati utilizzati dai processi del computer, ad esempio ASP.NET. Utilizzare questa posizione per archiviare i certificati utilizzati per l'autenticazione del server presso i client.
- Archivio dell'utente corrente: questa posizione in genere viene utilizzata dalle applicazioni interattive per memorizzare i certificati relativi all'utente corrente del computer. Se si crea un'applicazione client, utilizzare questa posizione per archiviare i certificati utilizzati per l'autenticazione degli utenti presso un servizio.
Ognuno di questi due archivi è composto da più sottoarchivi. Segue l'elenco di alcuni dei sottoarchivi più importanti quando si programma in WCF:
Autorità di certificazione radice attendibili: i certificati contenuti in questo archivio possono essere utilizzati per creare una catena di certificati che consente di risalire a un certificato di autorità di certificazione di questo archivio.
Nota
Il computer locale considera implicitamente attendibile qualsiasi certificato memorizzato in questo archivio, anche se il certificato non è stato rilasciato da un autorità di certificazione di terze parti attendibile. È pertanto necessario garantire che questo archivio contenga soltanto certificati rilasciati da emittenti completamente attendibili, nonché comprendere quali problemi possono verificarsi qualora questa indicazione non venga rispettata.
Personale: questo archivio viene utilizzato per i certificati associati a un utente di un computer. In genere questo archivio viene utilizzato per memorizzare i certificati rilasciati mediante uno dei certificati di autorità di certificazione contenuti nell'archivio Autorità di certificazione radice attendibili. In alternativa, questo archivio può contenere certificati autocertificati ritenuti attendibili da un'applicazione.
Per ulteriori informazioni sugli archivi certificati, vedere il documento relativo agli archivi certificati (la pagina potrebbe essere in inglese).
Scelta di un archivio
La scelta della posizione in cui archiviare un certificato dipende dalla modalità di esecuzione del servizio o del client. In particolare, la scelta si basa sulle regole di carattere generale seguenti:
- Se il servizio è un servizio Windows, ovvero un servizio privo di interfaccia utente in esecuzione in un account Servizio di rete in modalità "server", utilizzare l'archivio computer locale. Si noti che per memorizzare certificati in questo archivio è necessario disporre dei privilegi di amministratore.
- Se il servizio o il client è incorporato in un'applicazione in esecuzione in un account utente, utilizzare l'archivio utente corrente.
Accesso agli archivi
Analogamente alle cartelle di un computer, anche gli archivi vengono protetti tramite gli elenchi di controllo di accesso (ACL, Access Control List). Quando si crea un servizio ospitato in Internet Information Services (IIS), il processo ASP.NET è in esecuzione nell'account ASP.NET. Tale account deve essere autorizzato ad accedere all'archivio contenente i certificati utilizzati da un servizio. Ogni archivio principale viene protetto mediante un ACL predefinito, che tuttavia può essere modificato. Se si crea un ruolo a parte per accedere a un archivio, a tale ruolo è necessario concedere l'autorizzazione di accesso. Per informazioni su come modificare l'ACL mediante lo strumento WinHttpCertConfig.exe, vedere Procedura: creare certificati temporanei da utilizzare durante lo sviluppo. Per ulteriori informazioni sull'utilizzo di certificati client in IIS, vedere la procedura per chiamare un servizio Web utilizzando un certificato client come credenziale di autenticazione in un'applicazione Web ASP.NET (la pagina potrebbe essere in inglese).
Catena di trust e autorità di certificazione
I certificati digitali vengono utilizzati per autenticare un'entità basandosi su una catena di trust. Tale catena è composta da una gerarchia di elementi, il cui livello massimo è rappresentato da un'autorità radice. Lo snap-in MMC consente di visualizzare la catena di qualsiasi certificato. A tale scopo, fare doppio clic sul certificato desiderato e quindi sulla scheda Percorso certificato. Il certificato dell'autorità radice all'inizio di una catena di certificati è autocertificato. Ciò significa che l'emittente e il soggetto a cui viene rilasciato il certificato sono la stessa entità. Per ulteriori informazioni sull'importazione di catene di certificati di un'autorità di certificazione, vedere Procedura: specificare la catena di certificati di autorità di certificazione utilizzata per verificare le firme (WCF).
Nota
Qualsiasi emittente può essere definito come un'autorità radice attendibile. A tale scopo, aggiungere il certificato di tale emittente nell'archivio Autorità di certificazione radice attendibili.
Disattivazione della catena di trust
Quando si crea un nuovo servizio è possibile che si utilizzi un certificato che non è stato rilasciato tramite un certificato radice attendibile oppure che il certificato emittente non sia contenuto nell'archivio Autorità di certificazione radice attendibili. In questo caso, e solo per scopi di sviluppo, è possibile disattivare temporaneamente il meccanismo che verifica la catena di trust di un certificato. A tale scopo, impostare la proprietà CertificateValidationMode su PeerTrust oppure su PeerOrChainTrust. Queste modalità specificano rispettivamente che il certificato può essere autocertificato (trust peer) o appartenere a una catena di trust. Questa proprietà può essere impostata in una qualsiasi delle classi seguenti:
La proprietà può anche essere impostata in configurazione. Gli elementi seguenti vengono utilizzati per specificare la modalità di convalida:
- <authentication> of <serviceCertificate> Element
- <peerAuthentication> Element
- <messageSenderAuthentication> element
Autenticazione personalizzata
La proprietà CertificateValidationMode consente inoltre di personalizzare la modalità di autenticazione dei certificati. Per impostazione predefinita, il livello è impostato su ChainTrust. Per utilizzare il valore Custom è necessario impostare anche l'attributo CustomCertificateValidatorType sull'assembly e sul tipo utilizzati per convalidare il certificato. Per creare una convalida personalizzata è necessario ereditare una classe dalla classe astratta X509CertificateValidator.
Quando si crea un autenticatore personalizzato è fondamentale eseguire l'override del metodo Validate. Per un esempio di autenticazione personalizzata, vedere l'esempio X.509 Certificate Validator. Per ulteriori informazioni, vedere Credenziale personalizzata e convalida della credenziale.
Utilizzo dello strumento Makecert.exe per creare una catena di certificati
Lo strumento di creazione dei certificati Makecert.exe crea certificati X.509 e coppie di chiavi privata/pubblica. La chiave privata può essere salvata su disco e quindi utilizzata per rilasciare e firmare nuovi certificati, simulando in questo modo una gerarchia di certificati concatenati. Questo strumento deve essere utilizzato esclusivamente come risorsa ausiliare durante la fase di sviluppo dei servizi. È pertanto necessario evitare di utilizzarlo per creare i certificati da utilizzare nella distribuzione definitiva. Quando si sviluppa un servizio WCF, attenersi ai passaggi seguenti per creare una catena di trust tramite lo strumento Makecert.exe.
Per creare una catena di trust tramite lo strumento Makecert.exe
Utilizzare lo strumento MakeCert.exe per creare un certificato temporaneo dell'autorità radice (autofirmato). Salvare la chiave privata su disco.
Utilizzare il nuovo certificato per rilasciare un altro certificato contenente la chiave pubblica.
Importare il certificato dell'autorità radice nell'archivio Autorità di certificazione radice attendibili.
Per istruzioni dettagliate, vedere Procedura: creare certificati temporanei da utilizzare durante lo sviluppo.
Scelta del certificato da utilizzare
Quando si utilizzano i certificati spesso sorgono dubbi su quale certificato scegliere e sul motivo per cui sceglierlo. La soluzione a questi dubbi varia a seconda che la programmazione riguardi un client o un servizio. Le informazioni seguenti rappresentano una linea guida generale e non forniscono una risposta esauriente a questi dubbi.
Certificati di servizio
Lo scopo principale dei certificati di servizio è autenticare il server presso i client. Uno dei primi controlli svolti durante l'autenticazione di un server presso un client consiste nel confrontare il valore del campo Soggetto con l'Uniform Resource Identifier (URI) utilizzato per contattare il servizio. In particolare, è necessario che i DNS di entrambi corrispondano fra loro. Ad esempio, se l'URI del servizio è "https://www.contoso.com/endpoint/", anche il campo Soggetto deve contenere il valore "www.contoso.com."
Si noti che il campo può contenere più valori, ognuno avente un prefisso iniziale che ne indica il valore. Nella maggior parte dei casi viene utilizzato il prefisso iniziale "CN" per indicare un nome comune. Ad esempio, "CN = www.contoso.com". È inoltre possibile che il campo Soggetto sia vuoto. In tal caso, il campo Nome alternativo soggetto può contenere il valore Nome DNS.
Si noti inoltre che il valore del campo Scopi designati del certificato deve includere un valore appropriato, ad esempio "Autenticazione server" o "Autenticazione client".
Certificati client
Anziché essere rilasciati da un'autorità di certificazione di terze parti, in genere i certificati client vengono memorizzati da un'autorità radice nell'archivio Personale dell'utente corrente. Il campo Scopi designati in questo caso viene impostato su "Autenticazione client". Un client può utilizzare un certificato client quando è necessario eseguire l'autenticazione reciproca.
Revoca in linea e revoca non in linea
Validità del certificato
Ogni certificato è valido solo per un determinato periodo di tempo, detto periodo di validità. Il periodo di validità è definito in base ai campi Valido dal e Valido fino al di un certificato X.509. Durante l'autenticazione questi due campi vengono verificati per stabilire se il certificato è nel periodo di validità.
Elenco di revoche di certificati (CRL, Certificate Revocation List)
Durante il periodo di validità, l'autorità di certificazione può revocare un certificato in qualsiasi momento. Ciò può verificarsi per vari motivi, ad esempio se la chiave privata del certificato viene compromessa.
In questo caso, tutti i certificati appartenenti alle catene di trust aventi origine dal certificato revocato sono anch'essi considerati non validi e durante le procedure di autenticazione vengono considerati non attendibili. Per determinare quali certificati sono stati revocati, ogni emittente pubblica un elenco di revoche di certificati (CRL, Certificate Revocation List) dotato di timestamp e datestamp. Questo elenco può essere controllato tramite la revoca in linea oppure la revoca non in linea impostando la proprietà RevocationMode o la proprietà DefaultRevocationMode delle classi seguenti su uno dei valori dell'enumerazione X509RevocationMode: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication e IssuedTokenServiceCredential. Il valore predefinito di tutte le proprietà è Online.
La modalità può inoltre essere impostata in configurazione tramite l'attributo revocationMode sia dell'<authentication> of <clientCertificate> Element (della serviceBehaviors section) sia dell'<authentication> of <clientCertificate> Element (della endpointBehaviors section).
Metodo SetCertificate
In WCF spesso occorre specificare un certificato o un insieme di certificati che un servizio o un client deve utilizzare per autenticare, crittografare o firmare digitalmente un messaggio. Questa operazione può essere eseguita a livello di programmazione mediante il metodo SetCertificate di varie classi che rappresentano i certificati X.509. Le classi seguenti utilizzano il metodo SetCertificate per specificare un certificato.
| Classe | Metodo |
|---|---|
Il metodo SetCertificate si basa sulla definizione di una posizione di archivio, di un archivio, di un tipo "di ricerca" (ovvero il parametro x509FindType )" che specifica un campo del certificato e un valore da ricercare nel campo. Ad esempio, nel codice seguente viene creata un'istanza della classe ServiceHost e viene utilizzato il metodo SetCertificate per impostare il certificato del servizio utilizzato per autenticare il servizio presso i client.
Certificati aventi lo stesso valore
Un archivio può contenere più certificati aventi lo stesso nome del soggetto. Ciò significa che se si imposta il tipo x509FindType su FindBySubjectName o su FindBySubjectDistinguishedName e più di un certificato presenta lo stesso valore, viene generata un'eccezione. Infatti, in tal caso, non esiste alcun modo per individuare univocamente il certificato richiesto. Per risolvere questo problema, impostare la proprietà x509FindType su FindByThumbprint. Il campo dell'identificazione personale ("Thumbprint") contiene infatti un valore univoco che può essere utilizzato per individuare un certificato specifico all'interno di un archivio. Tuttavia, ciò comporta uno svantaggio: se il certificato viene revocato o rinnovato, il metodo SetCertificate ha esito negativo poiché in questi casi l'identificazione personale viene rispettivamente eliminata o alterata. Oppure, se il certificato non è più valido, l'autenticazione ha esito negativo. Per risolvere questo problema è possibile impostare il parametro x590FindType su FindByIssuerName e specificare quindi nome dell'emittente. Se non è richiesto alcun emittente specifico, è anche possibile impostare uno degli altri valori dell'enumerazione X509FindType, ad esempio FindByTimeValid.
Impostazione dei certificati in configurazione
I certificati possono anche essere impostati in configurazione. Se si crea un servizio, le credenziali, compresi i certificati, vengono specificate nella serviceBehaviors section. Quando si programma un client, i certificati vengono specificati nella endpointBehaviors section.
Mapping di un certificato a un account utente
Una funzionalità di IIS e di Active Directory è la possibilità di eseguire il mapping di un certificato a un account utente di Windows. Per ulteriori informazioni su questa funzionalità, vedere il documento sul mapping dei certificati agli account utente (la pagina potrebbe essere in inglese).
Per ulteriori informazioni sull'utilizzo della funzionalità di mapping di Active Directory, vedere Mapping di certificati client tramite il mapping del servizio directory (la pagina potrebbe essere in inglese).
Se questa funzionalità è attiva è possibile impostare la proprietà MapClientCertificateToWindowsAccount della classe X509ClientCertificateAuthentication su true. In configurazione è possibile impostare l'attributo mapClientCertificateToWindowsAccount dell'elemento <authentication> su true, come mostrato nel codice seguente.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
L'esecuzione del mapping di un certificato X.509 al token che rappresenta un account utente di Windows è considerata un'elevazione dei privilegi perché, una volta eseguito tale mapping, il token di Windows può essere utilizzato per accedere alle risorse protette. Pertanto, il criterio del dominio richiede che il certificato X.509 sia conforme al proprio criterio prima di eseguire il mapping. Il pacchetto di protezione SChannel applica questo requisito.
Quando si utilizza .NET Framework versione 3.5 o versioni successive, WCF garantisce che il certificato sia conforme al criterio di dominio prima che venga mappato a un account di Windows.
Nella prima versione di WCF il mapping viene eseguito senza prendere in considerazione il criterio del dominio. È pertanto possibile che le applicazioni che funzionano correttamente con la prima versione presentano problemi se il mapping viene attivato e il certificato X.509 non soddisfà il criterio del dominio.
Vedere anche
Riferimenti
System.ServiceModel.Channels
System.ServiceModel.Security
System.ServiceModel
X509FindType