Certificados digitais e criptografia em Exchange Server

Artigo
04/04/2023

Os certificados digitais e a criptografia são considerações importantes em qualquer organização. Por padrão, Exchange Server é configurado para usar o TLS (Transport Layer Security) para criptografar a comunicação entre servidores internos do Exchange e entre os serviços do Exchange no servidor local. Mas os administradores do Exchange devem considerar os requisitos de criptografia para comunicações com clientes internos e externos (computadores e dispositivos móveis) e servidores de mensagens externos.

Observação

Exchange Server 2019 inclui alterações importantes para melhorar a segurança das conexões de cliente e servidor. A configuração padrão para criptografia ativará apenas o TLS 1.2 e desabilitará o suporte a algoritmos mais antigos (ou seja, DES, 3DES, RC2, RC4 e MD5). Ela também configurará algoritmos de troca de chave de curva elíptica com prioridade sobre algoritmos de curva não elíptica. No Exchange Server 2016 e posterior, todas as configurações de criptografia são herdadas da configuração especificada no sistema operacional. Para obter informações adicionais, consulte Exchange Server práticas recomendadas de configuração do TLS.

Este tópico descreve os diferentes tipos de certificados que estão disponíveis, a configuração padrão para certificados no Exchange e recomendações para certificados adicionais que você precisará usar com o Exchange.

Para os procedimentos necessários para certificados em Exchange Server, consulte Procedimentos de certificado em Exchange Server.

Visão geral de certificados digitais

Certificados digitais são arquivos eletrônicos que funcionam como uma senha online para verificar a identidade de um usuário ou computador. Eles são usados para criar o canal criptografado, usado para a comunicações de clientes. Um certificado é uma declaração digital emitida por uma autoridade de certificação (CA), que valida a identidade do portador do certificado e permite que as partes se comuniquem de forma segura, usando criptografia.

Os certificados digitais fornecem os seguintes serviços:

Criptografia: eles ajudam a proteger os dados que são trocados contra roubo ou adulteração.
Autenticação: eles verificam se seus titulares (pessoas, sites e até mesmo dispositivos de rede, como roteadores) são realmente quem ou o que eles afirmam ser. Normalmente, a autenticação é unidirecional, onde a fonte verifica a identidade do destino, mas também é possível a autenticação TLS comum.

Os certificados podem ser emitidos para vários usos. Por exemplo: autenticação de usuário da Web, autenticação de servidor da Web, S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec e assinatura de código.

Um certificado contém uma chave pública e a vincula à identidade de uma pessoa, computador ou serviço que contém a chave privada correspondente. As chaves pública e privada são usadas pelo cliente e pelo servidor para criptografar dados antes que sejam transmitidos. Para usuários, computadores e serviços no Windows, a confiança na CA é estabelecida quando há uma cópia do certificado raiz no armazenamento de certificados raiz confiável e o certificado contém um caminho de certificação válido. Um certificado será considerado válido se não tiver sido revogado (não está na lista de revogação de certificado da CA ou CRL), nem tiver expirado.

Os três tipos principais de certificados digitais são descritos na tabela a seguir.

Tipo	Descrição	Vantagens	Desvantagens
Certificado autoassinado	O certificado é assinado pelo aplicativo que o criou.	Custo (gratuito).	O certificado não é automaticamente confiável para os computadores clientes e os dispositivos móveis. O certificado deve ser adicionado manualmente ao repositório de certificados raiz confiável em todos os computadores clientes e dispositivos, mas nem todos os dispositivos móveis permitem alterações ao repositório de certificados raiz confiável. Nem todos os serviços trabalham com certificados autoassinados. É difícil estabelecer uma infraestrutura para o gerenciamento de ciclo de vida de certificados. Por exemplo, certificados autoassinados não podem ser revogados.
Certificado emitido por uma autoridade de certificação interna	O certificado é emitido por uma infraestrutura de chaves públicas (PKI) em sua organização. Um exemplo é Serviços de certificado (AD CS) do Active Directory. Para obter mais informações, confira Visão geral de Serviços de Certificados do Active Directory.	Permite que as organizações emitam os próprios certificados. Menos caro que os certificados de uma autoridade de certificação comercial.	Aumento da complexidade para implantar e manter o PKI. O certificado não é automaticamente confiável para os computadores clientes e os dispositivos móveis. O certificado deve ser adicionado manualmente ao repositório de certificados raiz confiável em todos os computadores clientes e dispositivos, mas nem todos os dispositivos móveis permitem alterações ao repositório de certificados raiz confiável.
Certificado emitido por uma autoridade de certificação comercial	O certificado é comprado de uma autoridade de certificação comercial confiável.	Implantação simplificada de certificado, porque todos os clientes, dispositivos e servidores confiam automaticamente nos certificados.	Custo. É preciso planejar com antecedência para minimizar o número de certificados necessários.

