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 le comunicazioni tra i 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.

Nota

Exchange Server 2019 include modifiche importanti per migliorare la sicurezza delle connessioni client e server. La configurazione predefinita per la crittografia prevede l'abilitazione del solo protocollo TLS 1.2 e la disabilitazione del supporto per gli algoritmi meno recenti, ovvero DES, 3DES, RC2, RC4 e MD5. Prevede inoltre la configurazione degli algoritmi di scambio di chiavi a curva ellittica con priorità rispetto agli algoritmi a curva non ellittica. In Exchange Server 2016 e versioni successive tutte le impostazioni di crittografia vengono ereditate dalla configurazione specificata nel sistema operativo. Per altre informazioni, vedere Exchange Server procedure consigliate per la configurazione di TLS.

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.

Tipo	Descrizione	Vantaggi	Svantaggi
Certificato autofirmato	Un certificato firmato dall'applicazione che lo ha creato.	Costo (gratuito).	Il certificato non viene automaticamente considerato attendibile dai computer client e da dispositivi mobili. Il certificato deve essere manualmente aggiunto all'archivio dei certificati radice attendibili in tutti i computer e dispositivi client, ma non tutti i dispositivi consentono modifiche all'archivio dei certificati attendibili. Non tutti i servizi funzionano con certificati autofirmati. Difficile creare un'infrastruttura per la gestione del ciclo di vita del certificato. Ad esempio, i certificati autofirmati non possono essere revocati.
Il certificato emesso da un'autorità di certificazione interna	Il certificato è emesso da un'infrastruttura a chiave pubblica (PKI) nell'organizzazione. Un esempio è Servizi certificati Active Directory (AD CS) di Active Directory. Per ulteriori informazioni, vedere Panoramica sui Servizi certificati Active Directory.	Consente alle organizzazioni di emettere i propri certificati. Meno costosi dei certificati emessi da una CA commerciale.	Aumento della complessità per distribuire e gestire la PKI. Il certificato non viene automaticamente considerato attendibile dai computer client e da dispositivi mobili. Il certificato deve essere manualmente aggiunto all'archivio dei certificati radice attendibili in tutti i computer e dispositivi client, ma non tutti i dispositivi consentono modifiche all'archivio dei certificati attendibili.
Certificato emesso da una CA commerciale	Il certificato viene acquistato da un'autorità di certificazione attendibile commerciale.	Distribuzione del certificato semplificata, perché tutti i client, dispositivi e server considerano automaticamente attendibili i certificati.	Costo. È necessario pianificare in anticipo per ridurre al minimo il numero di certificati necessari.

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.

Metodo	Descrizione	Vantaggi	Svantaggi
Corrispondenza oggetto del certificato	Il campo Subject del certificato contiene il nome comune dell'host. Ad esempio, il certificato emesso per www.contoso.com può essere usato per il sito https://www.contoso.comWeb .	Compatibile con tutti i client, dispositivi e servizi. Classificazione. La revoca del certificato per un host non interessa gli altri host.	Numero di certificati necessari. È possibile utilizzare solo il certificato per l'host specificato. Ad esempio, non è possibile usare il certificato www.contoso.com per ftp.contoso.com, anche quando i servizi sono installati nello stesso server. Complessità. In un server Web, ogni certificato richiede il binding del proprio indirizzo IP.
Corrispondenza del nome alternativo del soggetto del certificato	Oltre al campo Subject, il campo Subject Alternative Name del certificato contiene un elenco di più nomi host. Ad esempio: www.contoso.com ftp.contoso.com ftp.eu.fabirkam.net	Praticità. È possibile utilizzare lo stesso certificato per più host in più domini separati. La maggior parte dei client, dispositivi e servizi supporta i certificati SAN. Controllo e sicurezza. Si sa esattamente quali host sono in grado di utilizzare il certificato SAN.	Ulteriore pianificazione necessaria. È necessario fornire l'elenco di host quando si crea il certificato. Mancanza di classificazione. Non è possibile revocare i certificati in modo selettivo per alcuni host specifici senza interessare tutti gli altri host nel certificato.
Corrispondenza certificato con caratteri jolly	Il campo Subject del certificato contiene il nome comune come carattere jolly (*) più un singolo dominio o sottodominio. Ad esempio, *.contoso.com o *.eu.contoso.com. Il certificato con carattere jolly *.contoso.com può essere utilizzato per: www.contoso.com ftp.contoso.com mail.contoso.com	Flessibilità. Non è necessario fornire un elenco di host quando si richiede il certificato ed è possibile usare il certificato in qualsiasi numero di host che potrebbero essere necessari in futuro.	Non è possibile utilizzare i certificati con caratteri jolly con altri domini di primo livello (TLD). Ad esempio, non è possibile utilizzare il certificato con caratteri jolly *.contoso.com per l'host *.contoso.net. È possibile utilizzare i certificati con caratteri jolly solo per i nomi host a livello del carattere jolly. Ad esempio, non è possibile usare il certificato *.contoso.com per www.eu.contoso.com. In alternativa, non è possibile usare il certificato *.eu.contoso.com per www.uk.eu.contoso.com. I client, dispositivi, applicazioni o servizi precedenti potrebbero non supportare i certificati con caratteri jolly. I caratteri jolly non sono disponibili con i certificati di convalida estesa (EV). Sono necessari un'attenta verifica e controllo. Se il certificato con caratteri jolly è compromesso, influisce ogni host nel dominio specificato.

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:

Nome	Commenti
Microsoft Exchange	Il certificato autofirmato Exchange presenta le seguenti funzionalità: Il certificato è considerato automaticamente attendibile da tutti gli altri server Exchange nell'organizzazione. Sono inclusi tutti i server Trasporto Edge sottoscritti dall'organizzazione di Exchange. Il certificato viene automaticamente abilitato per tutti i servizi Exchange ad eccezione di Messaggistica unificata ed è utilizzato per crittografare la comunicazione interna tra server Exchange, servizi Exchange nello stesso computer e connessioni client trasmesse tramite proxy dai servizi Accesso client ai servizi back-end nei server Cassette postali. Nota: la messaggistica unificata non è disponibile in Exchange 2019. Il certificato è automaticamente abilitato per le connessioni in ingresso dai server di messaggistica SMTP esterni e per le connessioni in uscita per i server di messaggistica SMTP esterni. Questa configurazione predefinita consente a Exchange di fornire TLS opportunistico su tutte le connessioni SMTP in ingresso e in uscita. Exchange tenta di crittografare la sessione SMTP con un server di messaggistica esterno, ma se il server esterno non supporta la crittografia TLS, la sessione viene decrittografata. Il certificato non fornisce comunicazioni crittografate con client interni o esterni. Client e server non considerano attendibili il certificato Exchange autofirmato, poiché il certificato non è definito negli archivi di certificazione radice attendibili.
Microsoft Exchange Server Auth Certificate	Questo certificato autofirmato di Exchange viene utilizzato per l'autenticazione e l'integrazione da server a server tramite OAuth. Per altre informazioni, vedere Pianificare l'integrazione Exchange Server con SharePoint e Skype for Business.
WMSVC	Questo certificato autofirmato di Windows viene utilizzato dal servizio Gestione Web in IIS per abilitare la gestione remota del server Web e dei siti e applicazioni Web ad esso associati. Se si rimuove il certificato, il servizio Gestione Web non potrà essere avviato se non viene selezionato alcun certificato valido. Il servizio in questo stato può impedire di installare gli aggiornamenti di Exchange o di disinstallare Exchange dal server. Per istruzioni su come risolvere questo problema, vedere ID evento 1007 - Autenticazione del servizio di gestione Web IIS

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 hotfix (HU) Exchange Server aprile 2024, Exchange Server 2016 e Exchange Server 2019 supporta l'utilizzo di 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.

Avviso

Gli scenari seguenti non supportano attualmente l'uso di certificati ECC. Stiamo lavorando a un aggiornamento per supportare questi scenari in futuro:

• Non è possibile assegnare certificati ECC nel ruolo server Trasporto Edge
• Il certificato trust federativo deve essere un certificato RSA
• Il certificato OAuth Exchange Server deve essere un certificato RSA
• I certificati ECC non possono essere usati quando viene configurata l'autenticazione basata sulle attestazioni di AD FS

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.

