Certificados digitales y cifrado en Exchange Server

El cifrado y los certificados digitales son consideraciones importantes en cualquier organización. De forma predeterminada, Exchange Server está configurado para usar seguridad de la capa de transporte (TLS) para cifrar la comunicación entre servidores internos de Exchange y entre los servicios de Exchange en el servidor local. Pero, los administradores de Exchange necesitan tener en cuenta sus requisitos de cifrado para la comunicación con clientes internos y externos (equipos y dispositivos móviles), y servidores de mensajería externos.

Nota:

Exchange Server 2019 incluye cambios importantes para mejorar la seguridad de las conexiones de cliente y servidor. La configuración predeterminada para el cifrado habilitará TLS 1.2 únicamente y deshabilitará la compatibilidad con algoritmos antiguos (es decir, DES, 3DES, RC2 y RC4 y MD5). También se dará prioridad a los algoritmos de intercambio de claves de curva elíptica sobre los algoritmos de curva no elíptica. En Exchange Server 2016 y versiones posteriores, todas las opciones de criptografía se heredan de la configuración que se especifica en el sistema operativo. Para obtener más información, consulte Exchange Server procedimientos recomendados de configuración de TLS.

En este tema se describen los diferentes tipos de certificados que están disponibles, la configuración predeterminada de los certificados en Exchange y las recomendaciones para los certificados adicionales que necesitará usar con Exchange.

Para ver los procedimientos necesarios para los certificados de Exchange Server, consulte Procedimientos de certificado en Exchange Server.

Introducción a los certificados digitales

Los certificados digitales son archivos electrónicos que funcionan como una contraseña en línea para comprobar la identidad de un usuario o equipo. Sirven para crear el canal cifrado, que a su vez se usa para las comunicaciones del cliente. Un certificado es una declaración digital emitida por una entidad de certificación (CA) que garantiza la identidad del poseedor del certificado y permite que las partes se comuniquen de manera segura mediante el cifrado.

Los certificados digitales proporcionan los siguientes servicios:

• Cifrado: ayudan a proteger los datos que se intercambian contra robos o alteraciones.

• Autenticación: comprueban que sus titulares (personas, sitios web e incluso dispositivos de red, como enrutadores) son realmente quién o lo que afirman ser. Normalmente, la autenticación es unidireccional, donde el origen comprueba la identidad del destino, pero la autenticación TLS mutua también es posible.

Se pueden emitir certificados para varios usos. Por ejemplo: autenticación de usuario web, autenticación de servidor web, extensiones seguras multipropósito al correo de Internet (S/MIME), protocolo de seguridad de Internet (IPsec) y firma de código.

Un certificado contiene y vincula una clave pública con la identidad de la persona, el equipo o el servicio que posee la clave privada correspondiente. Tanto el cliente como el servidor usan las claves públicas y privadas para cifrar datos antes de transmitirlos. Para los usuarios, equipos y servicios de Windows, la confianza en una CA se establece cuando el certificado raíz se define en el almacén de certificados raíz de confianza y el certificado contiene una ruta de certificación válida. Un certificado se considera válido si no se ha revocado (no se encuentra en la lista de revocación de certificados de CA o CRL) ni ha expirado.

Los tres tipos principales de certificados digitales se describen en la tabla siguiente.

Tipo	Descripción	Ventajas	Desventajas
Certificado autofirmado	El certificado se firma mediante la aplicación que lo ha creado.	Costo (gratuito).	Los dispositivos móviles y los equipos clientes no confían automáticamente en el certificado. El certificado necesita agregarse manualmente al almacén de certificados raíz de confianza en todos los equipos cliente y dispositivos, pero no todos los dispositivos móviles permiten cambios en el almacén de certificados raíz de confianza. No todos los servicios funcionan con certificados autofirmados. Dificultad para establecer una infraestructura para la administración del ciclo de vida del certificado. Por ejemplo, los certificados autofirmados no pueden revocarse.
Certificado emitido por una CA interna	El certificado se emite mediante una infraestructura de clave pública (PKI) de su organización. Un ejemplo son los Servicios de certificados de Active Directory (AD CS). Para obtener más información, vea Información general de Servicios de certificados de Active Directory.	Permite que las organizaciones emitan sus propios certificados. Menos costoso que los certificados de una CA comercial.	Más complejidad para implementar y mantener la PKI. Los dispositivos móviles y los equipos clientes no confían automáticamente en el certificado. El certificado necesita agregarse manualmente al almacén de certificados raíz de confianza en todos los equipos cliente y dispositivos, pero no todos los dispositivos móviles permiten cambios en el almacén de certificados raíz de confianza.
Certificado emitido por una CA comercial	El certificado se compra desde una CA comercial de confianza.	Implementación de certificados simplificada, porque todos los clientes, dispositivos y servidores confían automáticamente en los certificados.	Costo. Necesita planear con antelación para minimizar el número de certificados que se necesitan.

