Creazione di un certificato o di una richiesta di certificato per TLS

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2011-11-04

In questo argomento, viene descritto come creare certificati o richieste certificato TLS (Transport Layer Security) X.509 utilizzando i cmdlet ExchangeCertificate in Exchange Management Shell.

In termini di crittografia, il certificato e le rispettive chiavi private generate dal cmdlet New-ExchangeCertificate rapprsentano chiavi TLS. Il cmdlet New-ExchangeCertificate consente di specificare i metadati relativi al certificato in modo da consentire a diversi servizi l'utilizzo dello stesso certificato e della stessa chiave. Prima di creare certificati o richieste certificato per i servizi Exchange che utilizzano il protocollo TLS, è necessario comprendere i metadati utilizzati dai certificati per i servizi SSL e TLS. Nel certificato risultante, i metadati sono definiti "campi".

Per visualizzare i campi relativi ai certificati del computer in un computer specifico, è possibile utilizzare il cmdlet Get-ExchangeCertificate in Exchange Management Shell. In alternativa, è possibile utilizzare lo snap-in Gestione certificati di Microsoft Management Console (MMC). Per ulteriori informazioni su come utilizzare lo snap-in Gestione certificati, vedere Come aggiungere Gestione certificati a MMC (Microsoft Management Console).

Informazioni sui campi utilizzati dai servizi certificati TLS

Se si utilizza il cmdlet New-ExchangeCertificate per generare una richiesta certificato da parte di una terza parte o di un'Autorità di certificazione (CA) di un'infrastruttura con chiave pubblica (PKI), è necessario convalidare i campi e il formato dei certificati che sono richiesti dalla CA.

In questa sezione, sono illustrati i campi di certificato più importanti e sono descritte alcune procedure consigliate per la generazione di certificati e di richieste certificato.

Nome soggetto

Il nome soggetto di un certificato TLS rappresenta il campo utilizzato dai servizi compatibili con DNS. Il campo del nome soggetto associa un certificato a un server o a un nome dominio particolare.

Un nome soggetto rappresenta un nome distinto X.500 costituito da uno o più nomi distinti relativi, noti come RDN. Nella tabella riportata di seguito, sono elencati i nomi distinti relativi utilizzati in genere nel caso dell'identificazione di organizzazioni o di entità server.

I codici Paese sono rappresentati da codici ISO 3166-1. Per ulteriori informazioni, vedere English country names and code elements.

Il Componente dominio e il Paese, per convenzione, si escludono reciprocamente. Si consiglia di fare riferimento al nome per Paese oppure per nome DNS (Domain Name System). Inoltre, è necessario tenere presente che la dimensione massima del Componente dominio (255 caratteri) corrisponde al totale di tutti i valori di componente dominio.

Implementazione dei nomi distinti relativi

I nomi soggetto sono rappresentati nel cmdlet New-ExchangeCertificate come un singolo parametro costituito da una serie di nomi separati da virgole. Ciascun nome è identificato dall'abbreviazione riguardante il nome distinto relativo. Ad esempio, il nome soggetto indicato di seguito rappresenta il Paese = US, l'Organizzazione = Contoso Corp e il Nome comune = mail1.contoso.com:

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

Di seguito, sono riportati altri esempi di nomi soggetto che rappresentano lo stesso server:

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

Se si dispone di un nome DNS registrato utilizzato per inviare posta SMTP, si consiglia di utilizzare la convenzione componente dominio e il nome DNS per il nome certificato, ad esempio DC=contoso, DC=com, CN=mail1.contoso.com.

Quando si genera una richiesta certificato per un provider CA, è tuttavia necessario comprendere i requistiti del campo nome soggetto della CA e le esigenze univoche della propria infrastruttura PKI. In alcuni casi, è possibile che sia necessario utilizzare il codice Paese ("C"). Se si verifica tale circostanza, è necessario registrare il proprio nome distinto relativo con un'autorità di registrazione X.500.

