Informazioni sui certificati TLS

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

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 in Microsoft Management Console (MMC).

Per informazioni sulle attività di gestione relative ai certificati TLS, Vedere Certificati.

Sommario

Campi utilizzati dai certificati per i servizi TLS

Selezione di un certificato

Creazione dei certificati TLS

Riferimenti

Campi utilizzati dai certificati per i servizi TLS

Se si utilizza il cmdlet New-ExchangeCertificate per generare una richiesta certificato da parte di un'Autorità di certificazione di un'infrastruttura a chiave pubblica (PKI) o di terze parti, è necessario convalidare i campi e il formato dei certificati richiesti dall'autorità di certificazione.

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 Nomi inglesi dei paesi ed elementi di codice (informazioni in lingua inglese).

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.

Definizione dei nomi distinti relativi

Quando si creano le richieste certificato utilizzando il cmdlet New-ExchangeCertificate, i nomi soggetto sono rappresentati 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 questa è una pratica diffusa, fare attenzione a questi due problemi.

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 di dominio nel nome alternativo del soggetto. Il parametro DomainName è il parametro associato al nome alternativo del soggetto 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à certificato di Exchange non richiede o impone che il nome comune del soggetto 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 sulla risoluzione 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 Web browser 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 che contiene più nomi alternativi del soggetto 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. Ad esempio, considerare 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 specificato.

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.

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 immettere questo nome come CN nel parametro SubjectName del cmdlet New-ExchangeCertificate.

• Tutti i nomi domini accettati dell'organizzazione   Utilizzare il parametro IncludeAcceptedDomains del cmdlet New-ExchangeCertificate per compilare il nome soggetto alternativo per il certificato risultante.

• Il nome di dominio completo 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 per il certificato risultante.

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 sottodomini per 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.

Selezione di un certificato

Exchange segue diversi processi di selezione certificati in base al tipo di connessione SMTP.

Quando i server Trasporto Hub comunicano fra loro o con i server Trasporto Edge nell'organizzazione, vengono utilizzati certificati TLS anonimi. Per ulteriori informazioni, vedere Selezione di certificati TLS anonimi in ingresso e Selezione di certificati TLS anonimi in uscita.

Quando un client o un host SMTP si connette ai server Trasporto Hub o Edge, viene utilizzato il processo di selezione certificati STARTTLS. Per ulteriori informazioni, vedere Selezione di certificati STARTTLS in ingresso.

Creazione dei certificati TLS

Exchange 2010 crea un certificato autofirmato durante l'installazione che utilizza tutti i nomi server e dominio noti a Exchange al momento dell'installazione. È possibile duplicare questo certificato per utilizzarlo in altri server. Inoltre, è possibile sostituire questo certificato con quelli rilasciati da un'autorità di certificazione di terze parti. Negli argomenti seguenti vengono fornite le istruzioni dettagliate per ogni attività.

• Generazione di richieste per i Servizi certificati di terze parti

• Installazione di certificati emessi per le richieste di certificato

• Clonazione di un certificato esistente

Riferimenti

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

• Sicurezza basata su certificati e PKI di Windows Server 2008 (le informazioni potrebbero essere in lingua inglese)

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

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

 ©2010 Microsoft Corporation. Tutti i diritti riservati.