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 Exchange internos y entre Exchange servicios 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 Guía de TLS de Exchange Server.

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, vea Procedimientos decertificado 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 manipulaciones.

  • Autenticación: comprueban que sus poseedores (personas, sitios web e incluso dispositivos de red como enrutadores) son realmente quién o lo que dicen 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 ha emitido para www.contoso.com puede usarse para el sitio web https://www.contoso.com. 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, ni 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, 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, se crean e instalan dos certificados autofirmados por Exchange. 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 Exchange organización.
  • 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 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 Exchange 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 Plan Exchange Server integration with SharePoint and 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, vea Event ID 1007 - Servicio de administración web de IIS Authentication

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:

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

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.
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 están cifradas y autenticadas, vea Seguridad del dominio.

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.

Implementación híbrida con Microsoft 365 o Office 365 Para obtener más información, vea Certificate Requirements for Hybrid Deployments.
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.

*La autenticación Kerberos y el cifrado Kerberos se usan para el acceso remoto de PowerShell, tanto desde el centro de administración de Exchange como desde el Shell Exchange administración. 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 de Exchange desde un equipo que no es miembro del dominio o para conectarse desde Internet, debe configurar los certificados para usarlos 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 el menor número posible de certificados: es muy probable que esto signifique 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 CA comercial para 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 CA 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 correcta: compare los precios de los certificados y las características entre las 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.

  • Use el Exchange de certificados de Exchange: un error común al crear certificados es olvidar uno o más 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 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 llamada 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 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 Outlook, Exchange ActiveSync y Exchange de servicios web. 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 de sujeto (CertificateDomains) <ServerName> (por ejemplo, Mailbox01)

<ServerFQDN> (por ejemplo, Mailbox01.contoso.com)

ninguno WMSvc-<ServerName> (por ejemplo, WMSvc-Mailbox01 )
Tiene clave privada (HasPrivateKey) (True) (True) (True)
PrivateKeyExportable* False 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 NotBefore de .
Tamaño de clave pública (PublicKeySize) 2048 2048 2048
RootCAType Registro Ninguno Registro
Servicios IMAP, POP, IIS, SMTP SMTP Ninguno

*Estas propiedades no son visibles en la vista estándar del Shell Exchange administración. 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 sha1RSA sha1RSA sha1RSA
Algoritmo hash de firma sha1 sha1 sha1
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

n/d
Algoritmo de huella digital sha1 sha1 sha1

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.