Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In una distribuzione ibrida, i certificati digitali sono una parte importante della protezione delle comunicazioni tra l'organizzazione di Exchange locale e Microsoft 365 o Office 365. I certificati consentono a ciascuna organizzazione di Exchange di considerare attendibile l'identità dell'altra. I certificati assicurano inoltre che ciascuna organizzazione di Exchange comunichi con l'origine corretta.
In una distribuzione ibrida sono presenti vari servizi che utilizzano i certificati:
Microsoft Entra Connect (Microsoft Entra Connect) con Active Directory Federation Services (AD FS): se scegli di distribuire Microsoft Entra Connect con ADFS come parte della distribuzione ibrida, un certificato emesso da un'autorità di certificazione (CA) di terze parti attendibile viene usato per stabilire un rapporto di trust tra client Web e proxy server federativi, per firmare token di sicurezza e per decrittografare token di sicurezza.
Per ulteriori informazioni, vedere Certificati.
Federazione di Exchange: un certificato autofirmato viene usato per creare una connessione sicura tra i server Exchange locali e il sistema di autenticazione Microsoft Entra.
Per altre informazioni, vedi Condivisione.
Servizi Exchange: i certificati emessi da un'autorità di certificazione di terze parti attendibile vengono utilizzati per proteggere la comunicazione SSL (Secure Sockets Layer) tra i server e i client di Exchange. I servizi che utilizzano i certificati includono Outlook sul Web, Exchange ActiveSync, Outlook via Internet e il trasporto sicuro dei messaggi.
Server Exchange esistenti: i server Exchange esistenti possono usare i certificati per proteggere le comunicazioni di Outlook sul Web, il trasporto dei messaggi e così via. A seconda di come vengono utilizzati i certificati nei server Exchange, è possibile utilizzare certificati autofirmati o certificati emessi da un'Autorità di certificazione attendibile di terze parti.
Requisiti dei certificati per una distribuzione ibrida
Quando si configura una distribuzione ibrida è necessario utilizzare e configurare certificati acquistati da un'autorità di certificazione attendibile di terze parti. Il certificato utilizzato per il trasporto ibrido sicuro della posta deve essere installato in tutti i server Cassette postali (Exchange 2016 e versioni successive) locali e nei server Cassette postali e Accesso client (Exchange 2013 e versioni precedenti).
Importante
Se si sta configurando una distribuzione ibrida in un'organizzazione nella quale i server di Exchange sono distribuiti in più foreste Active Directory, è necessario utilizzare un certificato CA di terze parti per ogni foresta Active Directory.
Quando si implementano i server Trasporto Edge di Exchange nell'organizzazione locale, questo certificato deve essere installato anche in tutti i server Trasporto Edge. Ogni server Trasporto Edge deve utilizzare un certificato che condivide la stessa CA emittente e lo stesso oggetto affinché la posta protetta ibrida funzioni correttamente.
Se sono presenti più servizi, ad esempio AD FS, federazione Exchange, servizi ed Exchange, è necessario un certificato per ciascuno. In base alle necessità dell'organizzazione si può decidere di fare una delle cose seguenti:
Utilizzare un certificato di terze parti che viene utilizzato da tutti i servizi su più server.
Utilizzare un certificato di terze parti per ogni server che fornisce servizi.
La scelta di utilizzare lo stesso certificato per tutti i servizi o di utilizzare un certificato dedicato per ciascun servizio dipende dall'organizzazione e dal servizio che si sta implementando. Di seguito vengono riportate alcune considerazioni da tenere presente per ciascuna opzione:
Certificato di terze parti su più server: i certificati di terze parti usati dai servizi su più server possono essere leggermente più economici da ottenere, ma possono complicare il rinnovo e la sostituzione. Le complicazioni avvengono perchè quando è necessario sostituire un certificato, è necessario effettuare la sostituzione su tutti i server sui quali è stato installato.
Certificato di terze parti per ogni server: l'uso di un certificato dedicato per ogni server che ospita i servizi consente di configurare il certificato in modo specifico per i servizi su quel server. Se è necessario sostituire il certificato o rinnovarlo e necessario farlo solo sul server sul quale è installato il servizio. Gli altri server non sono coinvolti.
È consigliabile utilizzare un certificato di terze parti dedicato per ogni server AD FS facoltativo, un altro certificato per i servizi di Exchange per la distribuzione ibrida e, se necessario, un altro certificato nei server Exchange per tutti gli altri servizi o funzionalità necessari. Per il trust federativo locale configurato nell'ambito della condivisione federata in una distribuzione ibrida viene utilizzato un certificato autofirmato per impostazione predefinita. Se non esistono requisiti specifici, non è necessario utilizzare un certificato di terze parti per il trust federativo configurato nell'ambito di una distribuzione ibrida.
I servizi installati su un singolo server possono richiedere di configurare multipli nomi di dominio completi (FQDN) per il server. È consigliabile acquistare un certificato che consente il numero massimo di FQDN richiesto. I certificati sono composti dal nome del soggetto (altrimenti detto nome dell'entità) e da uno o più nomi alternativi del soggetto (SAN). Il nome soggetto è il dominio SMTP primario condiviso tra l'organizzazione locale e quella di Exchange Online. I SAN sono ulteriori FQDN che possono essere aggiunti nel certificato al nome del soggetto. Se il certificato deve supportare cinque FQDN, acquistare un certificato che consenta di aggiungere cinque domini: un nome del soggetto e quattro SAN.
La tabella seguente illustra il numero minimo di FQDN che è consigliabile includere nei certificati configurati per l'utilizzo in una distribuzione ibrida.
| Servizio | FQDN suggeriti | Campo |
|---|---|---|
| Dominio SMTP condiviso primario | contoso.com | Nome soggetto |
| Individuazione automatica | Etichetta che corrisponde all'FQDN esterno di individuazione automatica del server Accesso client di Exchange 2013, ad esempio autodiscover.contoso.com | Nome alternativo soggetto |
| Trasporto | Etichetta che corrisponde all'FQDN esterno dei server Trasporto Edge, ad esempio mail.contoso.com | Nome alternativo soggetto |
Se non è necessario inoltrare i messaggi di posta elettronica a Internet tramite Office 365, è possibile usare il nome del servizio di trasporto nel nome dell'oggetto invece del dominio SMTP condiviso primario. Per altre informazioni, vedere Configurare un connettore basato su certificato per inoltrare i messaggi di posta elettronica tramite Office 365.