Certificati digitali e crittografia in Exchange Server

SI APPLICA A:2016 2019 Edizione in abbonamento

La crittografia e i certificati digitali sono considerazioni importanti in tutte le organizzazioni. Per impostazione predefinita, Exchange Server è configurato per utilizzare TLS (Transport Layer Security) per crittografare la comunicazione tra i server Exchange interni e tra i servizi Exchange sul 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 di 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: Aiutano a proteggere i dati scambiati da furti o manomissioni.

• Autenticazione: Verificano che i loro titolari (persone, siti Web e persino dispositivi di rete come router) siano veramente chi o cosa affermano 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, Exchange crea e installa due certificati autofirmati. Un terzo certificato autofirmato viene creato e installato da Microsoft Windows per il servizio di 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.

I seguenti elementi di pianificazione e distribuzione per Exchange Server sono fattori importanti per i requisiti dei certificati:

• Bilanciamento del carico: si prevede di terminare il canale crittografato nel servizio di bilanciamento del carico o nel server proxy inverso, di utilizzare i servizi di bilanciamento del carico di layer 4 o 7 e di utilizzare l'affinità di sessione o l'assenza di 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 sta utilizzando il modello dello spazio dei nomi associato o non associato e si sta utilizzando un DNS split-brain (configurazione di indirizzi IP diversi per lo stesso host in base all'accesso interno o esterno)? Per ulteriori informazioni, vedere Pianificazione dello spazio dei nomi in Exchange 2016.

• Connettività client: quali servizi utilizzeranno i 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

Curva ellittica Supporto dei certificati di crittografia in Exchange Server

I certificati ECC, o certificati di crittografia a curva ellittica, sono un tipo di certificato digitale che utilizza l'algoritmo a curva ellittica per la crittografia, fornendo una maggiore sicurezza con chiavi di lunghezza inferiore rispetto ai tradizionali certificati RSA.

A partire dall'aggiornamento dell'hotfix (HU) di aprile 2024 di Exchange Server, Exchange Server 2016 ed Exchange Server 2019 supportano l'uso dei certificati ECC (Elliptic Curve Cryptography) per alcuni servizi. Sono state apportate alcune importanti modifiche con l'aggiornamento della sicurezza di Exchange Server novembre 2024 (SU) per risolvere i problemi noti e abilitare il supporto dei certificati ECC per altri scenari (ad esempio, POP3 e IMAP). Assicurarsi di installare l'aggiornamento più recente di Exchange Server prima di abilitare il supporto dei certificati ECC.

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

Il supporto del certificato ECC è disabilitato per impostazione predefinita e può essere abilitato creando un valore del Registro di sistema. Il comando deve essere eseguito su ogni Exchange Server dell'organizzazione. Possono essere necessari fino a 15 minuti prima che la modifica diventi attiva.

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String

L'override, introdotto con l'aggiornamento dell'hotfix (HU) di aprile 2024 di Exchange Server, non dovrebbe più essere usato perché non abilita completamente il supporto dei certificati ECC. È consigliabile rimuovere l'override. Aprire una nuova Exchange Management Shell (EMS) dopo l'esecuzione del New-SettingOverride comando:

Get-SettingOverride | Where-Object {($_.SectionName -eq "ECCCertificateSupport") -and ($_.Parameters -eq "Enabled=true")} | Remove-SettingOverride
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 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.

• Usa il minor numero possibile di certificati: molto probabilmente ciò 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.

• Utilizzare i certificati di una CA commerciale per le connessioni client e server esterni: sebbene sia possibile configurare la maggior parte dei client in modo che consideri attendibile qualsiasi certificato o autorità di certificazione, è molto più semplice utilizzare un certificato di 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.

• Scegli la CA commerciale giusta: confronta i prezzi e le caratteristiche dei certificati tra le 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.

• Utilizzare la procedura guidata per i certificati di Exchange: Un errore comune durante la creazione dei certificati è quello di dimenticare uno o più nomi comuni necessari per i servizi che si desidera utilizzare. 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 Certificato dopo aver distribuito il set iniziale di server Exchange 2016 o Exchange 2019 e aver determinato quali nomi host utilizzare per i diversi servizi per la distribuzione.

• Utilizzare il minor numero possibile di nomi host: ridurre al minimo il numero di nomi host nei certificati SAN riduce la complessità della 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, questo è un esempio ipotetico 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, Exchange Web Services, interfaccia di amministrazione di Exchange e 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 di Exchange 2016 aggiornamento cumulativo 22 o versione successiva ed Exchange 2019 aggiornamento cumulativo 11 o versione successiva. Per ulteriori informazioni, vedere I certificati di Exchange Server 2019 e 2016 creati durante l'installazione usano 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.