Nomi soggetto internazionali

Nel caso di nomi soggetto con caratteri non-ASCII, è possibile inserire il parametro SubjectName come nome distinto racchiuso tra virgolette, come nell'esempio riportato di seguito:

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Nomi soggetto e nomi dominio

Per convenzione, è possibile che in un nome comune sia presente un nome di dominio completo (FQDN) Anche se si tratta di una procedura diffusa e consigliata, è necessario comprendere i due problemi indicati di seguito.

Innanzitutto, la dimensione massima del campo del nome comune non supera i 64 caratteri e si tratta di un numero di caratteri inferiore a quello della dimensione massima di un FQDN. Di conseguenza, nel caso di FQDN con più di 64 caratteri, è necessario inserire il nome dominio nel nome soggetto alternativo. Il parametro DomainName rappresenta il parametro associato al nome soggetto alternativo nel certificato risultante.

Il secondo problema è rappresentato dalla restrizione del FQDN a un set secondario del set di caratteri ASCII. Tuttavia, il nome comune (CN) supporta la codifica Unicode. Di conseguenza, è possibile creare un certificato valido con un CN simile a un nome DNS, ma che non è un nome DNS valido. Un software che cerca un FQDN in un certificato CN non è in grado di restituire il risultato esatto se nel CN sono inclusi caratteri non ASCII. Ad esempio, se si crea un certificato con un nome soggetto in cui il nome comune è mail.mïcrosoft.com, il nome viene ignorato come FQDN perché contiene un carattere Unicode, ossia il carattere ï con il segno diacritico (x00ef). A occhio nudo, è possibile confondere facilmente il nome comune Unicode con un FQDN a causa della differenza minima tra il carattere ï con il segno diacritico (x00ef) e il carattere ASCII i (x0069). L'attività di certificato di Exchange non richiede o impone che il soggetto CN corrisponda a un FQDN valido. Per impostazione predefinita, ciò significa che il cmdlet include l'FQDN del server come nome comune predefinito.

Nomi dominio del certificato

Nel caso di TLS, è necessario che nei certificati siano presenti nomi DNS poiché il protocollo TLS si basa su DNS. I client verificano il nome DNS del server a cui si connettono con il nome DNS con cui prevedono di connettersi. Tale situazione si verifica nel caso di browser Web che si connettono al sito Web su HTTPS e nel caso di server SMTP che trasmettono la posta elettronica tramite Internet o intranet.

È possibile che un singolo server supporti più nomi DNS per i motivi indicati di seguito:

• un server SMTP supporta più domini accettati;

• un client può accedere a un server di posta elettronica tramite il nome server, il nome dominio, un nome FQDN locale oppure un nome con carico bilanciato.

Quando si stabilisce una connessione TLS, se il client trova il nome cercato, ignora gli altri nomi nel certificato. È possibile aggiungere più nomi dominio e nomi server nel campo nome soggetto alternativo di un certificato TLS. È possibile creare un certificato contenente più nomi soggetto alternativi utilizzando il parametro DomainName del cmdlet New-ExchangeCertificate. Il parametro DomainName consente l'inserimento di più valori e, quindi, accetta più nomi.

È possibile che i certificati X.509 contengano nessuno, uno o più nomi DNS nell'estensione certificato nome soggetto alternativo (SubjectAltName). I nomi DNS nell'estensione SubjectAltName corrispondono esattamente alle restrizioni di un nome DNS. È necessario che non superino i 255 caratteri e che siano costituiti da A-Z, a-z, 0-9 e un trattino (-).

Corrispondenza dei nomi per la funzionalità di protezione del dominio

Il metodo della corrispondenza dei nomi del certificato per la funzionalità di protezione del dominio controlla che un nome di dominio nel certificato ricevuto corrisponda al nome di dominio nel momento in cui invia posta elettronica a quello stesso dominio. Ai fini di questo esempio, si consideri il FQDN del dominio del destinatario, woodgrovebank.com.Il metodo della corrispondenza dei nomi del certificato cerca tra tutti i nomi DNS nei certificati e non appena un nome DNS corrisponde, il certificato viene verificato come corrispondente per il dominio specifico.

