Certificados digitais e encriptação no Exchange Server

Os certificados digitais e a criptografia são considerações importantes em qualquer organização. Por predefinição, o Exchange Server está configurado para utilizar o Transport Layer Security (TLS) para encriptar 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

O Exchange Server 2019 inclui alterações importantes para melhorar a segurança das ligaçõ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, veja Melhores práticas de configuração do TLS do Exchange Server.

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 obter os procedimentos necessários para certificados no Exchange Server, veja Procedimentos de certificado no 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:

• Encriptação: ajudam a proteger os dados trocados contra roubo ou adulteração.

• Autenticação: verificam se os respetivos titulares (pessoas, sites e até mesmo dispositivos de rede, como routers) são realmente quem ou o que 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.

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 utilizado para o site https://www.contoso.com.	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, não pode utilizar o certificado de www.contoso.com para ftp.contoso.com, mesmo quando os serviços estã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. Não precisa de fornecer uma lista de anfitriões quando pedir o certificado e pode utilizar o certificado em qualquer número de anfitriões de que possa precisar 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, não pode utilizar o certificado *.contoso.com para www.eu.contoso.com. Em alternativa, não pode utilizar 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 instala o Exchange 2016 ou o Exchange 2019 num servidor, são criados e instalados dois certificados autoassinados pelo Exchange. Um terceiro certificado autoassinado é criado e instalado pelo Microsoft Windows para o serviço de Gestão Web nos Serviços de Informação Internet (IIS). 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. Isto inclui todos os servidores de Transporte edge subscritos à 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. (Nota: 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. Esta configuração predefinida permite ao Exchange fornecer TLS oportunista em todas as ligaçõ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 Planear a integração do Exchange Server com o SharePoint e o Skype para Empresas.
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 este problema, veja ID do Evento 1007 – Autenticação do Serviço de Gestão 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 planeamento e implementação para o Exchange Server são fatores importantes para os seus requisitos de certificado:

• Balanceamento de carga: planeia terminar o canal encriptado no balanceador de carga ou no servidor proxy inverso, utilizar balanceadores de carga de Camada 4 ou Camada 7 e utilizar a afinidade de sessão ou nenhuma afinidade de sessão? Para saber mais, confira Balanceamento de carga do Exchange 2016.

• Planeamento do espaço de nomes: que versões do Exchange estão presentes, está a utilizar o modelo de espaço de nomes vinculado ou desvinculado e está a utilizar DNS split-brain (configurar diferentes endereços IP para o mesmo anfitrião com base no acesso interno vs. externo)? Para saber mais, confira Planejamento de namespace do Exchange 2016.

• Conectividade do cliente: que serviços os seus clientes utilizarão (serviços baseados na Web, POP, IMAP, etc.) e que versões do Exchange estão envolvidas? Para mais informações, confira os seguintes tópicos:

  • Conectividade de cliente em um ambiente de coexistência do Exchange 2016 com o Exchange 2013

  • Conectividade de cliente em um ambiente de coexistência do Exchange 2016 com o Exchange 2010

  • Conectividade de cliente em um ambiente de coexistência do Exchange 2016 com versões mistas do Exchange

Suporte para certificados de Criptografia de Curva Elíptica no Exchange Server

A partir da Atualização de Correção (HU) de abril de 2024 do Exchange Server, o Exchange Server 2016 e o Exchange Server 2019 suportam a utilização de certificados ECC (Elliptic Curve Cryptography) para alguns serviços.

Os certificados ECC, ou certificados de Criptografia de Curva Elíptica, são um tipo de certificado digital que utiliza o algoritmo de curva elíptica para encriptação, proporcionando uma segurança mais forte com comprimentos de chave mais curtos em comparação com os certificados RSA tradicionais.

Aviso

Os cenários seguintes não suportam atualmente a utilização de certificados ECC. Estamos a trabalhar numa atualização para suportar estes cenários no futuro:

• Não pode atribuir certificados ECC na função de Servidor de Transporte do Edge
• Pode atribuir certificados ECC ao serviço POP e IMAP, mas estes não serão utilizados
• O certificado de Confiança de Federação tem de ser um certificado RSA
• O certificado OAuth do Exchange Server tem de ser um certificado RSA
• Os certificados ECC não podem ser utilizados quando a opção Utilizar a autenticação baseada em afirmações do AD FS está configurada

Verifique a tabela na secção seguinte para compreender que serviços podem ser utilizados com um certificado ECC.

O suporte do certificado ECC está desativado por predefinição e pode ser ativado através da criação de uma substituição. Abra uma nova Shell de Gestão do Exchange (EMS) 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 suportado
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.	Não
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 a autenticação de TLS mútua, em que as ligações SMTP entre os servidores de origem e de destino são encriptadas e autenticadas, veja Domain Security.	Sim
UM (Unificação de Mensagens)	Para saber mais, veja Deploying Certificates for UM. Nota: o UM não está disponível no Exchange 2019.	Sim
Implementação híbrida com o Microsoft 365 ou o 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 utilizar o PowerShell remoto para ligar a um servidor Exchange a partir de um computador que não seja membro do domínio ou para se ligar a partir da Internet, tem de configurar os certificados para utilização 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ê.

• Utilizar o menor número possível de certificados: muito provavelmente, isto significa utilizar certificados SAN ou certificados de carateres universais. 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.

• Utilizar certificados de uma AC comercial para ligações de cliente e servidor externo: embora possa configurar a maioria dos clientes para confiar em qualquer emissor de certificados ou certificados, é muito mais fácil utilizar um certificado de uma AC comercial para ligações de cliente aos 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: comparar os preços e as funcionalidades dos certificados entre as ACs. 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.

• Utilizar o assistente de certificados do Exchange: um erro comum quando cria certificados é esquecer um ou mais nomes comuns que são necessários para os serviços que pretende utilizar. 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 certificados quando tiver implementado o conjunto inicial de servidores do Exchange 2016 ou Exchange 2019 e tiver determinado os nomes de anfitrião a utilizar para os diferentes serviços da sua implementação.

• Utilizar o mínimo de nomes de anfitrião possível: minimizar o número de nomes de anfitrião em certificados SAN reduz a complexidade envolvida na gestão 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 do Exchange Server simples denominada Contoso, este é um exemplo hipotético dos nomes mínimos de anfitrião que seriam necessários:

  • mail.contoso.com: este nome de anfitrião abrange a maioria das ligações ao Exchange, incluindo Outlook, Outlook na Web, distribuição OAB, Serviços Web exchange, centro de administração do Exchange e Exchange ActiveSync.

  • autodiscover.contoso.com: este nome de anfitrião específico é necessário para clientes que suportam a Deteção Automática, 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 do Requerente (CertificateDomains)	<ServerName> (por exemplo, Caixa de Correio01) <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
Está Autoassinado	Verdadeiro	Verdadeiro	Verdadeiro
Emissor	CN=<ServerName> (por exemplo, CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (por exemplo, CN=WMSvc-Mailbox01)
Não Antes	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 a (Não Após)	5 anos depois de NotBefore.	5 anos depois de NotBefore.	10 anos depois de 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	sha256RSA1	sha256RSA1	sha256RSA1
Algoritmo de assinatura hash	sha2561	sha2561	sha2561
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	sha2561	sha2561	sha2561

¹ Aplica-se a novas instalações da Atualização Cumulativa 22 ou posterior do Exchange 2016 e da Atualização Cumulativa 11 ou posterior do Exchange 2019. Para obter mais informações, veja Certificados do Exchange Server 2019 e 2016 criados durante a configuração, utilize o 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.