Para demostrar que un titular de certificado es quien dice ser, el certificado debe identificar con precisión el titular del certificado a otros clientes, dispositivos o servidores. Los tres métodos básicos para hacer esto se describen en la tabla siguiente.

Método	Descripción	Ventajas	Desventajas
Coincidencia de asunto del certificado	El campo Subject del certificado contiene el nombre común (CN) del host. Por ejemplo, el certificado que se emite para www.contoso.com se puede usar para el sitio https://www.contoso.comweb .	Compatible con todos los clientes, dispositivos y servicios. Compartimentación. Revocar el certificado de un host no afecta a los demás hosts.	Número de certificados necesarios. Solo puede usar el certificado para el host especificado. Por ejemplo, no puede usar el certificado de www.contoso.com para ftp.contoso.com, incluso cuando los servicios están instalados en el mismo servidor. Complejidad. En un servidor web, cada certificado necesita su propio enlace de direcciones IP.
Coincidencia del nombre alternativo del firmante (SAN) del certificado	Además del campo Subject, el campo Subject Alternative Name del certificado contiene una lista de varios nombres de host. Por ejemplo: www.contoso.com ftp.contoso.com ftp.eu.fabirkam.net	Comodidad. Puede usar el mismo certificado para varios hosts en varios dominios independientes. La mayoría de los clientes, dispositivos y servicios admiten certificados de SAN. Auditoría y seguridad. Sabe exactamente qué hosts pueden usar el certificado de SAN.	Se necesita más planeación. Necesita proporcionar la lista de hosts cuando cree el certificado. Falta de compartimentación. No puede revocar certificados de manera selectiva para algunos de los hosts especificados sin que afecte a todos los hosts del certificado.
Coincidencia del certificado comodín	El campo Subject del certificado contiene el nombre común como el carácter comodín (*) además de un dominio o subdominio único. Por ejemplo, *.contoso.com o *.eu.contoso.com. El certificado comodín *.contoso.com puede usarse para: www.contoso.com ftp.contoso.com mail.contoso.com	Flexibilidad. No es necesario proporcionar una lista de hosts al solicitar el certificado y puede usar el certificado en cualquier número de hosts que pueda necesitar en el futuro.	No puede usar certificados comodín con otros dominios de primer nivel (TLD). Por ejemplo, no puede usar el certificado comodín *.contoso.com para los hosts de *.contoso.net. Solo puede usar certificados comodín para nombres de host en el nivel del carácter comodín. Por ejemplo, no puede usar el certificado *.contoso.com para www.eu.contoso.com. O bien, no puede usar el certificado *.eu.contoso.com para www.uk.eu.contoso.com. Los servicios, aplicaciones, dispositivos o clientes antiguos puede que no sean compatibles con los certificados comodín. Los caracteres comodín no están disponibles para los certificados de validación extendida (EV). Se necesita un control y una auditoría minuciosa. Si el certificado comodín está en peligro, afecta a cada host del dominio especificado.

Certificados en Exchange

Al instalar Exchange 2016 o Exchange 2019 en un servidor, Exchange crea e instala dos certificados autofirmados. Microsoft Windows crea e instala un tercer certificado autofirmado para el servicio de administración web en Internet Information Services (IIS). Estos tres certificados están visibles en el Centro de administración de Exchange (EAC) y el Shell de administración de Exchange, y se describen en la tabla siguiente:

