Certificati digitali e crittografia in Exchange Server

La crittografia e i certificati digitali sono considerazioni importanti in tutte le organizzazioni. Per impostazione predefinita, Exchange Server è configurato per l'uso di Transport Layer Security (TLS) per crittografare la comunicazione tra server Exchange interni e tra i servizi di Exchange nel server locale. Tuttavia, gli amministratori Exchange devono valutare i propri requisiti di crittografia per la comunicazione con client interni ed esterni (computer e dispositivi mobili) e server di messaggistica esterna.

In questo argomento vengono illustrati i diversi tipi di certificati disponibili, la configurazione predefinita per i certificati in Exchangee consigli per certificati aggiuntivi che è necessario utilizzare con Exchange.

Per le procedure necessarie per i certificati in Exchange Server, vedere Procedure dei certificati in Exchange Server.

Panoramica certificati digitali

I certificati digitali sono file elettronici che funzionano come password in linea in grado di verificare l'identità di un utente o di un computer. Vengono utilizzati per creare il canale crittografato necessario per le comunicazioni client. Un certificato è una dichiarazione digitale emessa da un'Autorità di certificazione che si fa garante dell'identità del titolare del certificato e consente a terzi di comunicare in modo sicuro utilizzando la crittografia.

I certificati digitali offrono i servizi seguenti:

• Crittografia: consentono di proteggere i dati scambiati da furti o manomissioni.

• Autenticazione: verificano che i titolari (persone, siti Web e persino dispositivi di rete come i router) siano veramente chi o cosa dichiarano di essere. In genere, l'autenticazione è unidirezionale, dove l'origine verifica l'identità del target, ma è anche possibile l'autenticazione TLS manuale.

I certificati possono essere rilasciati per diversi usi. Ad esempio: l'autenticazione utente Web, l'autenticazione server Web, S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol security) e firma dei codici.

Un certificato contiene una chiave pubblica e la associa all'identità della persona, del computer o del servizio che possiede la chiave privata corrispondente. La chiave pubblica e quella privata sono utilizzate dal client e dal server per crittografare i dati prima di trasmetterli. Per utenti, computer e servizi Windows, l'attendibilità di una CA viene stabilita quando il certificato radice è definito nell'archivio certificati radice attendibili e il certificato contiene un percorso di certificazione valido. Il certificato è considerato se non è stato revocato (non si trova nel periodo di revoca del certificato o CRL della CA) oppure non è scaduto.

Nella seguente tabella sono descritti tre tipi principali di certificati digitali.

Per provare che il titolare di un certificato è colui che dichiara di essere, il certificato deve identificare in modo accurato il titolare del certificato per gli altri client, dispositivi o server. I tre metodi di base sono descritti nella tabella seguente.

Certificati in Exchange

Quando si installa Exchange 2016 o Exchange 2019 in un server, vengono creati e installati due certificati autofirmati da Exchange. Un terzo certificato autofirmato viene creato e installato da Microsoft Windows per il servizio gestione Web in Internet Information Services (IIS). Nella seguente tabella sono descritti i tre certificati visibili nell'Interfaccia di amministrazione di Exchange e Exchange Management Shell:

Le proprietà di questi certificati autofirmati sono descritte nella sezione Proprietà dei certificati autofirmati predefiniti.

Questi sono i problemi principali da considerare quando si tratta di certificati in Exchange:

• Non è necessario sostituire il certificato autofirmato Microsoft Exchange per crittografare il traffico di rete tra server e servizi Exchange nell'organizzazione.

• Sono necessari certificati aggiuntivi per crittografare le connessioni ai server Exchange tramite client interni ed esterni.

• Sono necessari certificati aggiuntivi per forzare la crittografia delle connessioni SMTP tra i server Exchange e i server di messaggistica esterni.

Gli elementi seguenti di pianificazione e distribuzione per Exchange Server sono driver importanti per i requisiti del certificato:

• Bilanciamento del carico: si prevede di terminare il canale crittografato nel server di bilanciamento del carico o nel server proxy inverso, usare i servizi di bilanciamento del carico di livello 4 o livello 7 e usare l'affinità di sessione o nessuna affinità di sessione? Per ulteriori informazioni, vedere Bilanciamento del carico in Exchange 2016.

