Compartir a través de

Certificados digitales y SSL

  • Artículo

Se aplica a: Exchange Server 2013

Capa de sockets seguros (SSL) es un método para proteger las comunicaciones entre un cliente y un servidor. Para Exchange Server 2013, SSL se usa para ayudar a proteger las comunicaciones entre el servidor y los clientes. Los clientes pueden ser teléfonos móviles, equipos de la red de una organización y equipos situados fuera de la red de una organización.

De forma predeterminada, al instalar Exchange 2013, las comunicaciones de cliente se cifran mediante SSL al usar Outlook Web App, Exchange ActiveSync y Outlook Anywhere.

SSL requiere que use certificados digitales. En este tema se resumen los distintos tipos de certificados digitales e información sobre cómo configurar Exchange 2013 para usar estos tipos de certificados digitales.

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. Se usan para crear el canal cifrado SSL que se usa para las comunicaciones de cliente. Un certificado es una declaración digital emitida por una entidad de certificación (CA) que responde a la identidad del titular del certificado y permite a las partes comunicarse de forma segura mediante el cifrado.

Los certificados digitales hacen lo siguiente:

  • Autentican que sus titulares (personas, sitios web e incluso recursos de red como enrutadores) son realmente quién o lo que afirman ser.

  • Protegen los datos que se intercambian en línea contra robos o alteraciones.

Los certificados digitales los puede emitir una ENTIDAD de certificación de terceros de confianza o una infraestructura de clave pública (PKI) de Windows mediante Servicios de certificados, o bien se pueden firmar automáticamente. Cada tipo de certificado tiene ventajas y desventajas. Cada tipo de certificado digital es a prueba de manipulaciones y no se puede falsificar.

Se pueden emitir certificados para varios usos. Entre estos usos se incluyen la autenticación de usuario web, la autenticación de servidor web, las extensiones de correo de Internet seguras o multipropósito (S/MIME), la seguridad del protocolo de Internet (IPsec), la seguridad de la capa de transporte (TLS) y la 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. El cliente y el servidor usan las claves públicas y privadas para cifrar los datos antes de transmitirlos. Para los usuarios, equipos y servicios basados en Windows, la confianza en una CA se establece cuando hay una copia del certificado raíz en el almacén de certificados raíz de confianza y el certificado contiene una ruta de certificación válida. Para que el certificado sea válido, el certificado no debe haberse revocado y el período de validez no debe haber expirado.

Tipos de certificados

Hay tres tipos principales de certificados digitales: certificados autofirmados, certificados generados por PKI de Windows y certificados de terceros.

Certificados autofirmados

Al instalar Exchange 2013, se configura automáticamente un certificado autofirmado en los servidores de buzones de correo. La aplicación que lo creó firma un certificado autofirmado. El asunto y el nombre del certificado son iguales. El emisor y el sujeto se definen en el certificado. Este certificado autofirmado se usa para cifrar las comunicaciones entre el servidor de acceso de cliente y el servidor de buzones. El servidor de acceso de cliente confía automáticamente en el certificado autofirmado en el servidor de buzones, por lo que no se necesita ningún certificado de terceros en el servidor de buzones. Al instalar Exchange 2013, también se crea un certificado autofirmado en el servidor de acceso de cliente. Este certificado autofirmado permitirá que algunos protocolos de cliente usen SSL para sus comunicaciones. Exchange ActiveSync y Outlook Web App pueden establecer una conexión SSL mediante un certificado autofirmado. Outlook Anywhere no funcionará con un certificado autofirmado en el servidor de acceso de cliente. Los certificados autofirmados se deben copiar manualmente en el almacén de certificados raíz de confianza en el equipo cliente o dispositivo móvil. Cuando un cliente se conecta a un servidor a través de SSL y el servidor presenta un certificado autofirmado, se pedirá al cliente que compruebe que el certificado lo emitió una entidad de confianza. El cliente debe confiar explícitamente en la autoridad emisora. Si el cliente confirma la confianza, las comunicaciones SSL pueden continuar.

Nota:

De forma predeterminada, el certificado digital instalado en el servidor o servidores de buzón de correo es un certificado autofirmado. No es necesario reemplazar el certificado autofirmado en los servidores de buzones de su organización por un certificado de terceros de confianza. El servidor de acceso de cliente confía automáticamente en el certificado autofirmado en el servidor de buzones de correo y no se necesita ninguna otra configuración para los certificados en el servidor de buzones.

Con frecuencia, las organizaciones pequeñas deciden no usar un certificado de terceros o no instalar su propia PKI para emitir sus propios certificados. Pueden tomar esta decisión porque esas soluciones son demasiado costosas, ya que sus administradores carecen de la experiencia y los conocimientos necesarios para crear su propia jerarquía de certificados, o por ambas razones. El costo es mínimo y la configuración es sencilla cuando se usan certificados autofirmados. Sin embargo, es mucho más difícil establecer una infraestructura para la administración, renovación, administración de confianza y revocación del ciclo de vida de los certificados cuando se usan certificados autofirmados.

Certificados de infraestructura de clave pública de Windows

El segundo tipo de certificado es un certificado generado por PKI de Windows. Una PKI es un sistema de certificados digitales, entidades de certificación y entidades de registro (CA) que comprueban y autentican la validez de cada parte implicada en una transacción electrónica mediante la criptografía de clave pública. Al implementar una PKI en una organización que usa Active Directory, se proporciona una infraestructura para la administración, renovación, administración de confianza y revocación del ciclo de vida de los certificados. Sin embargo, hay algún costo adicional implicado en la implementación de servidores e infraestructura para crear y administrar certificados generados por PKI de Windows.

Los servicios de certificados son necesarios para implementar una PKI de Windows y se pueden instalar a través de Agregar o quitar programas en Panel de control. Los Servicios de Certificate Server se pueden instalar en cualquier servidor del dominio.

Si obtiene certificados de una CA de Windows unida a un dominio, puede usar la CA para solicitar o firmar certificados para emitirlos a sus propios servidores o equipos de la red. Esto le permite usar una PKI como si se tratara de un proveedor externo de certificados, pero con menor costo. Estos certificados PKI no se pueden implementar públicamente, como pueden ser otros tipos de certificados. Sin embargo, cuando una CA PKI firma el certificado del solicitante mediante la clave privada, se comprueba el solicitante. La clave pública de esta CA es parte del propio certificado de la CA. Un servidor que tenga este certificado en el almacén de confianza de certificados de raíz puede usar esa clave pública para autenticar al solicitante y descifrar su certificado.

Los pasos para implementar un certificado generado por PKI son similares a los necesarios para implementar un certificado autofirmado. Todavía debe instalar una copia del certificado raíz de confianza de la PKI en el almacén de certificados raíz de confianza de los equipos o dispositivos móviles que desea poder establecer una conexión SSL a Microsoft Exchange.

Una PKI de Windows permite a las organizaciones publicar sus propios certificados. Los clientes pueden solicitar y recibir certificados de una PKI de Windows en la red interna. La PKI de Windows puede renovar o revocar certificados.

Certificados de terceros de confianza

Los certificados comerciales o de terceros son certificados generados por una entidad de certificación comercial o de terceros y, a continuación, se compran para que los use en los servidores de red. Un problema con los certificados autofirmados y basados en PKI es que, dado que el equipo cliente o el dispositivo móvil no confía automáticamente en el certificado, debe asegurarse de importar el certificado en el almacén de certificados raíz de confianza en equipos y dispositivos cliente. Los certificados comerciales o de terceros no tienen este problema. La mayoría de los certificados de CA comerciales son de confianza porque el certificado ya reside en el almacén de certificados raíz de confianza. Dado que el emisor es de confianza, el certificado también lo es. El uso de certificados de terceros simplifica notablemente la implementación.

En el caso de organizaciones más grandes que deben implementar certificados públicamente, la mejor solución es usar un certificado comercial o de terceros, aunque haya un costo asociado al certificado. Es posible que los certificados comerciales no sean la mejor solución para las organizaciones pequeñas y medianas, y es posible que decida usar una de las otras opciones de certificado que están disponibles.

Elección de un tipo de certificado