Tipo

Descrição

Vantagens

Desvantagens

Certificado autoassinado

O certificado é assinado pelo aplicativo que o criou.

Custo (gratuito).

O certificado não é automaticamente confiável para os computadores clientes e os dispositivos móveis. O certificado deve ser adicionado manualmente ao repositório de certificados raiz confiável em todos os computadores clientes e dispositivos, mas nem todos os dispositivos móveis permitem alterações ao repositório de certificados raiz confiável.

Nem todos os serviços trabalham com certificados autoassinados.

É difícil estabelecer uma infraestrutura para o gerenciamento de ciclo de vida de certificados. Por exemplo, certificados autoassinados não podem ser revogados.

Certificado emitido por uma autoridade de certificação interna

O certificado é emitido por uma infraestrutura de chaves públicas (PKI) em sua organização. Um exemplo é Serviços de certificado (AD CS) do Active Directory. Para obter mais informações, confira Visão geral de Serviços de Certificados do Active Directory.

Permite que as organizações emitam os próprios certificados.

Menos caro que os certificados de uma autoridade de certificação comercial.

Aumento da complexidade para implantar e manter o PKI.

Certificado emitido por uma autoridade de certificação comercial

O certificado é comprado de uma autoridade de certificação comercial confiável.

Implantação simplificada de certificado, porque todos os clientes, dispositivos e servidores confiam automaticamente nos certificados.

Custo. É preciso planejar com antecedência para minimizar o número de certificados necessários.

Para provar que um portador do certificado é quem diz ser, o certificado deve identificar precisamente o portador do certificado para outros servidores, dispositivos ou clientes. Os três métodos básicos de fazer isso estão descritos na tabela a seguir.

Método	Descrição	Vantagens	Desvantagens
Correspondência do assunto do certificado	O campo Subject do certificado contém o nome comum (CN) do host. Por exemplo, o certificado emitido para www.contoso.com pode ser usado para o site https://www.contoso.comda Web .	Compatível com todos os clientes, dispositivos e serviços. Compartimentalização. Revogar o certificado para um host não afeta outros hosts.	Número de certificados necessários. Você só pode usar o certificado para o host especificado. Por exemplo, você não pode usar o certificado www.contoso.com para ftp.contoso.com, mesmo quando os serviços são instalados no mesmo servidor. Complexidade. Em um servidor Web, cada certificado requer sua própria vinculação de endereço IP.
Correspondência do nome alternativo da entidade (SAN) do certificado	Além do campo Subject, o campo Subject Alternative Name do certificado contém uma lista de vários nomes de host. Por exemplo: www.contoso.com ftp.contoso.com ftp.eu.fabirkam.net	Conveniência. Você pode usar o mesmo certificado para vários hosts em vários domínios separados. A maioria dos serviços, dos dispositivos e dos clientes dão suporte certificados SAN. Auditoria e segurança. Você sabe exatamente quais hosts são capazes de usar o certificado SAN.	É preciso realizar mais planejamento. Você precisa fornecer a lista de hosts quando cria o certificado. Falta de compartimentalização. Você não pode revogar seletivamente os certificados para alguns hosts especificados sem afetar todos os hosts no certificado.
Correspondência com o certificado curinga	O campo Subject do certificado contém o nome comum como caractere curinga () além de um domínio ou subdomínio único. Por exemplo, .contoso.com ou .eu.contoso.com. O certificado curinga .contoso.com pode ser usado para: www.contoso.com ftp.contoso.com mail.contoso.com	Flexibilidade. Você não precisa fornecer uma lista de hosts quando solicitar o certificado e pode usar o certificado em qualquer número de hosts que talvez precise no futuro.	Não é possível usar os certificados curinga com outros domínios primários (TLDs). Por exemplo, você não pode usar o certificado curinga .contoso.com para hosts .contoso.net. Você só pode usar os certificados curinga para nomes de host no nível do curinga. Por exemplo, você não pode usar o certificado .contoso.com para www.eu.contoso.com. Ou não é possível usar o certificado .eu.contoso.com para www.uk.eu.contoso.com. Os clientes, dispositivos, aplicativos ou serviços mais antigos não dão suporte a certificados curinga. Os caracteres curinga não estão disponíveis com certificados de validação estendida (EV). É preciso ter auditoria e controle cuidadosos. Se o certificado curinga estiver comprometido, isso afetará todos os hosts no domínio especificado.

