Come configurare il TLS reciproco per la protezione del dominio

 

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

Ultima modifica dell'argomento: 2009-04-20

In questo argomento viene descritto come utilizzare Exchange Management Shell per configurare il TLS (Transport Layer Security) reciproco per la protezione del dominio, l'insieme di funzionalità di Microsoft Exchange Server 2007 e di Microsoft Office Outlook 2007 che forniscono un'alternativa relativamente economica a S/MIME e a altre soluzioni di protezione al livello dei messaggi.

A scopo illustrativo, in questo argomento viene descritto come gli amministratori Exchange di una società fittizia, la Contoso, configurano l'ambiente Exchange 2007 per lo scambio della posta con dominio protetto con il socio fittizio Woodgrove Bank. In tale scenario, Contoso desidera 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:

1. generano una richiesta certificato relativa ai certificati TLS;

2. importano il certificato nei server Trasporto Edge.

3. configurano la protezione del dominio in uscita;

4. configurano la protezione del dominio in ingresso;

5. verificano il flusso della posta.

Informazioni preliminari

La configurazione del TLS reciproco richiede i requisiti indicati di seguito:

• l'accesso ai server di Exchange 2007 interni utilizzando il cmdlet Set-TransportConfig e il cmdlet New-SendConnector se non sono stati configurati connettori di invio;

• l'accesso a computer con il server Trasporto Edge in cui siano eseguiti i cmdlet ExchangeCertificate.

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.

Quando si importano e si configurano i certificati TLS utilizzando i cmdlet ExchangeCertificate, è necessario eseguire tali cmdlet nel server Trasporto Edge che si sta configurando. Per eseguire i cmdlet ExchangeCertificate 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 eseguire il cmdlet Set-TransportConfig, è necessario utilizzare un account che disponga della delega del ruolo Exchange Organization Administrator.

Per eseguire il cmdlet New-SendConnector, all'account utilizzato deve essere delegato il ruolo di amministratore dell'organizzazione di Exchange e il gruppo Administrators locale nel computer.

Per ulteriori informazioni sulle autorizzazioni, sulla delega dei ruoli e sui diritti necessari per l'amministrazione di Exchange 2007, vedere Considerazioni sulle autorizzazioni.

Questo argomento presuppone la lettura e la comprensione di Creazione di un certificato o di una richiesta di certificato per TLS.

È necessario che il servizio EdgeSync di Microsoft Exchange sia implementato interamente per la protezione dominio.

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 Come abilitare l'infrastruttura a chiave pubblica (PKI) sul server Trasporto Edge per la protezione del dominio.

Generazione di una richiesta certificato relativa ai certificati TLS

Come già affermato in questo argomento, Contoso dispone di una PKI interna subordinata ad una CA 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 terze parti. 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 terze parti 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. È necessario che l'amministratore di Contoso esegua questo comando due volte: una volta per CN=mail1.contoso.com e una volta per CN=mail2.mail.contoso.com.

Creazione di una richiesta di certificato TLS

• Eseguire il comando indicato di seguito:

  New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate" -Path c:\certificates\request.p7c -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com"  -DomainName mail.contoso.com
  

Per ulteriori informazioni sulla sintassi e sui parametri, vedere New-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.

Importazione di certificati nei server Trasporto Edge

Dopo la generazione delle richieste di certificati, l'amministratore 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.

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.

Importazione e abilitazione di un certificato TLS per la Protezione dominio in un server Trasporto Edge

• Eseguire il comando indicato di seguito:

  Import-ExchangeCertificate -Path c:\certificates\import.pfx | 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. Per importare il certificato, eseguire il comando indicato di seguito:

Import-ExchangeCertificate -Path c:\certificates\import.pfx 

Quindi copiare l'identificazione personale negli Appunti di Windows. Per visualizzare l'identificazione personale appena importata, eseguire il seguente comando:

Get-ExchangeCertificate |FL

Copiare i dati dal campo di identificazione personale negli Appunti di Windows.

Infine, per abilitare il certificato, eseguire il seguente comando:

Enable-ExchangeCertificate -Thumbprint AB493A0C9A6C0327162FE04EF74609CB8FB7FE24 -Services SMTP

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 EdgeSync di Microsoft Exchange.

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 esegue il comando riportato di seguito in un server di Exchange 2007 interno:

Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com

Per ulteriori informazioni, vedere Set-TransportConfig.

Configurazione di un connettore di invio

Contoso utilizza il proprio connettore di invio indirizzato su DNS predefinito 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, viene utilizzato il DNS per instradare la posta 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 del 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 il 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 il 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 2007 per il connettore di invio "su Internet":