Al elegir el tipo de certificado que se va a instalar, hay varias cosas que hay que tener en cuenta. Se debe firmar un certificado para que sea válido. Puede ser autofirmado o firmado por una entidad de certificación. Un certificado autofirmado tiene limitaciones. Por ejemplo, no todos los dispositivos móviles permiten a un usuario instalar un certificado digital en el almacén de certificados raíz de confianza. La capacidad de instalar certificados en un dispositivo móvil depende del fabricante del dispositivo móvil y del proveedor de servicios móviles. Algunos fabricantes y proveedores de servicios móviles deshabilitan el acceso al almacén de certificados raíz de confianza. En este caso, no se puede instalar un certificado autofirmado ni un certificado de una CA PKI de Windows en el dispositivo móvil.

Certificados de Exchange predeterminados

De forma predeterminada, Exchange instala un certificado autofirmado en el servidor de acceso de cliente y en el servidor de buzones de correo para que se cifre toda la comunicación de red. El cifrado de todas las comunicaciones de red requiere que cada servidor exchange tenga un certificado X.509 que pueda usar. Debe reemplazar este certificado autofirmado en el servidor de acceso de cliente por uno de confianza automática para los clientes.

"Autofirmado" significa que el propio servidor exchange creó y firmó un certificado. Dado que no se creó ni firmó por una ENTIDAD de certificación de confianza general, el certificado autofirmado predeterminado no será de confianza para ningún software excepto para otros servidores de Exchange de la misma organización. El certificado predeterminado está habilitado para todos los servicios de Exchange. Tiene un nombre alternativo de firmante (SAN) que corresponde al nombre del servidor de Exchange en el que está instalado. También tiene una lista de SAN que incluyen el nombre del servidor y el nombre de dominio completo (FQDN) del servidor.

Aunque otros servidores de Exchange de la organización de Exchange confían automáticamente en este certificado, los clientes como exploradores web, clientes de Outlook, teléfonos móviles y otros clientes de correo electrónico, además de los servidores de correo electrónico externos, no confiarán automáticamente en él. Por lo tanto, considere la posibilidad de reemplazar este certificado por un certificado de terceros de confianza en los servidores de acceso de cliente de Exchange. Si tiene su propia PKI interna y todos los clientes confían en esa entidad, también puede usar los certificados que emita usted mismo.

Requisitos de certificado por servicio

Los certificados se usan para varias cosas en Exchange. La mayoría de los clientes también usan certificados en más de un servidor exchange. En general, cuantos menos certificados tenga, más fácil será la administración de certificados.

IIS

Todos los siguientes servicios de Exchange usan el mismo certificado en un servidor de acceso de cliente de Exchange determinado:

  • Outlook Web App

  • Centro de administración de Exchange (EAC)

  • Servicios Web de Exchange

  • Exchange ActiveSync

  • Outlook en cualquier lugar

  • Detección automática

  • Distribución de libreta de direcciones de Outlook

Dado que solo se puede asociar un único certificado a un sitio web y a que todos estos servicios se ofrecen en un único sitio web de forma predeterminada, todos los nombres que usan los clientes de estos servicios deben estar en el certificado (o estar bajo un nombre comodín en el certificado).

POP/IMAP

Los certificados que se usan para POP o IMAP se pueden especificar por separado del certificado que se usa para IIS. Sin embargo, para simplificar la administración, se recomienda incluir el nombre del servicio POP o IMAP en el certificado IIS y usar un único certificado para todos estos servicios.

SMTP

Se puede usar un certificado independiente para cada conector de recepción que configure. El certificado debe incluir el nombre que los clientes SMTP (u otros servidores SMTP) usan para llegar a ese conector. Para simplificar la administración de certificados, considere la posibilidad de incluir todos los nombres para los que tiene que admitir el tráfico TLS en un único certificado.

Certificados digitales y proxy

El proxy es el método por el que un servidor envía conexiones de cliente a otro servidor. En el caso de Exchange 2013, esto sucede cuando el servidor de acceso de cliente envía una solicitud de cliente entrante al servidor de buzones de correo que contiene la copia activa del buzón del cliente.

Cuando se solicita el proxy de servidores de acceso de cliente, SSL se usa para el cifrado, pero no para la autenticación. El certificado autofirmado en el servidor de buzones cifra el tráfico entre el servidor de acceso de cliente y el servidor de buzones.

Certificados y servidores proxy inversos