Método

Descrição

Vantagens

Desvantagens

Correspondência do assunto do certificado

O campo Subject do certificado contém o nome comum (CN) do host. Por exemplo, o certificado emitido para www.contoso.com pode ser usado para o site https://www.contoso.comda Web .

Compatível com todos os clientes, dispositivos e serviços.

Compartimentalização. Revogar o certificado para um host não afeta outros hosts.

Número de certificados necessários. Você só pode usar o certificado para o host especificado. Por exemplo, você não pode usar o certificado www.contoso.com para ftp.contoso.com, mesmo quando os serviços são instalados no mesmo servidor.

Complexidade. Em um servidor Web, cada certificado requer sua própria vinculação de endereço IP.

Correspondência do nome alternativo da entidade (SAN) do certificado

Além do campo Subject, o campo Subject Alternative Name do certificado contém uma lista de vários nomes de host. Por exemplo:

www.contoso.com
ftp.contoso.com
ftp.eu.fabirkam.net

Conveniência. Você pode usar o mesmo certificado para vários hosts em vários domínios separados.

A maioria dos serviços, dos dispositivos e dos clientes dão suporte certificados SAN.

Auditoria e segurança. Você sabe exatamente quais hosts são capazes de usar o certificado SAN.

É preciso realizar mais planejamento. Você precisa fornecer a lista de hosts quando cria o certificado.

Falta de compartimentalização. Você não pode revogar seletivamente os certificados para alguns hosts especificados sem afetar todos os hosts no certificado.

Correspondência com o certificado curinga

O campo Subject do certificado contém o nome comum como caractere curinga (*) além de um domínio ou subdomínio único. Por exemplo, *.contoso.com ou *.eu.contoso.com. O certificado curinga *.contoso.com pode ser usado para:

www.contoso.com
ftp.contoso.com
mail.contoso.com

Flexibilidade. Você não precisa fornecer uma lista de hosts quando solicitar o certificado e pode usar o certificado em qualquer número de hosts que talvez precise no futuro.

Não é possível usar os certificados curinga com outros domínios primários (TLDs). Por exemplo, você não pode usar o certificado curinga *.contoso.com para hosts *.contoso.net.

Você só pode usar os certificados curinga para nomes de host no nível do curinga. Por exemplo, você não pode usar o certificado *.contoso.com para www.eu.contoso.com. Ou não é possível usar o certificado *.eu.contoso.com para www.uk.eu.contoso.com.

Os clientes, dispositivos, aplicativos ou serviços mais antigos não dão suporte a certificados curinga.

Os caracteres curinga não estão disponíveis com certificados de validação estendida (EV).

É preciso ter auditoria e controle cuidadosos. Se o certificado curinga estiver comprometido, isso afetará todos os hosts no domínio especificado.

Certificados no Exchange

Quando você instala o Exchange 2016 ou o Exchange 2019 em um servidor, dois certificados autoassinados são criados e instalados pelo Exchange. Um terceiro certificado autoassinado é criado e instalado pelo Microsoft Windows para o serviço de Gerenciamento da Web no IIS (Internet Information Services). Esses três certificados estão visíveis no Centro de administração do Exchange (EAC) e no Shell de Gerenciamento do Exchange, e são descritos na tabela a seguir:

Nome	Comments
Microsoft Exchange	Esse certificado autoassinado do Exchange tem os seguintes recursos: O certificado é automaticamente confiável por todos os outros servidores do Exchange da organização. Isso inclui todos os servidores do Edge Transport inscritos na organização do Exchange. O certificado é habilitado automaticamente para todos os serviços do Exchange exceto Unificação de Mensagens, e é usado para criptografar a comunicação interna entre servidores do Exchange, serviços do Exchange no mesmo computador e conexões clientes usadas como proxy de serviços de acesso do cliente para os serviços de back-end em servidores de caixa de correio. (Observação: o UM não está disponível no Exchange 2019.) O certificado é habilitado automaticamente para conexões de entrada de servidores de mensagens externos SMTP e conexões de saída para os servidores de mensagens externos SMTP. Essa configuração padrão permite que o Exchange forneça TLS oportunista em todas as conexões SMTP de entrada e saída. O Exchange tenta criptografar a sessão SMTP com um servidor de mensagens externo, mas, se o servidor externo não der suporte a criptografia TLS, a sessão será descriptografada. O certificado não oferece comunicações criptografadas com clientes internos ou externos. Os clientes e os servidores não confiam no certificado autoassinado do Exchange, porque o certificado não está definido em seus armazenamentos de certificações raiz confiáveis.
Certificado de autenticação Microsoft Exchange Server	Esse certificado autoassinado do Exchange é usado para autenticação de servidor para servidor e integração usando OAuth. Para obter mais informações, consulte Planejar Exchange Server integração ao SharePoint e Skype for Business.
WMSVC	Esse certificado autoassinado do Windows é usado pelo serviço de gerenciamento da Web no IIS para habilitar o gerenciamento remoto do servidor Web e seus sites e aplicativos associados. Se você remover esse certificado, o serviço de gerenciamento da Web não iniciará se nenhum certificado válido tiver sido selecionado. Ter o serviço nesse estado poderá impedi-lo de instalar atualizações do Exchange ou desinstalar o Exchange do servidor. Para obter instruções sobre como corrigir esse problema, consulte ID de evento 1007 – Autenticação do Serviço de Gerenciamento Web do IIS

As propriedades esses certificados autoassinados são descritas na seção Propriedades dos certificados autoassinados padrão.

Estes são os principais problemas que você precisa considerar quando se trata de certificados no Exchange:

Não é necessário substituir o certificado autoassinado Microsoft Exchange para criptografar o tráfego de rede entre servidores do Exchange e serviços em sua organização.
Precisa de mais certificados para criptografar conexões com servidores do Exchange por clientes internos e externos.
Precisa de mais certificados para forçar a criptografia de conexões SMTP entre servidores do Exchange e servidores de mensagens externos.

Os seguintes elementos de planejamento e implantação para Exchange Server são drivers importantes para seus requisitos de certificado:

Balanceamento de carga: você planeja encerrar o canal criptografado no balanceador de carga ou no servidor proxy reverso, usar balanceadores de carga Camada 4 ou Camada 7 e usar afinidade de sessão ou nenhuma afinidade de sessão? Para saber mais, confira Balanceamento de carga do Exchange 2016.
Planejamento do namespace: quais versões do Exchange estão presentes, você está usando o modelo de namespace vinculado ou desvinculado e está usando DNS de cérebro dividido (configurando endereços IP diferentes para o mesmo host com base no acesso interno versus externo)? Para saber mais, confira Planejamento de namespace do Exchange 2016.
Conectividade do cliente: quais serviços seus clientes usarão (serviços baseados na Web, POP, IMAP etc.) e quais versões do Exchange estão envolvidas? Para mais informações, confira os seguintes tópicos:

Suporte a certificados de criptografia de curva elíptica no Exchange Server

A partir do Exchange Server Hu (Atualização de Hotfix) de abril de 2024, Exchange Server 2016 e Exchange Server 2019 dá suporte ao uso de certificados ECC (Criptografia de Curva Elíptica) para alguns serviços.