Set-SendConnector Internet -DomainSecureEnabled:$True

Per ulteriori informazioni, vedere Set-SendConnector.

È inoltre possibile utilizzare Exchange Management Console per abilitare la posta con dominio protetto in un connettore di invio.

Utilizzo di Exchange Management Console per configurare un connettore di invio per la protezione di dominio

1. In un server Trasporto Hub, aprire Exchange Management Console, fare clic su Configurazione organizzazione e, quindi, su Trasporto Hub e, nel riquadro dei risultati, fare clic sulla scheda Connettori di invio.

2. Selezionare il connettore di invio che invia la posta al dominio da cui si desidera inviare la posta con dominio protetto e, quindi, nel riquadro azioni, fare clic su Proprietà.

3. Nella scheda Rete, selezionare Abilita protezione dominio (Autenticazione reciproca TLS), fare clic su Applica e, quindi, su OK.

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.

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 un server di Exchange 2007 interno:

Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com

Per ulteriori informazioni, vedere Set-TransportConfig.

Configurazione di un 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'identità di tipo Inet, in 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.

Utilizzo di Exchange Management Shell per configurare un connettore di ricezione per la protezione del dominio

• Nel server Trasporto Edge, eseguire il comando indicato di seguito:

  Set-ReceiveConnector Inet -DomainSecureEnabled:$True -AuthMechanism TLS
  

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

Utilizzo di Exchange Management Console per configurare un connettore di ricezione per la protezione del dominio

1. Nel server Trasporto Edge, aprire Exchange Management Console, 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 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 specificata 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.

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 2007 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. Una negoziazione TLS corretta genera registri simili a quelli riportati di seguito.

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 utilizzare Exchange Management Shell in modo che configuri un connettore di ricezione per la registrazione di protocollo elevata

• Nel server Trasporto Edge, eseguire il comando riportato di seguito:

  Set-ReceiveConnector Inet -ProtocolLoggingLevel Verbose
  

  Dove Inet è il nome del connettore di ricezione sul quale è abilitata la posta elettronica del dominio protetto.

Per utilizzare Exchange Management Shell in modo che configuri un connettore di invio per la registrazione di protocollo elevata

• Nel server Trasporto Edge, eseguire il comando riportato di seguito:

  Set-SendConnector Internet -ProtocolLoggingLevel Verbose
  

  Dove Internet è il nome del connettore di invio sul quale è abilitata la posta elettronica del dominio protetto.

Esempio di un registro di invio

<220 edgedns3 ESMTP Microsoft ESMTP MAIL Service, Version: 8.0.647.0; Tue, 29 Aug 2006 04:22:00 -0700 (PDT)
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-STARTTLS
<250-DELIVERBY
<250 HELP
>STARTTLS
<220 2.0.0 Ready to start TLS
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-DELIVERBY
<250 HELP
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, sending message
>MAIL FROM:<user@example.com> SIZE=614
>RCPT TO:<root@smi.extest.contoso.com>
<250 2.1.0 <user@example.com>... Sender ok
<250 2.1.5 <root@smi.extest.contoso.com>... Recipient ok
>DATA
<354 Enter mail, end with "." on a line by itself
<250 2.0.0 k7TBM0BZ000043 Message accepted for delivery
>QUIT
<221 2.0.0 edgedns3 closing connection

Esempio di un registro di ricezione

>220 edgea36 Microsoft ESMTP MAIL Service, Version: 8.0.647.0 ready at Mon, 28 Aug 2006 15:37:53 -0700
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-STARTTLS
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<STARTTLS
>220 2.0.0 SMTP server ready
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<MAIL From:<user@smi.extest.contoso.com> SIZE=16
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, receiving message
>250 2.1.0 user@smi.extest.contoso.com Sender OK
<RCPT To:<user@woodgrove.com>
>250 2.1.5 user@woodgrove.com Recipient OK
<DATA
>354 Start mail input; end with <CRLF>.<CRLF>
>250 2.6.0 <200608281121.k7SBHYi0004586@edgedns3> Queued mail for delivery
<QUIT
>221 2.0.0 Service closing transmission channel

Per ulteriori informazioni sulla visualizzazione dei registri di protocollo, vedere Come configurare la registrazione di protocollo.

Per ulteriori informazioni sulla gestione della protezione del dominio di Exchange 2007, vedere Gestione della protezione del dominio.

Per ulteriori informazioni su come configurare un'infrastruttura a chiave pubblica, vedere Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure (informazioni in lingua inglese).