Nombre	Comentarios
Microsoft Exchange	Este certificado autofirmado de Exchange tiene las siguientes características: Todos los servidores de Exchange de la organización confían automáticamente en el certificado. Esto incluye los servidores de transporte perimetral suscritos a la organización de Exchange. El certificado está habilitado automáticamente para todos los servicios de Exchange excepto la mensajería unificada, y se usa para cifrar la comunicación interna entre servidores de Exchange, servicios de Exchange en el mismo equipo y las conexiones de cliente redirigidas mediante proxy desde los servicios de acceso de cliente a los servicios de back-end en servidores de buzón. (Nota: La mensajería unificada no está disponible en Exchange 2019). El certificado está habilitado automáticamente para las conexiones entrantes desde servidores externos de mensajes de SMTP, y para las conexiones salientes para servidores externos de mensajes de SMTP. Esta configuración predeterminada permite a Exchange proporcionar TLS oportunista en todas las conexiones SMTP entrantes y salientes. Exchange intenta cifrar la sesión de SMTP con un servidor externo de mensajes, pero si el servidor externo no admite el cifrado TLS, la sesión no se cifra. El certificado no proporciona una comunicación cifrada con clientes internos o externos. Los clientes y servidores no confían en el certificado autofirmado de Exchange, porque el certificado no se define en sus almacenes de certificados raíz de confianza.
Certificado de autenticación de Microsoft Exchange Server	Este certificado autofirmado de Exchange se usa para la autenticación de servidor a servidor y la integración con OAuth. Para obtener más información, vea Planear la integración de Exchange Server con SharePoint y Skype Empresarial.
WMSVC	El Servicio de administración web de IIS usa este certificado autofirmado de Windows para habilitar la administración remota del servidor web y sus aplicaciones y sitios web asociados. Si quita este certificado, el Servicio de administración web no podrá iniciarse si no está seleccionado ningún certificado válido. Tener el servicio en este estado puede impedir que instale actualizaciones de Exchange, o que desinstale Exchange del servidor. Para obtener instrucciones sobre cómo corregir este problema, consulte Id. de evento 1007: Autenticación del servicio de administración web de IIS.

Las propiedades de estos certificados autofirmados se describen en la sección Propiedades de los certificados autofirmados predeterminados.

Estos son los problemas principales que necesita tener en cuenta cuando se trata de certificados en Exchange:

• No necesita reemplazar el certificado autofirmado de Microsoft Exchange para cifrar el tráfico de red entre servidores y servicios de Exchange de su organización.

• Necesita certificados adicionales para cifrar las conexiones de los servidores de Exchange mediante clientes internos y externos.

• Necesita certificados adicionales para forzar el cifrado de las conexiones de SMTP entre los servidores de Exchange y los servidores externos de mensajes.

Los siguientes elementos de planeación e implementación para Exchange Server son controladores importantes para los requisitos de certificado:

• Equilibrio de carga: ¿tiene previsto finalizar el canal cifrado en el equilibrador de carga o en el servidor proxy inverso, usar equilibradores de carga de capa 4 o de capa 7 y usar afinidad de sesión o sin afinidad de sesión? Para obtener más información, vea Load Balancing in Exchange 2016 (Equilibrio de carga en Exchange 2016).

• Planeamiento de espacios de nombres: ¿Qué versiones de Exchange están presentes, está usando el modelo de espacio de nombres enlazado o sin enlazar y usa DNS de cerebro dividido (configurar distintas direcciones IP para el mismo host en función del acceso interno frente al externo)? Para obtener más información, vea Namespace Planning in Exchange 2016 (Planeación del espacio de nombres en Exchange 2016).

• Conectividad de cliente: ¿Qué servicios usarán los clientes (servicios basados en web, POP, IMAP, etc.) y qué versiones de Exchange están implicadas? Para obtener más información, consulte los siguientes temas:

  • Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2013 (Conectividad de cliente en un entorno de coexistencia de Exchange 2016 con Exchange 2013)

  • Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010 (Conectividad de cliente en un entorno de coexistencia de Exchange 2016 con Exchange 2010)

  • Client Connectivity in an Exchange 2016 Coexistence Environment with Mixed Exchange Versions (Conectividad de cliente en un entorno de coexistencia de Exchange 2016 con versiones mixtas de Exchange)

Los certificados criptográficos de curva elíptica admiten en Exchange Server

Los certificados ECC, o certificados criptográficos de curva elíptica, son un tipo de certificado digital que usa el algoritmo de curva elíptica para el cifrado, lo que proporciona una mayor seguridad con longitudes de clave más cortas en comparación con los certificados RSA tradicionales.