Certificados ECC, ou certificados de criptografia de curva elíptica, são um tipo de certificado digital que usa algoritmo de curva elíptica para criptografia, fornecendo segurança mais forte com comprimentos de chave mais curtos em comparação com certificados RSA tradicionais.

Aviso

Atualmente, os cenários a seguir não dão suporte ao uso de certificados ECC. Estamos trabalhando em uma atualização para dar suporte a esses cenários no futuro:

O certificado Federation Trust deve ser um certificado RSA
O certificado OAuth Exchange Server deve ser um certificado RSA
Os certificados ECC não podem ser usados quando a autenticação baseada em declarações do AD FS é configurada

Verifique a tabela na próxima seção para entender quais serviços podem ser usados com um certificado ECC.

O suporte ao certificado ECC é desabilitado por padrão e pode ser habilitado criando uma substituição. Abra um novo EMS (Exchange Management Shell) após a execução do 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

Requisitos de certificado para serviços do Exchange

Os serviços Exchange aos quais os certificados podem ser atribuídos estão descritos na tabela a seguir.

Serviço	Descrição	Certificado ECC com suporte
IIS (HTTP)	Por padrão, os seguintes serviços são oferecidos no site padrão nos serviços do acesso do cliente (front-end) em um servidor de caixa de correio e usados por clientes para se conectarem ao Exchange: Descoberta Automática Exchange ActiveSync Centro de administração do Exchange Serviços Web do Exchange Distribuição do catálogo de endereços offline (OAB) Outlook em Qualquer Lugar (RPC sobre HTTP) MAPI sobre HTTP no Outlook Outlook na Web PowerShell Remoto^* Como você só pode associar um certificado único a um site, todos os nomes DNS que os clientes usam para se conectarem a esses serviços precisam constar no certificado. Você pode fazer isso usando um certificado SAN ou curinga.	Sim
POP ou IMAP	Os certificados usados para POP ou IMAP podem ser diferentes do certificado usado para o IIS. No entanto, para simplificar a administração, é recomendável que você também inclua os nomes de host usados para POP ou IMAP em seu certificado IIS e use o mesmo certificado para todos esses serviços.	Sim
SMTP	As conexões SMTP de servidores clientes ou de mensagens são aceitos por um ou mais conectores de recebimento que estão configurados no Serviço de Transporte de Front End no servidor do Exchange. Para saber mais, veja Conectores de recebimento. Para exigir a criptografia TLS para as conexões SMTP, você poderá usar um certificado separado para cada conector de recebimento. O certificado deve incluir o nome DNS é usado por clientes ou servidores SMTP para se conectarem ao conector de recebimento. Para simplificar o gerenciamento de certificados, considere incluir todos os nomes DNS cujo tráfego TLS deve ser suportado em um único certificado. Para exigir autenticação mútua do TLS, em que as conexões SMTP entre os servidores de origem e de destino são criptografadas e autenticadas, consulte Domain Security.	Sim
UM (Unificação de Mensagens)	Para saber mais, veja Deploying Certificates for UM. Observação: o UM não está disponível no Exchange 2019.	Sim
Implantação híbrida com o Microsoft 365 ou Office 365	Para saber mais, veja Certificate Requirements for Hybrid Deployments.	Sim
Secure/Multipurpose Internet Mail Extensions (S/MIME)	Para saber mais, veja S/MIME para assinatura e criptografia de mensagens.	Não

^* A autenticação e a criptografia Kerberos são usadas para acesso ao PowerShell remoto, a partir do Centro de administração do Exchange e do Shell de Gerenciamento do Exchange. Portanto, não é necessário configurar seus certificados para uso com o PowerShell remoto, desde que você se conecte diretamente a um servidor do Exchange (não para um namespace com balanceamento de carga). Para usar o PowerShell remoto para se conectar a um servidor exchange de um computador que não é membro do domínio ou para se conectar da Internet, você precisa configurar seus certificados para uso com o PowerShell remoto.

Práticas recomendadas para certificados do Exchange

