Utilizzo di protezione dominio: Configurazione di Mutual TLS

 

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

Ultima modifica dell'argomento: 2009-12-07

In questo argomento viene descritto come configurare autenticazione reciproca TLS (Transport Layer Security) per la protezione di dominio in Microsoft Exchange Server 2010e Microsoft Office Outlook 2007 che fornisce un'alternativa relativamente economica a S/MIME e ad altre soluzioni di protezione a livello dei messaggi.

A scopo illustrativo, in questo argomento viene descritto come gli amministratori di Exchange di una società fittizia, la Contoso, configurano l'ambiente Exchange 2010 per lo scambio della posta con dominio protetto con il socio fittizio Woodgrove Bank. Gli amministratori di Contoso desiderano garantire la protezione di tutta la posta inviata e ricevuta da Woodgrove Bank con il TLS reciproco. Inoltre, Contoso desidera configurare la funzionalità Protezione del dominio per rifiutare tutta la posta per e da Woodgrove Bank se non è possibile utilizzare il TLS reciproco.

Contoso dispone di un'infrastruttura a chiave pubblica (PKI) interna che genera certificati. Il certificato principale della PKI è stato firmato da un'autorità di certificazione (CA) di terze parti principale. Woodgrove Bank utilizza la stessa CA di terze parti per generare i propri certificati. Pertanto, sia Contoso che Woodgrove Bank considerano rispettivamente attendibili le CA principali.

Per impostare il TLS reciproco, gli amministratori Exchange di Contoso eseguono le procedure indicate di seguito:

Passo 1: Generazione di una richiesta certificato relativa ai certificati TLS

Passo 2: Importazione di certificati nei server Trasporto Edge

Passo 3: Configurazione della protezione del dominio in uscita

Passo 4: Configurazione della protezione del dominio in ingresso

Passo 5: Verifica del flusso di posta con dominio protetto

Prerequisiti

  • Questo argomento presuppone la lettura e la comprensione di Generazione di richieste per i Servizi certificati di terze parti.

  • È necessario che il servizio EdgeSync di Microsoft Exchange sia implementato interamente per la protezione dominio. In genere, è consigliabile che le modifiche di configurazione della funzionalità Protezione dominio che non utilizza i cmdlet ExchangeCertificate siano apportate all'interno dell'organizzazione e sincronizzate con i server Trasporto Edge, utilizzando il servizio EdgeSync di Microsoft Exchange.

  • Prima che sia possibile eseguire correttamente il TLS reciproco in un server Trasporto Edge, è necessario configurare il computer e l'ambiente della PKI per rendere operativi la convalida del certificato e il controllo dell'elenco dei certificati revocati. Per ulteriori informazioni, vedere Utilizzo di PKI sul server Trasporto Edge per la protezione del dominio.

  • Anche se è possibile effettuare i singoli passi della configurazione all'interno di questo ambito con minori privilegi, per completare tutte le attività dall'inizio alla fine, è necessario che l'account utilizzato sia un membro del gruppo di ruoli Gestione organizzazione.

Passo 1: Generazione di una richiesta certificato relativa ai certificati TLS

Contoso dispone di una PKI interna subordinata a un'autorità di certificazione di terze parti. In tale scenario, la subordinazione fa riferimento al fatto che la CA implementata da Contoso nell'infrastruttura centrale contiene un certificato principale firmato da una CA pubblica di terzi. Per impostazione predefinita, la CA pubblica di terze parti rappresenta uno dei certificati principali attendibili nell'archivio certificati di Microsoft Windows. Pertanto, qualsiasi client che include la stessa CA di terzi nell'archivio principale attendibile e che si connette a Contoso può autenticare il certificato presentato da Contoso.

Contoso dispone di due server Trasporto Edge che richiedono i certificati TLS, mail1.contoso.com e mail2.mail.contoso.com. Pertanto, è necessario che l'amministratore della posta di Contoso generi due richieste di certificato, ciascuna per ognuno dei server.