A partir de la actualización de revisiones (HU) Exchange Server de abril de 2024, Exchange Server 2016 y Exchange Server 2019 admite el uso de certificados de criptografía de curva elíptica (ECC) para algunos servicios. Hemos realizado algunos ajustes importantes con la actualización de seguridad (SU) de noviembre de 2024 de Exchange Server para resolver problemas conocidos y habilitar la compatibilidad con certificados ECC para escenarios adicionales (por ejemplo, POP3 e IMAP). Asegúrese de instalar la actualización de Exchange Server más reciente antes de habilitar la compatibilidad con certificados ECC.

Advertencia

Los siguientes escenarios no admiten actualmente el uso de certificados ECC. Estamos trabajando en una actualización para admitir estos escenarios en el futuro:

• El certificado de confianza de federación debe ser un certificado RSA.
• El certificado Exchange Server OAuth debe ser un certificado RSA.
• Los certificados ECC no se pueden usar cuando se configura El uso de la autenticación basada en notificaciones de AD FS

Compruebe la tabla de la sección siguiente para comprender qué servicios se pueden usar con un certificado ECC.

La compatibilidad con certificados ECC está deshabilitada de forma predeterminada y se puede habilitar mediante la creación de un valor del Registro. El comando debe ejecutarse en cada Exchange Server de la organización. El cambio puede tardar hasta 15 minutos en activarse.

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

La invalidación, que se introdujo con la actualización de revisiones (HU) de abril de 2024 de Exchange Server, ya no debe usarse porque no habilita totalmente la compatibilidad con certificados ECC. Se recomienda quitar la invalidación. Abra un nuevo Shell de administración de Exchange (EMS) después de ejecutar el 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

Requisitos de certificado para servicios de Exchange

Los servicios de Exchange a los que se pueden asignar los certificados se describen en la tabla siguiente.

Servicio	Descripción	Certificado ECC compatible
IIS (HTTP)	De manera predeterminada, los siguientes servicios se ofrecen en el sitio web predeterminado en los servicios de acceso de cliente (front-end) en un servidor de buzón, y los clientes los usan para conectarse a Exchange: Detección automática Exchange ActiveSync Centro de administración de Exchange Servicios web de Exchange Distribución de la libreta de direcciones sin conexión (OAB) Outlook en cualquier lugar (RPC sobre el proxy HTTP) Outlook MAPI sobre HTTP Outlook en la web PowerShell remoto* Como solo puede asociar un certificado único a un sitio web, todos los nombres DNS que los clientes usan para conectarse a estos servicios necesitan incluirse en el certificado. Puede obtener esto mediante un certificado de SAN o un certificado comodín.	Yes
POP o IMAP	Los certificados usados para POP o IMAP pueden ser diferentes del certificado usado para IIS. En cambio, para simplificar la administración, recomendamos que también incluya los nombres de host que se usan para POP o IMAP en el certificado IIS, y use el mismo certificado para todos estos servicios.	Yes
SMTP	Las conexiones de SMTP de clientes o servidores de mensajes se aceptan por uno o más conectores de recepción que están configurados en el servicio de Transporte front-end en el servidor de Exchange. Para obtener más información, vea Conectores de recepción. Para requerir el cifrado TLS en las conexiones de SMTP, puede usar un certificado independiente para cada conector de recepción. El certificado debe incluir el nombre DNS que usan los servidores o clientes de SMTP para conectarse al conector de recepción. Para que la administración de certificados sea más sencilla, considere la posibilidad de incluir en un solo certificado todos los nombres DNS para los que es necesario el tráfico TLS. Para requerir la autenticación TLS mutua, donde las conexiones SMTP entre los servidores de origen y de destino se cifran y autentican, consulte Seguridad del dominio.	Yes
EdgeSync	Para obtener más información, vea Suscripciones perimetrales en Exchange Server	No
Mensajería unificada (UM)	Para obtener más información, vea Deploying Certificates for UM. Nota: La mensajería unificada no está disponible en Exchange 2019.	Yes
Implementación híbrida con Microsoft 365 o Office 365	Para obtener más información, vea Certificate Requirements for Hybrid Deployments.	Yes
Extensiones seguras multipropósito al correo de Internet (S/MIME)	Para obtener más información, vea S/MIME para la firma y el cifrado de mensajes.	No