Muchas implementaciones de Exchange usan servidores proxy inversos para publicar servicios de Exchange en Internet. Los servidores proxy inversos se pueden configurar para finalizar el cifrado SSL, examinar el tráfico sin cifrar en el servidor y, a continuación, abrir un nuevo canal de cifrado SSL desde los servidores proxy inversos a los servidores exchange detrás de ellos. Esto se conoce como puente SSL. Otra manera de configurar los servidores proxy inversos es permitir que las conexiones SSL pasen directamente a los servidores exchange detrás de los servidores proxy inversos. Con cualquiera de los modelos de implementación, los clientes de Internet se conectan al servidor proxy inverso mediante un nombre de host para el acceso a Exchange, como mail.contoso.com. A continuación, el servidor proxy inverso se conecta a Exchange con un nombre de host diferente, como el nombre de equipo del servidor de acceso de cliente de Exchange. No es necesario incluir el nombre de equipo del servidor de acceso de cliente de Exchange en el certificado porque los servidores proxy inversos más comunes pueden coincidir con el nombre de host original que usa el cliente con el nombre de host interno del servidor de acceso de cliente de Exchange.

SSL y DNS dividido

Dividir DNS es una tecnología que permite configurar diferentes direcciones IP para el mismo nombre de host, en función de dónde procede la solicitud DNS de origen. Esto se conoce también como DNS de horizonte dividido, DNS de vista dividida o DNS de cerebro dividido. El DNS dividido contribuye a reducir el número de nombres de host que debe administrar para Exchange, ya que permite que los clientes se conecten a Exchange a través del mismo nombre de host, independientemente de si se conectan desde Internet o desde una intranet. Dns dividido permite que las solicitudes que se originan en la intranet reciban una dirección IP diferente a las solicitudes que se originan en Internet.

La división de DNS suele ser innecesaria en una pequeña implementación de Exchange porque los usuarios pueden acceder al mismo punto de conexión DNS independientemente de si proceden de la intranet o de Internet. Sin embargo, con implementaciones más grandes, esta configuración provocará una carga demasiado alta en el servidor proxy de Internet saliente y en el servidor proxy inverso. Para implementaciones más grandes, configure DNS dividido para que, por ejemplo, los usuarios externos accedan a mail.contoso.com y los usuarios internos accedan a internal.contoso.com. El uso de DNS dividido para esta configuración garantiza que los usuarios no tendrán que recordar usar nombres de host diferentes en función de dónde se encuentren.

Windows PowerShell remoto

La autenticación Kerberos y el cifrado Kerberos se usan para el acceso remoto Windows PowerShell, tanto desde el Centro de administración de Exchange (EAC) como desde el Shell de administración de Exchange. Por lo tanto, no tendrá que configurar los certificados SSL para su uso con Windows PowerShell remotas.

Procedimientos recomendados de certificados digitales

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.

Procedimiento recomendado: Uso de un certificado de terceros de confianza

Para evitar que los clientes reciban errores relacionados con certificados que no son de confianza, el certificado que usa el servidor exchange debe ser emitido por alguien en el que confíe el cliente. Aunque la mayoría de los clientes se pueden configurar para confiar en cualquier emisor de certificados o certificados, es más sencillo usar un certificado de terceros de confianza en el servidor exchange. Esto se debe a que la mayoría de los clientes ya confían en sus certificados raíz. Hay varios emisores de certificados de terceros que ofrecen certificados configurados específicamente para Exchange. Puede usar el EAC para generar solicitudes de certificado que funcionen con la mayoría de los emisores de certificados.

Selección de una entidad de certificación

Una entidad de certificación (CA) es una empresa que emite y garantiza la validez de los certificados. El software cliente (por ejemplo, exploradores como Microsoft Internet Explorer o sistemas operativos como Windows o Mac OS) tienen una lista integrada de CA en las que confían. Esta lista normalmente se puede configurar para agregar y quitar CA, pero esa configuración suele ser complicada. Use los siguientes criterios al seleccionar una entidad de certificación a la que comprar los certificados:

  • Asegúrese de que la CA es de confianza para el software cliente (sistemas operativos, exploradores y teléfonos móviles) que se conectará a los servidores de Exchange.

  • Elija una ENTIDAD de certificación que indique que admite "certificados de comunicaciones unificadas" para su uso con exchange server.

  • Asegúrese de que la entidad de certificación admite los tipos de certificados que va a usar. Considere la posibilidad de usar certificados de nombre alternativo de firmante (SAN). No todas las ENTIDADes de certificación admiten certificados SAN y otras ca no admiten tantos nombres de host como pueda necesitar.

  • Asegúrese de que la licencia que compra para los certificados le permite colocar el certificado en el número de servidores que piensa usar. Algunas ENTIDADes de certificación solo permiten colocar un certificado en un servidor.

  • Compare los precios de los certificados entre ca.