Embora a configuração dos certificados digitais da sua organização variem com base em suas necessidades específicas, informações sobre práticas recomendadas foram incluídas para ajudá-lo a escolher a configuração de certificado digital certa para você.

Use o menor número possível de certificados: muito provavelmente, isso significa usar certificados SAN ou certificados curinga. Em termos a interoperabilidade com o Exchange, ambos têm funcionalidades equivalentes. A decisão sobre usar um certificado SAN versus um certificado curinga depende das principais limitações ou recursos (reais ou observadas) para cada tipo de certificado conforme descrito na Visão geral de certificados digitais.

Por exemplo, se todos os seus nomes em comum estiverem mesmo nível de contoso.com, não importa se você usar um certificado SAN ou curinga. Mas, se for necessário usar o certificado para autodiscover.contoso.com autodiscover.fabrikam.com e autodiscover.northamerica.contoso.com, será necessário usar um certificado SAN.
Use certificados de uma AC comercial para conexões de servidor externo e cliente: embora você possa configurar a maioria dos clientes para confiar em qualquer emissor de certificado ou certificado, é muito mais fácil usar um certificado de uma AC comercial para conexões de cliente com seus servidores exchange. Nenhuma configuração é necessária no cliente para confiar em um certificado emitido por uma autoridade de certificação comercial. Muitas autoridades de certificação comercial oferecem certificados que são configurados especialmente para Exchange. É possível utilizar o EAC ou o Shell de Gerenciamento do Exchange para gerar solicitações de certificado que funcionam com a maioria das autoridades de certificação comercial.
Escolha a AC comercial certa: compare os preços e os recursos do certificado entre CAs. Por exemplo:
- Verifique se os clientes (sistemas operacionais, navegadores e dispositivos móveis) que se conectarão a seus servidores do Exchange confiam na autoridade de certificação.
- Verifique se a autoridade de certificação oferece suporte ao tipo de certificados de que você precisa. Por exemplo, nem todos os certificados SAN dão suporte a autoridades de certificação, a autoridade de certificação pode limitar o número de nomes comuns que você pode usar em um certificado SAN ou a autoridade de certificação pode cobrem um adicional com base no número de nomes comuns em um certificado SAN.
- Confira se a autoridade de certificação oferece um período de cortesia durante o qual você pode adicionar mais nomes comuns para certificados SAN depois que são emitidos sem serem cobrados.
- Verifique se a licença do certificado permite que você use o certificado no número necessário de servidores. Algumas autoridades de certificação só permitem que você use um certificado em um servidor.
Use o assistente de certificado do Exchange: um erro comum ao criar certificados é esquecer um ou mais nomes comuns necessários para os serviços que você deseja usar. O assistente de certificado no Centro de administração do Exchange ajudará a incluir a lista correta de nomes comuns na solicitação do certificado. O assistente permite especificar os serviços que usam o certificado e incluem os nomes comuns que você precisa ter no certificado para esses serviços. Execute o assistente de certificado quando você implantou seu conjunto inicial de servidores exchange 2016 ou Exchange 2019 e determinou quais nomes de host usar para os diferentes serviços para sua implantação.
Use o menor número possível de nomes de host: minimizar o número de nomes de host em certificados SAN reduz a complexidade envolvida no gerenciamento de certificados. Não se sinta obrigada a incluir os nomes de host de servidores Exchange individuais em certificados SAN se o uso pretendido para o certificado não exigir isso. Normalmente, você só precisa incluir os nomes DNS apresentados para os clientes internos, clientes externos ou servidores externos que usam o certificado para se conectar ao Exchange.

Para uma organização de Exchange Server simples chamada Contoso, este é um exemplo hipotético dos nomes mínimos de host que seriam necessários:
- mail.contoso.com: esse nome de host abrange a maioria das conexões com o Exchange, incluindo Outlook, Outlook na Web, distribuição OAB, Exchange Web Services, Centro de administração do Exchange e Exchange ActiveSync.
- autodiscover.contoso.com: esse nome de host específico é exigido por clientes que dão suporte a Autodiscover, incluindo clientes do Outlook, Exchange ActiveSync e Exchange Web Services. Para saber mais, veja Serviço de descoberta automática.