^* La autenticación Kerberos y el cifrado Kerberos se usan para el acceso remoto a PowerShell, tanto desde Centro de administración de Exchange como desde Shell de administración de Exchange. Por lo tanto, no necesita configurar sus certificados para usarlos con PowerShell remoto, siempre que se conecte directamente a un servidor de Exchange (no a un espacio de nombres de carga equilibrada). Para usar PowerShell remoto para conectarse a un servidor exchange desde un equipo que no sea miembro del dominio o para conectarse desde Internet, debe configurar los certificados para su uso con PowerShell remoto.

Procedimientos recomendados para los certificados de Exchange

Aunque la configuración de los certificados digitales de la organización variará en función de sus necesidades específicas, a continuación se incluye información sobre prácticas recomendadas que puede serle útil a la hora de elegir la configuración de certificados digitales más adecuada.

• Use tan pocos certificados como sea posible: muy probablemente, esto significa usar certificados SAN o certificados comodín. En términos de interoperabilidad con Exchange, ambos son equivalentes a nivel funcional. La decisión de si usar un certificado de SAN o un certificado comodín depende más de las características o limitaciones principales (reales o percibidas) para cada tipo de certificado como se describe en la Introducción a los certificados digitales.

  Por ejemplo, si todos sus nombres comunes van a estar en el mismo nivel de contoso.com, no importa si usa un certificado de SAN o un certificado comodín. Pero, si necesita usar el certificado para autodiscover.contoso.com, autodiscover.fabrikam.com y autodiscover.northamerica.contoso.com, necesita usar un certificado de SAN.

• Usar certificados de una entidad de certificación comercial para las conexiones de cliente y servidor externo: aunque puede configurar la mayoría de los clientes para que confíen en cualquier emisor de certificados o certificados, es mucho más fácil usar un certificado de una ENTIDAD de certificación comercial para las conexiones de cliente a los servidores de Exchange. No se necesita ninguna configuración en el cliente para que confíe en un certificado que se ha emitido mediante una CA comercial. Muchas CA comerciales ofrecen certificados que están configurados específicamente para Exchange. Puede usar el EAC o el Shell de administración de Exchange para generar solicitudes de certificado que funcionen con la mayoría de las CA comerciales.

• Elija la CA comercial adecuada: compare los precios y las características de los certificados entre ca. Por ejemplo:

  • Compruebe que la CA es de confianza para los clientes (sistemas operativos, exploradores y dispositivos móviles) que se conectan a los servidores de Exchange.

  • Compruebe que la CA admite el tipo de certificado que necesita. Por ejemplo, no todas las CA admiten certificados de SAN, la CA puede limitar el número de nombres comunes que puede usar en un certificado de SAN, o la CA puede facturarle más en función del número de nombres comunes de un certificado de SAN.

  • Vea si la CA ofrece un período de gracia durante el que puede agregar nombres comunes adicionales a certificados de SAN después de que se emitan sin cargos.

  • Compruebe que la licencia del certificado le permite usar el certificado en el número de servidores necesario. Algunas CA solo le permiten usar el certificado en un servidor.

• Usar el Asistente para certificados de Exchange: un error común al crear certificados es olvidar uno o varios nombres comunes necesarios para los servicios que desea usar. El Asistente para certificados en el Centro de administración de Exchange le ayuda a incluir la lista correcta de nombres comunes en la solicitud del certificado. El asistente le permite especificar los servicios que usará el certificado, e incluye los nombres comunes que necesita tener en el certificado para esos servicios. Ejecute el Asistente para certificados cuando haya implementado el conjunto inicial de servidores de Exchange 2016 o Exchange 2019 y determine qué nombres de host usar para los diferentes servicios para la implementación.