• Pianificazione dello spazio dei nomi: quali versioni di Exchange sono presenti, si usa il modello di spazio dei nomi associato o non associato e si usa dns split-brain (configurazione di indirizzi IP diversi per lo stesso host in base all'accesso interno ed esterno)? Per ulteriori informazioni, vedere Pianificazione dello spazio dei nomi in Exchange 2016.

• Connettività client: quali servizi verranno usati dai client (servizi basati sul Web, POP, IMAP e così via) e quali versioni di Exchange sono coinvolte? Per ulteriori informazioni, vedere i seguenti argomenti:

  • Connettività client in un ambiente di coesistenza di Exchange 2016 con Exchange 2013

  • Connettività client in un ambiente di coesistenza di Exchange 2016 con Exchange 2010

  • Connettività client in un ambiente di coesistenza di Exchange 2016 con versioni miste di Exchange

Supporto dei certificati di crittografia a curva ellittica in Exchange Server

A partire dall'aggiornamento dell'hotfix di aprile 2024 di Exchange Server, Exchange Server 2016 ed Exchange Server 2019 supporta l'utilizzo dei certificati ECC (Elliptic Curve Cryptography) per alcuni servizi.

I certificati ECC, o certificati di crittografia a curva ellittica, sono un tipo di certificato digitale che usa l'algoritmo a curva ellittica per la crittografia, offrendo una maggiore sicurezza con lunghezze di chiave più brevi rispetto ai certificati RSA tradizionali.

Controllare la tabella nella sezione successiva per comprendere quali servizi possono essere usati con un certificato ECC.

Il supporto dei certificati ECC è disabilitato per impostazione predefinita e può essere abilitato creando un override. Aprire una nuova Exchange Management Shell (EMS) dopo l'esecuzione del New-SettingOverride comando:

New-SettingOverride -Name "ECC Support" -Parameters @("Enabled=true") -Component "Global" -Reason "Support ECC" -Section "ECCCertificateSupport"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

Requisiti relativi ai certificati per i servizi di Exchange

Nella seguente tabella sono descritti i servizi Exchange ai quali è possibile assegnare certificati.

^* L'autenticazione Kerberos e la crittografia Kerberos sono utilizzate per l'accesso remoto a PowerShell, da Interfaccia di amministrazione di Exchange e Exchange Management Shell. Di conseguenza, non è necessario configurare i certificati per l'uso con Remote PowerShell, purché ci si connetta direttamente a un server Exchange (non a uno spazio dei nomi con carico bilanciato). Per usare PowerShell remoto per connettersi a un server Exchange da un computer che non è membro del dominio o per connettersi da Internet, è necessario configurare i certificati per l'uso con PowerShell remoto.

Best practices per i certificati di Exchange

Sebbene la configurazione dei certificati digitali dell'organizzazione varia in base alle esigenze specifiche, sono state illustrate procedure consigliate per consentire di scegliere la configurazione dei certificati digitali migliore.

• Usare il minor numero possibile di certificati: molto probabilmente, questo significa usare certificati SAN o certificati con caratteri jolly. In termini di interoperabilità con Exchange, entrambi sono equivalenti. Decidere tra l'utilizzare un certificato SAN o un certificato con caratteri jolly riguarda principalmente le funzionalità principali o le limitazioni (reali o percepite) di ogni tipo di certificato, secondo quanto descritto in Panoramica certificati digitali.

  Ad esempio, se tutti i nomi comuni saranno sullo stesso livello di contoso.com, non importa se si utilizza un certificato SAN o un certificato con caratteri jolly. Al contrario, se si deve usare il certificato per autodiscover.contoso.com, autodiscover.fabrikam.com e autodiscover.northamerica.contoso.com, è necessario utilizzare un certificato SAN.

• Usare i certificati di un'autorità di certificazione commerciale per le connessioni client ed esterne al server: sebbene sia possibile configurare la maggior parte dei client per considerare attendibile qualsiasi certificato o autorità di certificazione, è molto più semplice usare un certificato da una CA commerciale per le connessioni client ai server Exchange. Non è necessaria alcuna configurazione nel client per considerare attendibile un certificato emesso da una CA commerciale. Molte CA commerciali offrono certificati appositamente configurati per Exchange. È possibile utilizzare EAC o Exchange Management Shell per generare richieste di certificati che funzionino con la maggior parte delle CA.

• Scegliere la CA commerciale corretta: confrontare i prezzi dei certificati e le funzionalità tra ca. Ad esempio:

  • Assicurarsi che la CA sia ritenuta attendibile dai client (sistemi operativi, browser e dispositivi mobili) che si connettono ai server Exchange.

  • Assicurarsi che la CA supporti il tipo di certificato necessario. Ad esempio, non tutte le CA supportano i certificati SAN, la CA potrebbe limitare il numero di nomi comuni utilizzabili in un certificato SAN oppure la CA potrebbe chiedere costi aggiuntivi in base al numero di nomi comuni in un certificato SAN.

  • Vedere se la CA offre un periodo di prova in cui è possibile aggiungere ulteriori nomi comuni ai certificati SAN dopo la loro emissione senza incorrere in eventuali addebiti.

  • Verificare che la licenza del certificato consenta di utilizzare il certificato nel numero di server necessario. Alcune CA consentono di utilizzare il certificato in un solo server.

• Usare la procedura guidata per i certificati di Exchange: un errore comune quando si creano certificati consiste nel dimenticare uno o più nomi comuni necessari per i servizi che si desidera usare. La certificazione guidata in Interfaccia di amministrazione di Exchange consente di includere l'elenco corretto di nomi comuni nella richiesta di certificato. La procedura guidata consente di specificare i servizi che utilizzeranno il certificato e include i nomi comuni che è necessario avere nel certificato per tali servizi. Eseguire la procedura guidata per il certificato quando è stato distribuito il set iniziale di server Exchange 2016 o Exchange 2019 e sono stati determinati i nomi host da usare per i diversi servizi per la distribuzione.

• Usare il minor numero possibile di nomi host: ridurre al minimo il numero di nomi host nei certificati SAN riduce la complessità coinvolta nella gestione dei certificati. Non è obbligatorio includere i nomi host dei singoli server Exchange nei certificati SAN se l'uso previsto del certificato non lo richiede. In genere, è sufficiente includere i nomi DNS visualizzati per i client interni, esterni o per i server esterni che utilizzano il certificato per connettersi a Exchange.

  Per una semplice organizzazione di Exchange Server denominata Contoso, si tratta di un ipotetico esempio dei nomi host minimi necessari:

  • mail.contoso.com: questo nome host copre la maggior parte delle connessioni a Exchange, tra cui Outlook, Outlook sul Web, distribuzione della rubrica offline, Servizi Web Exchange, interfaccia di amministrazione di Exchange ed Exchange ActiveSync.

  • autodiscover.contoso.com: questo nome host specifico è richiesto dai client che supportano l'individuazione automatica, inclusi i client Outlook, Exchange ActiveSync ed Exchange Web Services. Per ulteriori informazioni, vedere Servizio di individuazione automatica.

Proprietà dei certificati autofirmati predefiniti

Alcune delle proprietà più interessanti dei certificati autofirmati predefiniti visibili in Interfaccia di amministrazione di Exchange e/o Exchange Management Shell in un server Exchange sono descritte nella seguente tabella.

^* Queste proprietà non sono visibili nella visualizzazione standard in Exchange Management Shell. Per visualizzarle, è necessario specificare il nome della proprietà (corrispondenza nome esatto o casuale) con i cmdlet Format-Table o Format-List. Ad esempio:

• Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *

• Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*

Per altre informazioni, vedere Get-ExchangeCertificate.

Ulteriori dettagli sui certificati autofirmati predefiniti visibili in Gestione certificati Windows sono descritti nella seguente tabella.

¹ Si applica alle nuove installazioni dell'aggiornamento cumulativo 22 o versione successiva di Exchange 2016 e dell'aggiornamento cumulativo 11 di Exchange 2019 o versione successiva. Per altre informazioni, vedere Certificati di Exchange Server 2019 e 2016 creati durante l'installazione usare l'hash SHA-1.

In genere, non si usa Gestione certificati Windows per gestire i certificati Exchange (usare Interfaccia di amministrazione di Exchange o Exchange Management Shell). Si noti che il certificato WMSVC non è un certificato Exchange.