Utilizzo di PKI sul server Trasporto Edge per la protezione del dominio

 

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

Ultima modifica dell'argomento: 2012-07-23

La protezione del dominio si basa su Transport Layer Security (TLS) reciproco per l'autenticazione. Un'autenticazione TLS reciproca corretta si basa su una catena di certificati X.509 attentibile e convalidata per i certificati TLS che vengono utilizzati per la protezione del dominio.

Pertanto, prima di poter distribuire correttamente la protezione del dominio, è necessario configurare il server Trasporto Edge e l'infrastruttura a chiave pubblica (PKI, Public Key Infrastructure) X.509 in modo da tenere conto dell'attendibilità e della convalida dei certificati.

Importante

La spiegazione dettagliata delle tecnologie e dei concetti relativi alla crittografia e ai certificati esula dall'ambito di questo argomento. Prima di distribuire qualsiasi soluzione per la protezione che utilizzi la crittografia e i certificati X.509, si consiglia di comprendere i concetti fondamentali di trust, autenticazione, crittografia e modifica a chiave pubblica e privata relativi alla crittografia. Per ulteriori informazioni, vedere i riferimenti elencati alla fine di questo argomento.

Configurazione delle Autorità di certificazione radice

Per convalidare un determinato certificato X.509, è necessario riconoscere come attendibile l'Autorità di certificazione radice che ha emesso il certificato. Un'Autorità di certificazione radice è l'Autorità di certificazione più attendibile, che sta al vertice di una gerarchia di autorità di certificazione. L'Autorità di certificazione radice ha un certificato autofirmato. Se si esegue un'applicazione basata sull'autenticazione dei certificati, ogni certificato deve disporre di una catena di certificati che termina con un certificato nel contenitore radice disponibile nell'elenco locale del computer locale. Il contenitore radice disponibile nell'elenco locale contiene certificati provenienti dalle Autorità di certificazione radice.

Per inviare correttamente un dominio di posta protetto, è necessario essere in grado di convalidare il certificato X.509 del server di ricezione. Allo stesso modo, se qualcuno invia un dominio di posta protetto a un'organizzazione, il server addetto all'invio deve essere in grado di convalidare il certificato.

Esistono due tipi di Autorità di certificazione radice disponibile nell'elenco locale che possono essere utilizzati per implementare la protezione del dominio: Autorità di certificazione radice di terze parti incorporate e Autorità di certificazione radice private.

Autorità di certificazione radice di terze parti

Microsoft Windows comprende una serie di Autorità di certificazione radice di terze parti incorporate. Se si considerano come attendibili i certificati emessi da queste Autorità di certificazione radice di terze parti significa che è possibile verificare i certificati immessi da dette Autorità di certificazione. Se l'organizzazione e le organizzazioni partner utilizzano l'installazione di Windows predefinita e considerano come attendibili le Autorità di certificazione radice di terze parti incorporate, il trust è automatico. In questo scenario, non è necessaria una configurazione trust aggiuntiva.

Autorità di certificazione radice disponibile nell'elenco locale private

Un'Autorità di certificazione radice disponibile nell'elenco locale privata è un'Autorità di certificazione radice che è stata distribuita da un'infrastruttura a chiave pubblica privata o interna. Ad esempio, se l'organizzazione dell'utente o l'organizzazione con cui si scambiano domini di posta protetti ha distribuito un'infrastruttura a chiave pubblica interna con il proprio certificato radice, è necessario eseguire configurazioni trust aggiuntive.

Se si utilizzano le Autorità di certificazione radice private, è necessario aggiornare l'archivio dei certificati radice disponibili nell'elenco locale di Windows sul server Trasporto Edge per garantire il corretto funzionamento della protezione del dominio.

È possibile configurare i trust in due modi: trust principale diretto e certificazione incrociata. È bene ricordare che ogni volta che il servizio di trasporto recupera un messaggio, convalida il certificato prima di utilizzarlo. Pertanto, se si utilizza un'Autorità di certificazione radice privata per l'emissione dei certificati, è necessario includere l'Autorità di certificazione radice privata nell'archivio dei certificati radice attendibili su ogni server Trasporto Edge che invia o riceve posta elettronica da domini protetti.

Trust principale diretto

Se si desidera considerare come valido un certificato emesso da un'Autorità di certificazione radice privata, è possibile aggiungere manualmente il certificato radice all'archivio di certificati radice attendibili sul computer del server Trasporto Edge. Per ulteriori informazioni sull'aggiunta manuale dei certificati nell'archivio di certificati locale, vedere il file della Guida per lo snap-in Gestione certificati in Microsoft Management Console (MMC).

Certificazione incrociata

La certificazione incrociata viene generata quando un'Autorità di certificazione sottoscrive un certificato generato da un'Autorità di certificazione diversa. La certificazione incrociata viene utilizzata per creare trust da un'infrastruttura a chiave pubblica con un'altra infrastruttura a chiave pubblica. Nel contesto della protezione dei domini, se l'utente dispone di una propria infrastruttura a chiave pubblica, anziché utilizzare il trust manuale diretto per un'autorità principale di un partner con un'infrastruttura a chiave pubblica interna, è possibile creare un certificato incrociato per l'Autorità di certificazione partner all'interno dell'autorità principale. In questo caso, il trust viene stabilito in quanto il certificato incrociato rimanda alle Autorità di certificazione principali attendibili.