La procedura descritta di seguito illustra il comando utilizzato dall'amministratore per generare una richiesta di certificato in formato PKCS#10 codificato in base allo standard base64.

L'amministratore di Contoso deve eseguire questo comando per CN=mail1.contoso.com.

$Data1 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail1" -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com" -DomainName mail.contoso.com
Set-Content -Path "C:\Certificates\mail1-request.req" -Value $Data1

L'amministratore di Contoso deve eseguire questo comando per CN=mail2.mail.contoso.com.

$Data2 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail2" -SubjectName "DC=com,DC=Contoso,CN=mail2.mail.contoso.com"  -DomainName mail.contoso.com
Set-Content -Path "C:\Certificates\mail2-request.req" -Value $Data2

Per ulteriori informazioni sulla sintassi e sui parametri, vedere New-ExchangeCertificate.

Importante

I dettagli specifici del certificato o della richiesta certificato creati dipendono da diversi fattori. Quando si crea una richiesta, accertarsi di collaborare strettamente con l'Autorità di certificazione (CA) o con l'amministratore dell'infrastruttura a chiave pubblica (PKI) che rilascerà il certificato. Per ulteriori informazioni su come creare una richiesta certificato per i servizi TLS, vedere Generazione di richieste per i Servizi certificati di terze parti.

Inizio pagina

Passo 2: Importazione di certificati nei server Trasporto Edge

Dopo la generazione delle richieste di certificati, l'amministratore delle CA per Contoso utilizza tali richieste per generare i certificati relativi ai server. È necessario che i certificati risultanti siano emessi in forma di certificato singolo oppure come catena di certificati e che siano copiati nei server Trasporto Edge appropriati.

Importante

Non utilizzare lo snap-in Gestione certificati in Microsoft Management Console per importare i certificati correlati ai servizi TLS nel server Exchange. L'utilizzo dello snap-in Gestione certificati per l'importazione dei certificati nei server Exchange non associa le richieste create in questa procedura ai certificati emessi. Per questa ragione è possibile che i servizi TLS non funzionino. È possibile utilizzare lo snap-in Gestione certificati per importare certificati e chiavi archiviati come file pfx nell'archivio del computer locale.

Quando si importa il certificato nel server Trasporto Edge, è necessario inoltre abilitare il certificato per il servizio SMTP (Simple Mail Transfer Protocol). L'amministratore di Contoso esegue il comando indicato di seguito in ogni server trasporto Edge, una volta per ciascun rispettivo certificato.

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificates\mail1-certificate.pfx -Encoding Byte -ReadCount 0)) | Enable-ExchangeCertificate -Services SMTP

Questo comando importa e abilita il certificato TLS eseguendo il piping del cmdlet Enable-ExchangeCertificate. È inoltre possibile abilitare il certificato dopo l'importazione. In questo caso, sarà necessario specificare l'identificazione personale del certificato che si desidera abilitare.

Per ulteriori informazioni sulla sintassi e sui parametri, vedere gli argomenti Import-ExchangeCertificate e Enable-ExchangeCertificate.

Trasporto di certificati e chiavi correlate