Propriedades dos certificados autoassinados padrão

Algumas das propriedades mais interessantes dos certificados autoassinados padrão que são visíveis no Centro de administração do Exchange e/ou o Shell de Gerenciamento do Exchange em um servidor do Exchange são descritas na tabela a seguir.

Propriedade	Microsoft Exchange	Certificado de autenticação Microsoft Exchange Server	WMSVC
Assunto	`CN=<ServerName>` (por exemplo, `CN=Mailbox01`)	`CN=Microsoft Exchange Server Auth Certificate`	`CN=WMSvc-<ServerName>` (por exemplo, `CN=WMSvc-Mailbox01`)
Nomes alternativos de assunto (CertificateDomains)	<ServerName> (por exemplo, Mailbox01) <ServerFQDN> (por exemplo, Mailbox01.contoso.com)	none	`WMSvc-<ServerName>` (por exemplo, `WMSvc-Mailbox01`)
Tem chave privada (HasPrivateKey)	Sim (Verdadeiro)	Sim (Verdadeiro)	Sim (Verdadeiro)
Privatekeyexportable^*	Falso	Verdadeiro	Verdadeiro
EnhancedKeyUsageList^*	Autenticação do servidor (1.3.6.1.5.5.7.3.1)	Autenticação do servidor (1.3.6.1.5.5.7.3.1)	Autenticação do servidor (1.3.6.1.5.5.7.3.1)
IISServices^*	`IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2` (por exemplo, `IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2`)	none	none
IsSelfSigned	Verdadeiro	Verdadeiro	Verdadeiro
Emissor	`CN=<ServerName>` (por exemplo, `CN=Mailbox01`)	`CN=Microsoft Exchange Server Auth Certificate`	`CN=WMSvc-<ServerName>` (por exemplo, `CN=WMSvc-Mailbox01`)
Notbefore	A data/hora em que Exchange foi instalado.	A data/hora em que Exchange foi instalado.	A data/hora em que o serviço do Gerenciador do IIS na Web foi instalado.
Expira em (NotAfter)	5 anos após `NotBefore`.	5 anos após `NotBefore`.	10 anos depois `NotBefore`.
Tamanho da chave pública (PublicKeySize)	2048	2048	2048
RootCAType	Registro	None	Registro
Serviços	IMAP, POP, IIS, SMTP	SMTP	None

^* Essas propriedades não estão visíveis no modo de exibição padrão no Shell de Gerenciamento do Exchange. Para vê-las, você precisa especificar o nome da propriedade (nome exato ou correspondência do curinga) com os cmdlets Format-Table ou Format-List. Por exemplo:

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

Para obter mais informações, consulte Get-ExchangeCertificate.

Outros detalhes sobre os certificados autoassinados padrão que estão visíveis no Gerenciador de certificado do Windows são descritos na tabela a seguir.

Propriedade	Microsoft Exchange	Certificado de autenticação Microsoft Exchange Server	WMSVC
Algoritmo de assinatura	sha256RSA¹	sha256RSA¹	sha256RSA¹
Algoritmo de assinatura hash	sha256¹	sha256¹	sha256¹
Uso de chave	Assinatura Digital, Codificação de Chave (a0)	Assinatura Digital, Codificação de Chave (a0)	Assinatura Digital, Codificação de Chave (a0), Codificação de dados (b0 00 00 00)
Restrições básicas	`Subject Type=End Entity` `Path Length Constraint=None`	`Subject Type=End Entity` `Path Length Constraint=None`	n/d
Algoritmo de impressão digital	sha256¹	sha256¹	sha256¹

¹ Aplica-se a novas instalações do Exchange 2016 Cumulativo Atualização 22 ou posterior e Atualização Cumulativa 11 ou posterior do Exchange 2019. Para obter mais informações, consulte Exchange Server certificados 2019 e 2016 criados durante a instalação usam hash SHA-1.

Normalmente, você não usa o Gerenciador de certificados do Windows para gerenciar certificados do Exchange (use o Centro de administração do Exchange ou Shell de Gerenciamento do Exchange). Observe que o certificado WMSVC não é um certificado Exchange.