È bene ricordare che se si ha un'infrastruttura a chiave pubblica interna e si utilizza la certificazione incrociata, è necessario aggiornare manualmente l'archivio dei certificati principali su ogni server Trasporto Edge che riceve domini di posta protetti in modo che ciascun server Trasporto Edge possa convalidare i certificati durante la ricezione di messaggi di posta elettronica da partner attendibili tramite la certificazione incrociata.

Per ulteriori informazioni sull'aggiunta manuale dei certificati nell'archivio di certificati locale, vedere il file della Guida per lo snap-in Gestione certificati in Management Console (MMC).

Configurazione dell'accesso all'elenco di revoche di certificati

Ogni volta che recupera un certificato, il servizio di trasporto convalida la catena di certificati e il certificato. La convalida del certificato è un processo in cui vengono confermati molti attributi del certificato. La maggior parte di questi attributi può essere confermata sul computer locale dall'applicazione che richiede il certificato. Ad esempio, l'uso previsto del certificato, le date di scadenza sul certificato e attributi simili possono essere verificati all'esterno del contesto di un'infrastruttura a chiave pubblica. Tuttavia, la verifica che il certificato non è stato revocato deve essere convalidata con l'Autorità di certificazione che ha emesso il certificato. Per questo motivo la maggior parte delle Autorità di certificazione mette a disposizione del pubblico un elenco di revoche di certificati (CRL, certificate revocation list) per convalidare lo stato di revoca.

Per utilizzare correttamente la protezione dei domini, gli elenchi di revoche di certificati per le Autorità di certificazione in uso o utilizzati dai partner devono essere disponibili sui server Trasporto Edge che inviano e ricevono domini di posta protetti. Se il controllo della revoca non riesce, il server di Exchange destinatario emette un rifiuto del protocollo temporaneo del messaggio. Si può verificare un errore di revoca temporaneo. Ad esempio, il server Web che viene utilizzato per pubblicare l'elenco di revoche di certificati potrebbe presentare un errore. Potrebbe anche verificarsi un errore di controllo della revoca dovuto a problemi generali di connettività di rete tra il server Trasporto Edge e il punto di distribuzione dell'elenco di certificati revocati. Pertanto, gli errori di revoca temporanea causano semplicemente dei ritardi temporanei nel recapito della posta visto che il server di invio effettuerà una nuova prova in un momento successivo. Tuttavia, la convalida dell'elenco di revoche di certificati è necessaria per la trasmissione corretta di domini di posta protetti.

È necessario abilitare i seguenti scenari:

• I server Trasporto Edge devono essere in grado di accedere agli elenchi di certificati revocati per le autorità di certificazione esterne   Ogni partner con cui si scambia posta elettronica da domini protetti deve disporre di elenchi di certificati revocati disponibili pubblicamente, che il server Trasporto Edge dell'organizzazione può contattare. In alcuni casi, gli elenchi di revoche di certificati sono disponibili solo con LDAP (Lightweight Directory Access Protocol). Nella maggior parte dei casi, con autorità di certificazione pubbliche, gli elenchi di revoche di certificati vengono pubblicati tramite HTTP. Assicurarsi di avere configurato le porte in uscita e i proxy appropriati per consentire al server Trasporto Edge di mettersi in contatto con l'elenco di certificati revocati. È possibile determinare il protocollo accettato da uno specifico punto di distribuzione dell'elenco di revoche di certificati aprendo un certificato in MMC e visualizzando il campo Punti di distribuzione Elenco di revoche di certificati (CRL).

• Assicurarsi che l'elenco di revoche di certificati per l'Autorità di certificazione che emette i certificati sia pubblicamente disponibile   Ricordare che anche quando un server Trasporto Edge recupera un certificato dall'organizzazione, esso convalida la catena di certificati per convalidare il certificato. Pertanto, l'elenco di revoche di certificati per l'Autorità di certificazione deve essere a disposizione dei server Trasporto Edge in uso. Inoltre tutti i partner con cui si scambiano domini di posta protetti devono essere in grado di accedere all'elenco di revoche di certificati per l'Autorità di certificazione che emette i certificati.

Configurazione delle impostazioni proxy per WinHTTP

I server di trasporto di Exchange 2010 si affidano ai servizi HTTP (WinHTTP) sottostanti di Microsoft Windows per la gestione di tutto il traffico HTTP e HTTPS. I server Trasporto Hub e Trasporto Edge possono entrambi utilizzare HTTP per accedere agli aggiornamenti standard del filtro protezione posta indesiderata di Microsoft Exchange 2010 e per la convalida degli elenchi di certificati revocati.

Per ulteriori informazioni, vedere Configurazione delle impostazioni proxy per WinHTTP.

Verifica della configurazione proxy e PKI

Per verificare la configurazione proxy e PKI per uno specifico server Trasporto Edge, utilizzare Certutil.exe per esaminare la catena di certificati per il certificato del server Trasporto Edge. Certutil.exe è uno strumento della riga di comando installato come parte di Servizi certificati nei sistemi operativi Windows Server 2008. Per ulteriori informazioni, vedere Test PKI e configurazione proxy.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.