Quando si riceve un certificato dal proprio provider CA o PKI, convertire il certificato rilasciato in un file pfx (PKCS#12) in modo che sia possibile eseguirne il backup in caso di emergenza. Un file pfx contiene il certificato e le chiavi correlate. In alcuni casi è possibile che si desideri trasportare il certificato e le chiavi su altri computer. Ad esempio, se si hanno più server Trasporto Edge per un dominio protetto sul quale si prevede di ricevere e inviare posta elettronica, è possibile creare un singolo certificato che funzionerà per tutti i server. In questo caso è necessario che il certificato sia stato importato e abilitato per i servizi TLS su ognuno dei server Trasporto Edge.

Finché si conserva una copia del file pfx archiviata in un percorso sicuro, è sempre possibile importare e abilitare il certificato. Il file pfx contiene la chiave privata; di conseguenza è fondamentale proteggere fisicamente il file su un supporto di archiviazione collocato in un luogo sicuro.

È importante comprendere che il cmdlet Import-ExchangeCertificate contrassegna sempre la chiave privata importata dal file pfx come non esportabile. Tale funzionalità è preimpostata.

Quando si utilizza lo snap-in Gestione certificati in Microsoft Management Console per importare un file pfx, è possibile specificare l'esportabilità della chiave privata e la protezione chiave avanzata.

Importante

Non abilitare la protezione chiave avanzata su certificati destinati all'utilizzo di servizi TLS. La protezione chiave avanzata avvisa l'utente ogni volta che viene effettuato l'accesso alla chiave privata. Con la protezione del dominio, l'utente è il servizio SMTP sul server Trasporto Edge.

Inizio pagina

Passo 3: Configurazione della protezione del dominio in uscita

È necessario eseguire tre passaggi per configurare la protezione del dominio in uscita:

  1. eseguire il cmdlet Set-TransportConfig per specificare il dominio con cui si desidera inviare posta con dominio protetto;

  2. Eseguire il cmdlet Set-SendConnector per impostare la proprietà DomainSecureEnabled nel connettore di invio che provvede a inviare la posta al dominio con cui si desidera inviare posta con dominio protetto;

  3. Eseguire il cmdlet Set-SendConnector per verificare quanto riportato di seguito:

    • il connettore di invio che invia la posta al dominio con cui si desidera inviare posta con dominio protetto instrada la posta con DNS (Domain Name System);

    • L'FQDN è impostato per applicare corrispondenze con il nome del soggetto oppure con il nome del soggetto alternativo che si utilizza per la protezione dominio.

Le modifiche apportate in questi tre passaggi sono globali, per cui è necessario apportare tali modifiche in un Exchange server interno. Le modifiche di configurazione apportate saranno replicate all'esterno dei server Trasporto Edge utilizzando il servizio Microsoft Exchange EdgeSync.

Passo 3a: Specifica del dominio del mittente nella configurazione di trasporto

È relativamente semplice specificare il dominio con cui si desidera inviare la posta con dominio protetto. L'amministratore di Contoso utilizza il comando riportato di seguito su un server Exchange 2010 interno:

Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com

Il parametro TLSSendDomainSecureList accetta un elenco di nomi di dominio con più valori. Il comando Set-TransportConfig sostituisce l'intero valore relativo a TLSSendDomainSecureList con il nuovo valore fornito nel cmdlet. Quindi, se si hanno altri domini già configurati e si desidera aggiungere un nuovo dominio, è necessario includere il dominio esistente nell'elenco o utilizzare una variabile temporanea. Nell'esempio seguente, viene illustrato come aggiungere il dominio woodgrovebank.com al parametro TLSSendDomainSecureList senza sovrascrivere i valori esistenti.

$TransportConfig = Get-TransportConfig
$TransportConfig.TLSSendDomainSecureList += "woodgrovebank.com"
Set-TransportConfig -TLSSendDomainSecureList $TransportConfig.TLSSendDomainSecureList

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Set-TransportConfig.

Passo 3b: Configurare il connettore di invio predefinito

Contoso utilizza il proprio connettore di invio indirizzato su DNS predefinito denominato Internet per inviare posta con dominio protetto ai soci. Poiché il connettore di invio indirizzato su DNS predefinito rappresenta un connettore di invio su Internet predefinito, per instradare la posta viene utilizzato il DNS e non uno smart host. L'FQDN è già impostato su mail.contoso.com. Poiché i certificati creati dall'amministratore di Contoso impostano il parametro DomainName di New-ExchangeCertificate su mail.contoso.com, è possibile che il connettore di invio utilizzi i certificati senza una configurazione aggiuntiva.

Se si è configurato un sottodominio di prova, potrebbe essere necessario aggiornare l'FQDN del proprio connettore di invio in modo che corrisponda al certificato creato (ad esempio, sottodominio.posta.contoso.com). Se invece si è creato un certificato che contiene il sottodominio nei campi Oggetto o Nome alternativo oggetto, non è necessario aggiornare l'FQDN del connettore di invio.

Pertanto, l'unica configurazione che l'amministratore di Contoso deve eseguire nel connettore di invio consiste nell'impostazione del parametro DomainSecureEnabled. A tale scopo, l'amministratore di Contoso esegue il comando indicato di seguito in un server interno di Exchange 2010 per il connettore di invio su Internet:

Set-SendConnector Internet -DomainSecureEnabled:$true

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Set-SendConnector.

Passo 3C: Verifica della configurazione del connettore di invio

Dopo aver completato le modifiche di configurazione, è necessario che l'amministratore di Contoso verifichi che il connettore di invio utilizzato per la protezione dominio sia configurato correttamente. A tale scopo, l'amministratore di Contoso deve eseguire il comando riportato di seguito.

Get-SendConnector Internet | Format-List Name,DNSRoutingEnabled,FQDN,DomainSecureEnabled

Tale comando elencherà i parametri rilevanti configurati per la protezione dominio consentendo all'amministratore di Contoso di verificare la configurazione.

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Get-SendConnector.

Inizio pagina

Passo 4: Configurazione della protezione del dominio in ingresso

È necessario eseguire due passaggi per abilitare la protezione del dominio in ingresso:

  1. Eseguire il cmdlet Set-TransportConfig per specificare il dominio da cui si desidera ricevere posta con dominio protetto.

  2. Nel server Trasporto Edge, utilizzare Exchange Management Shell oppure Exchange Management Console per abilitare la protezione del dominio nel connettore di ricezione da cui si desidera ricevere posta con dominio protetto. Poiché la protezione del dominio richiede l'autenticazione TLS reciproca, è necessario abilitare il TLS anche nel connettore di ricezione.

Passo 4a: Specifica del dominio del destinatario nella configurazione di trasporto

È relativamente semplice specificare il dominio con cui si desidera ricevere la posta con dominio protetto. L'amministratore di Contoso esegue il comando riportato di seguito in Shell su un server Exchange 2010 interno o sulla workstation di gestione:

Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com

Il parametro TLSReceiveDomainSecureList accetta un elenco di nomi di dominio con più valori. Il comando Set-TransportConfig sostituisce l'intero valore relativo al parametro TLSReceiveDomainSecureList con il nuovo valore fornito nel cmdlet Set-TransportConfig. Quindi, se si hanno altri domini già configurati e si desidera aggiungere un nuovo dominio, è necessario includere il dominio esistente nell'elenco o utilizzare una variabile temporanea. Nell'esempio seguente, viene illustrato come aggiungere il dominio woodgrovebank.com al parametro TLSReceiveDomainSecureList senza sovrascrivere i valori esistenti.

$TransportConfig = Get-TransportConfig
$TransportConfig.TLSReceiveDomainSecureList += "woodgrovebank.com"
Set-TransportConfig -TLSReceiveDomainSecureList $TransportConfig.TLSReceiveDomainSecureList

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Set-TransportConfig.

Passo 4b: Configurare il connettore di ricezione

È necessario configurare il connettore di ricezione nel server Trasporto Edge che accetta la posta dal dominio da cui si desidera ricevere posta con dominio protetto. L'ambiente Contoso è configurato per disporre di un unico connettore di ricezione su Internet, con un valore Internet del parametro Identity su entrambi i server Trasporto Edge. Di conseguenza, per abilitare il TLS durante lo scambio della posta con Woodgrove Bank, è necessario che l'amministratore di Contoso si assicuri che il protocollo TLS sia abilitato nel connettore di ricezione da Internet predefinito in entrambi i server Trasporto Edge. A tale scopo, l'amministratore di Contoso esegue il seguente comando sia su mail1.contoso.com che su mail2.mail.contoso.com.

Set-ReceiveConnector Internet -DomainSecureEnabled $true -AuthMechanism TLS

Per ulteriori informazioni sulla sintassi e sui parametri, vedere Set-ReceiveConnector.

È inoltre possibile utilizzare EMC per configurare il connettore di ricezione applicando la seguente procedura.

  1. Nel server Trasporto Edge, aprire EMC, fare clic su Trasporto Edge e, nel riquadro dei risultati, fare clic sulla scheda Connettori di ricezione.

  2. Selezionare il connettore di ricezione che accetta la posta dal dominio da cui si desidera ricevere la posta con dominio protetto, in questo caso il connettore Internet e, quindi, nel riquadro azioni, fare clic su Proprietà.

  3. Nella scheda Autenticazioni, selezionare TLS (Transport Layer Security) e Abilita protezione dominio (Autenticazione reciproca TLS) e, quindi, fare clic su OK.

Occorre ricordare che la specifica del meccanismo di autenticazione come TLS non impone il TLS a tutte le connessioni in ingresso.

Il TLS viene imposto alle connessioni in entrata da Woodgrove Bank per i motivi indicati di seguito:

  • Woodgrove Bank viene specificato nel cmdlet Set-TransportConfig nel parametro TLSReceiveDomainSecureList.

  • Il parametro DomainSecureEnabled è impostato su $true nel connettore di ricezione.

Altri mittenti non elencati nel parametro TLSReceiveDomainSecureList nel cmdlet Set-TransportConfig utilizzano il TLS solo se è supportato dal sistema di invio.

Inizio pagina

Passo 5: Verifica del flusso di posta con dominio protetto

Dopo la configurazione della posta con dominio protetto, è possibile verificare la connessione riesaminando i registri di prestazione e di protocollo. I messaggi autenticati correttamente nel percorso del flusso di posta con dominio protetto vengono visualizzati in Outlook come messaggi di tipo Dominio protetto.

Contatori delle prestazioni

La caratteristica di protezione del dominio include in MSExchange Secure Mail Transport l'insieme di contatori delle prestazioni indicato di seguito:

  • Messaggi del dominio protetto ricevuti

  • Messaggi del dominio protetto inviati

  • Totale errori di sessioni dominio protetto in uscita

È possibile creare un nuovo file di registro contatore relativo al flusso di posta con dominio sicuro con tali contatori delle prestazioni per monitorare il numero di messaggi inviati e ricevuti e per monitorare le sessioni di TLS reciproco non riuscite. Per ulteriori informazioni sulla creazione e la configurazione di registri contatori, vedere il file della Guida incluso nello snap-in Avvisi e registri di prestazioni di MMC.

Registri di protocollo

È possibile riesaminare i registri di protocollo di invio e ricezione per determinare se la negoziazione TLS è stata eseguita correttamente.

Per visualizzare registri di protocollo dettagliati, è necessario impostare il livello di registrazione protocollo su Verbose sui connettori utilizzati dalla propria organizzazione per inviare e ricevere posta elettronica con dominio protetto. Per effettuare tale operazione, l'amministratore di Contoso utilizza il comando riportato qui di seguito su entrambi i server Trasporto Edge.

Set-ReceiveConnector Internet -ProtocolLoggingLevel Verbose

Per abilitare la registrazione del protocollo sul connettore di invio, l'amministratore di Contoso effettua la seguente operazione su un server Exchange interno o su una workstation di gestione. La configurazione delle modifiche viene quindi replicata sui server Trasporto Edge utilizzando il servizio Microsoft Exchange EdgeSync.

Set-SendConnector Internet -ProtocolLoggingLevel Verbose

Per ulteriori informazioni sulla sintassi e sui parametri, vedere gli argomenti Set-ReceiveConnector e Set-SendConnector.

Per ulteriori informazioni sulla visualizzazione dei registri di protocollo, vedere Configurazione della registrazione protocollo.

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.