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 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, 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 en 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:
|
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:
|
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:
|
| 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 nivel 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:
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:
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 se cifran y autentican, consulte 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 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 distintos 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 |
Subject Type=End Entity |
No aplicable |
| Algoritmo de huella digital | sha2561 | sha2561 | sha2561 |
1 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.