Uso dei certificati
Per programmare le funzionalità di sicurezza di Windows Communication Foundation (WCF) in genere si usano i certificati digitali X.509. In particolare, questi certificati vengono usati per autenticare client e server, nonché per crittografare e firmare digitalmente i messaggi. Questo argomento fornisce una breve descrizione delle funzionalità relative ai certificati digitali X.509 e illustra come usarle 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'uso 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'uso di crittografia a chiave pubblica. Ogni certificato viene rilasciato da un'autorità di certificazione e presenta un set di campi che contengono determinati dati, ad esempio soggetto (l'entità alla quale viene rilasciato il certificato), date di validità (il periodo di validità del certificato), autorità emittente (l'entità che ha emesso il certificato) 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 altre informazioni sui certificati X.509, vedere Certificati di chiave pubblica X.509. Per altre informazioni sulle attestazioni e l'autorizzazione in WCF, vedere Gestione di attestazioni e autorizzazioni con il modello di identità. Per altre informazioni sull'implementazione di un'infrastruttura a chiave pubblica (PKI), vedere Enterprise PKI con Windows Server 2012 R2 Active Directory Certificate Services.
La funzione principale di un certificato è consentire l'autenticazione dell'identità del proprietario del certificato presso altre entità. Un certificato contiene la chiave pubblicadel proprietario, mentre il proprietario conserva la chiave privata. La chiave pubblica può essere utilizzata per crittografare i messaggi inviati 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.
Visualizzare i 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 altre informazioni, vedere Procedura: Visualizzare certificati con lo snap-in MMC.
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 a cui accedono i 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. Di seguito sono elencati 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.
Importante
Il computer locale considera implicitamente attendibile qualsiasi certificato posizionato 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 i certificati rilasciati mediante uno dei certificati di autorità di certificazione contenuti nell'archivio Autorità di certificazione radice disponibile nell'elenco locale. In alternativa, questo archivio può contenere certificati autocertificati ritenuti attendibili da un'applicazione.
Per altre informazioni sugli archivi certificati, vedere Archivi certificati.
Selezionare 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 WCF è ospitato in un servizio Windows, usare l'archivio del computer locale. Si noti che per memorizzare certificati in questo archivio è necessario disporre dei privilegi di amministratore.
Se il servizio o il client è un'applicazione in esecuzione con un account utente, usare l'archivio utente corrente.
Accedere ad 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 da Internet Information Services (IIS), il processo di ASP.NET viene eseguito con l'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'elenco di accesso tramite lo strumento WinHttpCertConfig.exe, vedere Procedura: creare certificati temporanei da usare durante lo sviluppo.
Concatenare l'attendibilità e le autorità di certificazione
I certificati vengono creati in una gerarchia dove ogni singolo certificato è collegato alla CA che ha emesso il certificato. Questo collegamento è per il certificato della CA. Il certificato della CA collega quindi la CA che ha emesso il certificato della CA originale. Questo processo si ripete fino a raggiungere il certificato della CA radice. Il certificato della CA radice è considerato naturalmente attendibile.
I certificati digitali vengono usati per autenticare un'entità basandosi su una catena di trust. 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. Per altre informazioni sull'importazione di catene di certificati per un'autorità di certificazione, vedere Procedura: specificare la catena di certificati di autorità di certificazione usata per verificare le firme.
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.
Disabilitare l'attendibilità della catena
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 disabilitare 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:
Autenticazione personalizzata
La proprietà CertificateValidationMode consente inoltre di personalizzare la modalità di autenticazione dei certificati. Per impostazione predefinita, il livello è impostato su ChainTrust. Per usare il valore Custom è necessario impostare anche l'attributo CustomCertificateValidatorType sull'assembly e sul tipo usati per convalidare il certificato. Per creare un validator personalizzato è 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 Validator del certificato X.509. Per altre informazioni, vedere Credenziale personalizzata e convalida della credenziale.
Usare il cmdlet New-SelfSignedCertificate di PowerShell per compilare una catena di certificati
Il cmdlet New-SelfSignedCertificate di PowerShell crea certificati X.509 e coppie di chiavi private/chiave 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 cmdlet deve essere usato esclusivamente come risorsa ausiliare durante la fase di sviluppo dei servizi. È pertanto necessario evitare di usarlo per creare i certificati da usare nella distribuzione definitiva. Quando si sviluppa un servizio WCF, seguire questa procedura per creare una catena di trust con il cmdlet New-SelfSignedCertificate.
Creare un certificato di autorità radice temporanea (autofirmato) usando il cmdlet New-SelfSignedCertificate. 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 usare durante lo sviluppo.
Quale certificato usare?
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) usato per contattare il servizio. In particolare, è necessario che i DNS di entrambi corrispondano fra loro. Ad esempio, se l'URI del servizio è "http://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 usato 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". Il client può usare tali certificati quando è necessaria l'autenticazione reciproca.
Revoca online e revoca offline
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 online oppure la revoca offline 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 nella configurazione tramite l'attributo revocationMode sia di <autenticazione> (di <serviceBehaviors>) che di <autenticazione> (di <endpointBehaviors>).
Metodo SetCertificate
In WCF spesso occorre specificare un certificato o un set di certificati che un servizio o un client deve usare 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.
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 usato il metodo SetCertificate per impostare il certificato del servizio usato per autenticare il servizio presso i client.
Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
Più certificati con 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 FindBySubjectDistinguishedName e più certificati dispongono dello stesso valore, viene generata un'eccezione. Infatti, non esiste alcun modo per distinguere quale 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.
Certificati nella configurazione
I certificati possono anche essere impostati in configurazione. Se si crea un servizio, le credenziali, compresi i certificati, vengono specificate in <serviceBehaviors>. Quando si programma un client, i certificati vengono specificati in <endpointBehaviors>.
Eseguire il 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 altre informazioni sulla funzionalità, vedere la pagina relativa al mapping dei certificati agli account utente.
Per altre informazioni sull'uso della funzionalità di mapping di Active Directory, vedere Mapping di certificati client con il mapping del servizio directory.
Se questa funzionalità è abilitata è possibile impostare la proprietà MapClientCertificateToWindowsAccount della classe X509ClientCertificateAuthentication su true. Nella configurazione è possibile impostare su > l'attributo mapClientCertificateToWindowsAccount dell'elemento <authenticationtrue, 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 sicurezza SChannel applica questo requisito.
Quando si usa .NET Framework 3.5 o versioni successive, WCF garantisce che il certificato sia conforme ai criteri di dominio prima che venga eseguito il mapping 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 abilitato e il certificato X.509 non soddisfa il criterio del dominio.