Procedimiento recomendado: Uso de certificados SAN

En función de cómo configure los nombres de servicio en la implementación de Exchange, el servidor de Exchange puede requerir un certificado que pueda representar varios nombres de dominio. Aunque un certificado comodín, como el de *.contoso.com, puede resolver este problema, muchos clientes se sienten incómodos con las implicaciones de seguridad de mantener un certificado que se puede usar para cualquier subdominio. Una alternativa más segura es enumerar cada uno de los dominios necesarios como SAN en el certificado. De forma predeterminada, este enfoque se usa cuando Exchange genera solicitudes de certificado.

Procedimiento recomendado: Uso del Asistente para certificados de Exchange para solicitar certificados

Hay muchos servicios en Exchange que usan certificados. Un error común al solicitar certificados es realizar la solicitud sin incluir el conjunto correcto de nombres de servicio. El Asistente para certificados del Centro de administración de Exchange le ayudará a incluir la lista correcta de nombres en la solicitud de certificado. El asistente le permite especificar con qué servicios debe trabajar el certificado y, en función de los servicios seleccionados, incluye los nombres que debe tener en el certificado para que se pueda usar con esos servicios. Ejecute el Asistente para certificados cuando haya implementado el conjunto inicial de servidores de Exchange 2013 y determine qué nombres de host usar para los distintos servicios de la implementación. Lo ideal es que solo tenga que ejecutar el Asistente para certificados una vez para cada sitio de Active Directory donde implemente Exchange.

En lugar de preocuparse por olvidar un nombre de host en la lista SAN del certificado que compra, puede usar una entidad de certificación que ofrezca, sin cargo alguno, un período de gracia durante el cual puede devolver un certificado y solicitar el mismo certificado nuevo con algunos nombres de host adicionales.

Procedimiento recomendado: Usar el menor número posible de nombres de host

Además de usar el menor número posible de certificados, también debe usar el menor número posible de nombres de host. Esta práctica puede ahorrar dinero. Muchos proveedores de certificados cobran una tarifa en función del número de nombres de host que agregue al certificado.

El paso más importante que puede realizar para reducir el número de nombres de host que debe tener y, por lo tanto, la complejidad de la administración de certificados, es no incluir nombres de host de servidor individuales en los nombres alternativos de firmante del certificado.

Los nombres de host que debe incluir en los certificados de Exchange son los nombres de host usados por las aplicaciones cliente para conectarse a Exchange. A continuación se muestra una lista de nombres de host típicos que serían necesarios para una empresa denominada Contoso:

  • Mail.contoso.com: este nombre de host cubre la mayoría de las conexiones a Exchange, como Microsoft Outlook, Outlook Web App, Outlook Anywhere, la Libreta de direcciones sin conexión, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Panel de control y ActiveSync.

  • Autodiscover.contoso.com: los clientes que admiten la detección automática usan este nombre de host, incluido Microsoft Office Outlook 2007 y versiones posteriores, Exchange ActiveSync y clientes de Exchange Web Services.

  • Legacy.contoso.com: este nombre de host es necesario en un escenario de coexistencia con Exchange 2007 y Exchange 2013. Si va a tener clientes con buzones en Exchange 2007 y Exchange 2013, la configuración de un nombre de host heredado impide que los usuarios tengan que aprender una segunda dirección URL durante el proceso de actualización.

Descripción de los certificados comodín

Un certificado comodín está diseñado para admitir un dominio y varios subdominios. Por ejemplo, la configuración de un certificado comodín para *.contoso.com da como resultado un certificado que funcionará para mail.contoso.com, web.contoso.com y autodiscover.contoso.com.