In questo esempio, il metodo di corrispondenza del certificato accetta un certificato con un'esatta corrispondenza di dominio, ad esempio woodgrovebank.com. Supporta inoltre l'utilizzo, nei certificati, di nomi di dominio con caratteri jolly in modo che un certificato con un nome DNS come *.woodgrovebank.com venga accettato come corrispondente. Per ulteriori informazioni sui nomi di dominio con caratteri jolly, vedere"Nomi di dominio con caratteri jolly" più avanti in questo argomento.

Il metodo della corrispondenza dei nomi del certificato cerca inoltre DNS con profondità di un nodo. Di conseguenza, anche mail1.woodgrovebank.com viene accettato come corrispondente per woodgrovebank.com.Tuttavia, i nomi DNS più profondi di due nodi non vengono accettati. Di conseguenza, mail1.us.woodgrovebank.com, ad esempio, non verrebbe accettato come corrispondente per woodgrovebank.com.

Per ulteriori informazioni sulla selezione dei certificati da parte di Exchange, vedere Selezione del certifcato TLS SMTP.

Procedure consigliate per i nomi dominio relativi a SMTP su Internet

Quando si crea un certificato o una richiesta certificato per un server Trasporto Edge che esegue TLS SMTP su Internet, è necessario includere nella richiesta l'insieme di nomi dominio riportato di seguito:

• Nome di dominio Internet completo del server   È possibile che sia diverso dall'FQDN interno utilizzato tra i server Trasporto Edge e Trasporto Hub ed è necessario che corrisponda al record A pubblicato nel server DNS Internet (pubblico). È necessario inserire tale nome come nome comune nel parametro SubjectName del cmdlet New-ExchangeCertificate.

• Tutti i nomi di dominio accettati dell'organizzazione   Utilizzare il parametro IncludeAcceptedDomain del cmdlet New-ExchangeCertificate per compilare il nome soggetto alternativo relativo al certificato risultante.

• L'FQDN relativo al connettore se non è stato applicato da nessun altro elemento   Utilizzare il parametro DomainName del cmdlet New-ExchangeCertificate per compilare il nome soggetto alternativo relativo al certificato risultante.

Procedure consigliate per i nomi dominio relativi a un server Accesso client

Quando si crea un certificato o una richiesta certificato per un server Accesso client, è necessario includere nella richiesta l'insieme di nomi dominio riportato di seguito:

• Nome locale o NetBIOS del server, ad esempio, owa1.

• Tutti i nomi dominio accettati per l'organizzazione, ad esempio, contoso.com.

• Il nome di dominio completo per il server, ad esempio, owa1.contoso.com

• Il nome dominio di individuazione automatica per il dominio, ad esempio, Autodiscover.contoso.com.

• L'identità di bilanciamento del traffico del server se utilizzata, ad esempio, owa.contoso.com.

Nomi dominio con caratteri jolly

I nomi dominio con caratteri jolly costituiscono uno speciale tipo di nome dominio che rappresenta più domini secondari. I nomi dominio con caratteri jolly consentono di semplificare i certificati poiché un singolo nome dominio con caratteri jolly rappresenta tutti i domini secondari relativi a tale dominio. Sono rappresentati da un carattere di asterisco ( * ) nel nodo DNS. Ad esempio, *.contoso.com rappresenta contoso.com e tutti i domini secondari relativi a contoso.com. Quando si utilizza un carattere jolly per creare un certificato o una richiesta certificato per tutti i domini accettati, è possibile semplificare significativamente la richiesta.

Clonazione di un certificato esistente