• Use el menor número posible de nombres de host: minimizar el número de nombres de host en los certificados SAN reduce la complejidad que implica la administración de certificados. No se sienta obligado a incluir los nombres de host de servidores de Exchange individuales en certificados de SAN si el uso previsto para el certificado no lo necesita. Normalmente, solo necesita incluir los nombres DNS que se presentan a los clientes internos, clientes externos o servidores externos que usan el certificado para conectarse a Exchange.

  Para una organización Exchange Server sencilla denominada Contoso, este es un ejemplo hipotético de los nombres de host mínimos que serían necesarios:

  • mail.contoso.com: este nombre de host cubre la mayoría de las conexiones a Exchange, incluidos Outlook, Outlook en la Web, distribución de OAB, Servicios web de Exchange, Centro de administración de Exchange y Exchange ActiveSync.

  • autodiscover.contoso.com: este nombre de host específico es necesario para los clientes que admiten la detección automática, incluidos los clientes de Outlook, Exchange ActiveSync y Exchange Web Services. Para más información, vea Servicio Detección automática.

Propiedades de los certificados autofirmados predeterminados

Algunas de las propiedades más interesantes de los certificados autofirmados predeterminados que están visibles en el Centro de administración de Exchange o el Shell de administración de Exchange en un servidor de Exchange se describen en la tabla siguiente.

Propiedad	Microsoft Exchange	Certificado de autenticación de Microsoft Exchange Server	WMSVC
Asunto	CN=<ServerName> (por ejemplo, CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (por ejemplo, CN=WMSvc-Mailbox01)
Nombres alternativos del firmante (CertificateDomains)	<ServerName> (por ejemplo, Mailbox01) <ServerFQDN> (por ejemplo, Mailbox01.contoso.com)	ninguno	WMSvc-<ServerName> (por ejemplo, WMSvc-Mailbox01)
Tiene clave privada (HasPrivateKey)	Sí (True)	Sí (True)	Sí (True)
PrivateKeyExportable*	Falso	True	True
EnhancedKeyUsageList*	Autenticación del servidor (1.3.6.1.5.5.7.3.1)	Autenticación del servidor (1.3.6.1.5.5.7.3.1)	Autenticación del servidor (1.3.6.1.5.5.7.3.1)
IISServices*	IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (por ejemplo, IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2)	ninguno	ninguno
IsSelfSigned	True	True	True
Emisor	CN=<ServerName> (por ejemplo, CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (por ejemplo, CN=WMSvc-Mailbox01)
NotBefore	Le fecha y la hora en la que se ha instalado Exchange.	Le fecha y la hora en la que se ha instalado Exchange.	La fecha y la hora en la que el Servicio de administración web de IIS se ha instalado.
Expira en (NotAfter)	5 años después de NotBefore.	5 años después de NotBefore.	10 años después de NotBefore.
Tamaño de clave pública (PublicKeySize)	2048	2048	2048
RootCAType	Registro	Ninguno	Registro
Servicios	IMAP, POP, IIS, SMTP	SMTP	Ninguno

^* Estas propiedades no están visibles en la vista estándar en el Shell de administración de Exchange. Para verlas, necesita especificar el nombre de propiedad (nombre exacto o coincidencia de carácter comodín) con los cmdlets Format-Table o Format-List. Por ejemplo:

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

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

Para obtener más información, vea Get-ExchangeCertificate.

En la siguiente tabla se describen más detalles sobre los certificados autofirmados predeterminados que son visibles en el Administrador de certificados de Windows.

Propiedad	Microsoft Exchange	Certificado de autenticación de Microsoft Exchange Server	WMSVC
Algoritmo de firma	sha256RSA1	sha256RSA1	sha256RSA1
Algoritmo hash de firma	sha2561	sha2561	sha2561
Uso de la clave	Firma digital, cifrado de clave (a0)	Firma digital, cifrado de clave (a0)	Firma digital, cifrado de clave (a0), cifrado de datos (b0 00 00 00)
Restricciones básicas	Subject Type=End Entity Path Length Constraint=None	Subject Type=End Entity Path Length Constraint=None	No aplicable
Algoritmo de huella digital	sha2561	sha2561	sha2561

¹ Se aplica a las instalaciones nuevas de la actualización acumulativa 22 o posterior de Exchange 2016 y a la actualización acumulativa 11 o posterior de Exchange 2019. Para obtener más información, consulte Exchange Server certificados de 2019 y 2016 creados durante la instalación, use el hash SHA-1.

Normalmente, no usa el Administrador de certificados de Windows para administrar certificados de Exchange (usa el Centro de administración de Exchange o el Shell de administración de Exchange). Tenga en cuenta que el certificado WMSVC no es un certificado Exchange.