Servizio	Descrizione	Certificato ECC supportato
IIS (HTTP)	Per impostazione predefinita, i seguenti servizi sono disponibili nel sito Web predefinito dei servizi Accesso client (front-end) in un server Cassette postali e vengono utilizzati dai client per connettersi a Exchange: Individuazione automatica Exchange ActiveSync Interfaccia di amministrazione di Exchange Servizi Web Exchange Distribuzione Rubrica fuori rete (OAB, offline address book) Outlook via Internet (RPC su HTTP) Outlook MAPI su HTTP Outlook sul Web Remote PowerShell* Perché è possibile associare solo un singolo certificato a un sito Web, tutti i nomi DNS che i client utilizzano per connettersi a questi servizi devono essere inclusi nel certificato. È possibile effettuare questa operazione utilizzando un certificato SAN o un certificato con caratteri jolly.	Sì
POP o IMAP	I certificati utilizzati per POP o IMAP possono essere diversi dal certificato utilizzato per IIS. Tuttavia, per semplificare l'amministrazione, è consigliabile includere anche i nomi host utilizzati per POP o IMAP nel certificato IIS e utilizzare lo stesso certificato per tutti questi servizi.	Sì
SMTP	Le connessioni SMTP da client o server di messaggistica vengono accettate da uno o più connettori di ricezione configurati nel servizio di trasporto Front-End per il server Exchange. Per ulteriori informazioni, vedere Connettori di ricezione. Per impostare la crittografia TLS per le connessioni SMTP, è possibile utilizzare un certificato distinto per ogni connettore di ricezione. Il certificato deve includere il nome DNS utilizzato dai client o server SMTP per connettersi al connettore di ricezione. Per semplificare la gestione dei certificati, valutare l'inclusione di tutti i nomi DNS per i quali è necessario supportare il traffico TLS in un unico certificato. Per richiedere l'autenticazione TLS reciproca, in cui le connessioni SMTP tra i server di origine e di destinazione sono crittografate e autenticate, vedere Sicurezza del dominio.	Sì
Messaggistica unificata (UM)	Per ulteriori informazioni, vedere Deploying Certificates for UM. Nota: la messaggistica unificata non è disponibile in Exchange 2019.	Sì
Distribuzione ibrida con Microsoft 365 o Office 365	Per ulteriori informazioni, vedere Certificate Requirements for Hybrid Deployments.	Sì
Secure/Multipurpose Internet Mail Extensions (S/MIME)	Per ulteriori informazioni, vedere S/MIME per la firma e la crittografia dei messaggi.	No

^* 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 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 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.

Proprietà	Microsoft Exchange	Microsoft Exchange Server Auth Certificate	WMSVC
Oggetto	CN=<ServerName> (ad esempio, CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (ad esempio, CN=WMSvc-Mailbox01)
Nomi alternativi soggetto (CertificateDomains)	<ServerName> (ad esempio, Mailbox01) <ServerFQDN> (ad esempio, Mailbox01.contoso.com)	nessuno	WMSvc-<ServerName> (ad esempio, WMSvc-Mailbox01)
Ha una chiave privata (HasPrivateKey)	Sì (True)	Sì (True)	Sì (True)
PrivateKeyExportable*	Falso	True	True
EnhancedKeyUsageList*	Autenticazione server (1.3.6.1.5.5.7.3.1)	Autenticazione server (1.3.6.1.5.5.7.3.1)	Autenticazione server (1.3.6.1.5.5.7.3.1)
IISServices*	IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (ad esempio, IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2)	nessuno	nessuno
IsSelfSigned	True	True	True
Autorità di certificazione	CN=<ServerName> (ad esempio, CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (ad esempio, CN=WMSvc-Mailbox01)
NotBefore	Data/ora dell'installazione di Exchange.	Data/ora dell'installazione di Exchange.	Data/ora in cui è stato installato il servizio Gestione Web IIS.
Scade il (NotAfter)	5 anni dopo NotBefore.	5 anni dopo NotBefore.	10 anni dopo NotBefore.
Dimensioni della chiave pubblica (PublicKeySize)	2048	2048	2048
RootCAType	Registro di sistema	Nessuna	Registro di sistema
Servizi	IMAP, POP, IIS, SMTP	SMTP	Nessuno

^* 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.

Proprietà	Microsoft Exchange	Microsoft Exchange Server Auth Certificate	WMSVC
Algoritmo di firma	sha256RSA1	sha256RSA1	sha256RSA1
Algoritmo hash di firma	sha2561	sha2561	sha2561
Utilizzo chiavi	Firma digitale, Crittografia chiave (a0)	Firma digitale, Crittografia chiave (a0)	Firma digitale, Crittografia chiave (a0), Data Encipherment (b0 00 00 00)
Vincoli dei costi	Subject Type=End Entity Path Length Constraint=None	Subject Type=End Entity Path Length Constraint=None	n/d
Algoritmo identificazione personale	sha2561	sha2561	sha2561

¹ 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 Exchange Server certificati 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.