Exchange 2007 crea un certificato autofirmato durante l'installazione che utilizza tutti i nomi server e nomi dominio noti a Exchange al momento dell'installazione. Tali certificati restano validi per 12 mesi. In alcuni casi, risulta opportuno clonare questi certificati se è possibile utilizzare i nomi soggetto e i nomi soggetto alternativi per altri computer. È importante tenere presente che vengono clonati solo i metadati del certificato e non le serie di chiavi.

Per eseguire i cmdlet riportati di seguito su un computer in cui è installato il ruolo del server Trasporto Edge, è necessario accedere al sistema utilizzando un account che sia membro del gruppo Administrators locale del computer.

Per clonare un nuovo certificato da un certificato esistente, è necessario identificare innanzitutto il certificato corrente relativo al dominio, eseguendo il comando indicato di seguito:

Get-ExchangeCertificate -DomainName mail1.contoso.com

in cui mail1.contoso.com rappresenta il nome server o l'FQDN il cui certificato si desidera clonare.

Il primo certificato elencato nell'output rappresenta il certificato TLS SMTP per il server.

Per clonare il certificato, eseguire il comando indicato di seguito:

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

in cui il valore di Thumbprint deriva dal primo certificato elencato nell'output per Get-ExchangeCertificate.

Questo comando consente di estrarre i nomi dal certificato esistente identificati dall'identificazione personale e di utilizzarli nel nuovo certificato autofirmato.

Generazione di richieste per i Servizi certificati di terze parti

Se si utilizza una CA per generare certificati, è necessario fornire una richiesta certificato in base ai requisiti della CA.

Per generare una richiesta certificato, è possibile utilizzare il cmdlet New-ExchangeCertificate. Per generare una richiesta certificato, utilizzare il parametro GenerateRequest con il parametro Path per definire la posizione in cui creare il file di richiesta. Il file risultante è rappresentato da un file di richiesta PKCS #10 (REQ). PKCS #10 rappresenta lo standard di sintaasi della richiesta certificazione specificato dall'RFC 2314 (http://www.ietf.org/rfc/rfc2314.txt).

Gli esempi riportati di seguito illustrano alcune richieste certificato tipiche.

Il primo esempio genera una richiesta certificato per il server di Contoso, mail1. Il nome comune del nome soggetto include l'FQDN del server, mentre il nome soggetto alternativo include tutti i domini accettati per Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

Il secondo esempio genera una richiesta certificato per il server di Contoso, mail1. Contoso dispone di un connettore di invio in ciascun server Trasporto Edge il cui FQDN è mail.contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

Il terzo esempio crea una richiesta certificato da un certificato Contoso.com esistente.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

L'ultimo esempio descrive come creare una richiesta certificato con un carattere jolly per tutti i domini secondari di Contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

Per ulteriori esempi, vedere l'intervento nel blog del team di Microsoft Exchange, Lessons Learned: Generating a Certificate with a 3rd Party CA (informazioni in lingua inglese).

Installazione di certificati emessi da una richiesta certificato

Dopo l'invio di una richiesta certificato a una CA, questa emette un certificato o una catena di certificati. In entrambi i casi, i certificati vengono recapitati come file da installare con il cmdlet Import-ExchangeCertificate.

L'esempio riportato di seguito descrive come importare un certificato per il servizio TLS SMTP.

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

L'esempio successivo descrive come importare un certificato e abilitarlo per un server Accesso client che supporta client POP3 (Post Office Protocol versione 3).

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

Ulteriori informazioni

Per ulteriori informazioni sulle Autorità di certificazione che attualmente operano su siti Web specifici di Exchange, vedere l'articolo 929395 della Microsoft Knowledge Base, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007 (informazioni in lingua inglese).

Per ulteriori informazioni sulla crittografia e le tecnologie e i concetti relativi ai certificati, vedere le pubblicazioni indicate di seguito:

• Housley, Russ and Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Son, Inc., 2001.

• Adams, Carlisle and Steve Lloyd. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. New York: John Wiley & Son, Inc., 1996.

• Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure