Uso de certificados en Exchange 2007 Server

 

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2008-05-19

Microsoft Exchange Server 2007 usa certificados para contribuir a proteger muchas de las vías de comunicación del correo electrónico. Este tema pretende ser una introducción completa al uso de certificados en Exchange 2007. En él se explican los siguientes aspectos:

• Cómo se usan los certificados en Exchange 2007.

• Cómo determinar si se debe adquirir un certificado emitido por una entidad de certificación (CA) externa pública y cuándo es suficiente el certificado autofirmado predeterminado.

• Cómo usan los componentes de Exchange 2007 los atributos de los certificados y cómo se relacionan las propiedades de los certificados con los campos de la extensión de certificado X.509.

• Certificados de confianza y su validación.

• Cómo crear, importar y habilitar certificados de Exchange 2007.

• Cómo seleccionan los componentes de Exchange certificados del almacén del equipo Personal.

En cada sección de este tema se incluyen referencias y vínculos a la documentación de Exchange 2007 relativa a los certificados.

Agradecimientos   La mayor parte del contenido de este tema es una adaptación de las notas y la documentación interna de Microsoft, recopilada y proporcionada por Stuart Presley, ingeniero de soporte técnico.

Tabla de contenido

• Componentes de Exchange 2007 que usan certificados para cifrar o autenticar sesiones

• Cómo determinar cuándo usar certificados emitidos por CA públicas y cuándo usar certificados autofirmados

• Descripción de los atributos de los certificados y el uso que Exchange 2007 hace de ellos

• Certificados de confianza y su validación

• Creación, importación y habilitación de certificados

• Selección de certificados

• Para obtener más información

Componentes de Exchange 2007 que usan certificados para cifrar o autenticar sesiones

Exchange 2007 usa certificados X.509 para negociar los canales de de transporte de comunicación protegidos de Seguridad de la capa de transporte (TLS) y Capa de sockets seguros (SSL) para los protocolos, como HTTPS, SMTP, POP e IMAP.

TLS es el protocolo estándar del Grupo de trabajo de ingeniería de Internet (IETF) que contribuye a proporcionar privacidad y seguridad a las comunicaciones entre dos aplicaciones que se comunican a través de una red. TLS codifica las comunicaciones y permite a los clientes autenticar servidores y, opcionalmente, a los servidores autenticar a clientes. TLS es una versión más segura del protocolo SSL, en el que está basado. SSL fue creado con anterioridad por Netscape. La funcionalidad de los dos protocolos es la misma. Prácticamente todas las implementaciones admiten los dos protocolos por razones de compatibilidad con clientes anteriores que sólo admiten SSL.

La comunicación protegida mediante TLS se puede usar únicamente por razones de confidencialidad (cifrado), o por razones de confidencialidad y autenticación. Los certificados X.509 pueden ser autofirmados, denominados también autoemitidos, o bien emitidos por una CA de X.509. Una CA de X.509 es una entidad de certificación externa pública que emite certificados o una infraestructura de clave pública (PKI) implementada en una organización. A menos que se indique lo contrario, en este tema se hace referencia a las dos soluciones como entidades de certificación (CA). Las CA externas se denominan CA públicas.

Los siguientes componentes de Exchange 2007 usan certificados para cifrar o autenticar sesiones:

• SMTP   Los certificados se usan para el cifrado y autenticación para la seguridad de dominio entre organizaciones asociadas. Los certificados se usan para las conexiones de confianza directa entre servidores de transporte de concentradores y servidores de transporte perimetral. Se usan también entre servidores de transporte de concentradores para cifrar la sesión SMTP. En Exchange Server 2007, confianza directa es la funcionalidad de autenticación para la que la presencia del certificado en el servicio de directorio de Active Directory o el servicio de directorio de Active Directory Application Mode (ADAM) valida el certificado. Active Directory se considera un mecanismo de almacenamiento de confianza. Los certificados se usan también para las sesiones de TLS oportunista entre organizaciones. Para obtener más información, consulte Funcionalidad de la TLS y terminología relacionada en Exchange 2007.

• Sincronización de EdgeSync   Un certificado autofirmado creado por Exchange 2007 se usa para cifrar la sesión de comunicación LDAP entre la instancia de ADAM de los servidores de transporte perimetral y los servidores de Active Directory internos una vez que el servicio EdgeSync de Microsoft Exchange ha replicado los datos de Active Directory en la instancia de ADAM del servidor de transporte perimetral. Un certificado autofirmado es aquél que firma su propio creador. El servicio EdgeSync de Microsoft Exchange es el servicio de sincronización de datos que replica periódicamente los datos de configuración de Active Directory en un servidor de transporte perimetral suscrito. Para obtener más información, consulte Descripción del proceso de sincronización de EdgeSync.

• POP3 e IMAP4   Los certificados se usan para autenticar y cifrar la sesión entre los clientes del Protocolo de oficina de correos versión 3 (POP3) y el Protocolo de acceso a mensajes de Internet versión 4rev1 (IMAP4) y los servidores de Exchange. Para obtener más información, consulte Administración de la seguridad de POP3 e IMAP4.

• Mensajería unificada   Los certificados se usan para cifrar la sesión entre los servidores de transporte de concentradores y la puerta de enlace IP de Mensajería unificada (UM) y Microsoft Office Communications Server 2007. Para obtener más información, consulte Descripción de la seguridad de la mensajería unificada VoIP.

• Detección automática   Los certificados se usan para cifrar la ruta de acceso HTTP entre el cliente y el servidor de acceso de cliente. Para obtener más información, consulte las White Paper: Exchange 2007 Autodiscover Service (página en inglés).

• Aplicaciones de acceso de cliente   Los certificados se usan para cifrar la ruta de acceso entre el servidor de acceso de cliente y diversos clientes HTTP, por ejemplo, Outlook en cualquier lugar, Microsoft Outlook Web Access y dispositivos compatibles con Microsoft Exchange ActiveSync. Para obtener más información, consulte Administración de la seguridad del acceso de cliente.

Para obtener información concreta sobre el cifrado y la autenticación en Exchange 2007 de cada una de las rutas de acceso a datos, consulte Referencia de seguridad de rutas de datos.

Volver al principio

Cómo determinar cuándo usar certificados emitidos por CA públicas y cuándo usar certificados autofirmados

El objetivo de esta sección consiste en ofrecer una descripción breve del uso de certificados que hace Exchange 2007. Cuando haya leído esta sección, sabrá qué tipo de certificados debe adquirir de una CA pública, en función de los componentes de Exchange que haya habilitado y los clientes que desee admitir. Se describe también el contexto general del contenido de carácter más técnico que viene a continuación.

Es importante ser consciente de que, dado que la finalidad de esta sección es la de permitirle determinar con rapidez qué certificados necesita adquirir de CA públicas, no se trata de una sección extensa. En aras de la brevedad, se usan generalizaciones sobre los certificados y las tecnologías relacionadas para ilustrar su uso en Exchange 2007. Si hay algún concepto de esta sección que no comprende, no olvide leer el resto del tema y la documentación de referencia.

Normalmente, cualquier componente de Exchange 2007 que use la autenticación Kerberos, NTLM o de confianza directa, puede usar un certificado autofirmado para el cifrado. En este tema, tales componentes se denominan componentes internos de Exchange 2007. Interno hace referencia al hecho de que las rutas de acceso a datos se encuentran entre servidores de Exchange 2007 y dentro de la red corporativa definida por Active Directory.

Recomendamos que implemente un certificado emitido por una CA pública siempre que los usuarios tengan acceso a componentes de Exchange que requieran autenticación y cifrado desde el exterior del firewall corporativo. Por ejemplo, todos los clientes que admite la función del servidor Acceso de cliente, como Exchange ActiveSync, POP3, IMAP4 y Outlook en cualquier lugar, se deben proteger mediante un certificado emitido por una CA pública. En este tema, tales componentes se denominan componentes externos de Exchange 2007. Externo hace referencia al hecho de que las rutas de acceso a datos entre los clientes y los servidores de Exchange 2007 atraviesan el firewall corporativo y se adentran en Internet.

Los componentes internos usan certificados autofirmados

Como ya se ha explicado, muchos de los componentes de Exchange 2007 usan certificados. Por lo general, todas las rutas de acceso a datos internas de Exchange protegidas por certificados no requieren un certificado emitido por una CA pública.

Todo el tráfico interno de SMTP y MU está protegido mediante certificados autofirmados que se instalan al ejecutar el programa de instalación de Exchange 2007 Server. Si bien debe renovar estos certificados anualmente mediante el cmdlet New-ExchangeCertificate, no necesita tener un certificado emitido por una CA pública para ejecutar los componentes de mensajería internos predeterminados de Exchange.

Exchange 2007 incluye un conjunto de cmdlets para crear, solicitar y administrar certificados TLS. Para obtener más información, consulte Cmdlets de certificados más adelante en este tema. De forma predeterminada, estos certificados son autofirmados. Como ya se ha mencionado en este tema, un certificado autofirmado es aquél firmado por su propio creador. En Exchange 2007, el equipo en que se está ejecutando Microsoft Exchange crea el certificado autofirmado mediante la API de certificado de Windows (CAPI)  subyacente. Dado que los certificados son autofirmados, los certificados resultantes son menos confiables que los generados por una CA. Por lo tanto, se recomienda usar certificados autofirmados sólo en las siguientes situaciones de uso interno:

• Sesiones SMTP entre servidores de transporte de concentradores: el certificado se usa sólo para cifrar la sesión SMTP. El protocolo Kerberos se encarga de la autenticación.

• Sesiones SMTP entre servidores de transporte de concentradores y un servidor de transporte perimetral: se usa un certificado para cifrar la sesión STMP y para la autenticación de confianza directa.

• Sincronización de EdgeSync entre servidores de transporte perimetral y Active Directory: se usa un certificado para cifrar la sesión de comunicación LDAP entre la instancia de ADAM de los servidores de transporte perimetral y los servidores de Active Directory internos una vez que el servicio EdgeSync de Microsoft Exchange ha replicado los datos de Active Directory en la instancia de ADAM del servidor de transporte perimetral.

• Comunicación de mensajería unificada: se usa un certificado para cifrar el tráfico del Protocolo de inicio de sesión (SIP) y el Protocolo de transporte en tiempo real (RTP) entre servidores de MU y puertas de enlace IP de MU, centrales de conmutación IP (PBX) y equipos en los que se ejecuta Office Communications Server 2007. El certificado se usa también para cifrar el tráfico SMTP cuando se envían mensajes de correo de voz y de fax desde servidores de MU a servidores de transporte de concentradores.

• Un servidor de acceso de cliente al que sólo tienen acceso los clientes internos.

El acceso de clientes externos a Exchange requiere certificados emitidos por una CA pública

Los componentes internos de Exchange pueden usar certificados autofirmados porque éstos no se usan para la autenticación. Kerberos o NTLM proporcionan la autenticación para la mayoría de los componentes de Exchange. En la comunicación entre un servidor de transporte perimetral y un servidor de transporte de concentradores se usa la autenticación de confianza directa. Esta autenticación se obtiene de un certificado y del hecho de que la clave pública del servidor de transporte perimetral se almacena en Active Directory, que es un almacén de confianza. En los demás casos, se usan certificados autofirmados que proporcionan una clave efímera para cifrar las rutas de acceso a datos entre los componentes de Exchange.

Sin embargo, para el acceso de clientes externos desde Internet a la red en que está hospedado Exchange, se necesita la validación de confianza de certificados convencional. Es aconsejable usar un certificado emitido por una CA pública para realizar la validación de confianza. De hecho, si se necesita obtener la autenticación de certificados, se recomienda encarecidamente NO usar un certificado autofirmado. Se recomienda usar un certificado de una CA pública para:

• Acceso de clientes POP3 e IMAP4 a Exchange

• Outlook Web Access

• Outlook en cualquier lugar

• Exchange ActiveSync

• Detección automática

• Seguridad de dominio

La práctica más aconsejable en todos estos casos es la de usar una CA que sea de confianza para todos los clientes de manera predeterminada.

Use el cmdlet New-ExchangeCertificate para generar una solicitud de certificado según las especificaciones de la CA pública externa que vaya a emitir el certificado.

Para obtener más información al respecto, consulte los siguientes temas:

• New-ExchangeCertificate

• Creación de un certificado o de una solicitud de certificado para TLS

• Lo que hemos aprendido de Exchange 2007: generar un certificado con una CA externa

  Nota

  El contenido de las Wikis y los blogs, así como sus direcciones URL, pueden cambiar sin previo aviso.

El resto de este apartado proporciona información sobre cómo determinar el tipo de certificado público que se debe adquirir y si se debe adquirir más de uno para contribuir a proteger los clientes que la organización usa para tener acceso a Exchange 2007.

Determinación del tipo y el número de certificados emitidos por CA públicas para la implementación

La elección del certificado adecuado emitido por una CA pública para la organización depende de los siguientes factores:

• La compatibilidad de los clientes con nombres comodín en los certificados   Hágase esta pregunta: ¿Qué clientes voy a admitir? Como ya se ha dicho, "clientes" en este contexto hace referencia a los que obtendrán acceso a Exchange desde Internet.

• El espacio de nombres de la organización   ¿Cómo está configurado el espacio de nombres de Internet Information Services (IIS) que se usa con Internet?

• El origen del certificado   ¿Dónde va a obtener el certificado? ¿Admite la CA pública que seleccione el uso de caracteres comodín en los campos de sujeto o nombre alternativo del sujeto (SAN)? Si no es así, ¿admite el uso de los SAN?

En las siguientes secciones se describen detalladamente estos factores.

Compatibilidad del cliente con nombres con caracteres comodín en los certificados

Los nombres comodín se pueden usar en las extensiones de sujeto o SAN de los certificados X.509. Para obtener más información acerca de los nombres con caracteres comodín, consulte "CertificateDomains" en Descripción de los atributos de los certificados y el uso que Exchange 2007 hace de ellos, más adelante en este tema.

Una vez que haya determinado qué clientes admitirá la organización, resulta útil determinar si los clientes admiten certificados en que se usan nombres con caracteres comodín en el certificado de usuarios al que se va a conectar el cliente.

Si el cliente admite el uso de nombres con caracteres comodín en el certificado, la planeación global de certificados en la organización se simplifica mucho. Si todos los clientes admiten nombres con caracteres comodín en los certificados y la organización usa un único nombre de dominio, no necesita tener en cuenta la planeación del espacio de nombres en la estrategia de implementación de certificados. En lugar de ello, puede crear un único certificado que admita el espacio de nombres con un carácter comodín. Por ejemplo, si los clientes en los que se ejecuta Outlook Web Access usan mail.contoso.com/owa para tener acceso al correo, y los clientes POP3 usan pop.contoso.com, un único certificado con el sujeto con caracteres comodín *.contoso.com los admitirá a todos.

Los siguientes clientes de Microsoft admiten nombres con caracteres comodín en los certificados:

• Outlook

  Nota

  Cuando se implementan certificados comodín en servidores de Exchange que ejecutan la función Acceso de cliente, es necesario configurar las opciones de detección automática para permitir que los clientes de Outlook 2007 se conecten correctamente. Para obtener más información acerca de este problema y solucionarlo, consulte El certificado comodín causa problemas de conectividad de cliente en Outlook en cualquier lugar.

• Internet Explorer (Outlook Web Access)

• Servidor de transporte perimetral de Exchange (seguridad de dominio)

Si un cliente admitido por la organización no admite nombres con caracteres comodín en el certificado del servidor, y tiene que admitir varios espacios de nombres de cliente, debe:

1. Adquirir un certificado con varios nombres, como mail.contoso.com, pop.contoso.com y mobile.contoso.com en la extensión SAN; o bien

2. Adquirir un certificado para cada entidad del espacio de nombres a la que se vaya a conectar el cliente.

Planeación del espacio de nombres de la organización

Todos los clientes requieren una dirección URL o un nombre de dominio completo (FQDN) al que conectarse. Cada ruta de acceso a la que se conecten los clientes debe estar asociada a un certificado válido que contenga el nombre de host, el nombre del NetBIOS, el FQDN o el nombre común del host al que se va a conectar el cliente. La determinación de la lista de nombres que se van a incluir en el certificado es el proceso de planeación del espacio de nombres.

Por lo general, la planeación del espacio de nombres en grandes organizaciones que admiten muchos clientes y abarcan varias regiones con varios servidores es más compleja que la de organizaciones de pequeño tamaño.

Es necesario conocer y entender la planeación del espacio de nombres de certificados, de forma que se sepa qué nombres de host incluir en la extensión SAN del certificado que se use para contribuir a proteger las conexiones de entrada a Exchange 2007.

Para obtener más información, consulte Descripción de la planeación del espacio de nombres para Exchange Server 2007.

Dónde obtener el certificado

Como ya se ha mencionado, para el acceso de clientes externos es recomendable adquirir un certificado de una CA externa pública.

Al evaluar las entidades de certificación, tenga en cuenta los siguientes criterios:

• ¿Admite la CA nombres con caracteres comodín en el certificado? Si los clientes que usa admiten nombres con caracteres comodín en el certificado, la compra de un certificado en una CA que también los admite es el método más sencillo de implementar clientes protegidos.

• ¿Admite la CA la extensión SAN? Es posible que sea útil usar un certificado que admita varios nombres en la extensión SAN si de dan las condiciones siguientes:

  • Es necesario admitir clientes que no admiten nombres con caracteres comodín en el certificado.

  • Se dispone de más de una ruta de acceso de host a las que se deben conectar los clientes.

  Microsoft está asociado a las CA públicas para proporcionar un certificado de comunicaciones unificado. Para obtener la lista actualizada de las CA que ofrecen certificados de comunicaciones unificados, consulte el artículo 929395 de Microsoft Knowledge Base Empresas colaboradoras de certificados de comunicaciones unificadas para Exchange 2007 y para Communications Server 2007.

• ¿Ofrece la CA un alto nivel de comprobación de la autenticidad? Hay algunas CA que son muy económicas. Otras tienen un costo de cientos de dólares al año por cada certificado. Puesto que va a depender de la integridad de este certificado para autenticar el tráfico entrante en su organización, recomendamos que no seleccione una CA únicamente en función de su costo. Evalúe y compare con atención los servicios proporcionados por cada CA, así como su prestigio, antes de decidirse por una de ellas.

Volver al principio

Descripción de los atributos de los certificados y el uso que Exchange 2007 hace de ellos

Conocer los distintos atributos de los certificados resulta muy útil para entender cómo los usa Exchange. A su vez, esto le ayudará a planear las necesidades de certificados de la organización de Exchange, así como a solucionar problemas.

Los certificados X.509 tienen dos tipos de atributos.

• Los campos de certificado son atributos que están dentro de los datos firmados del certificado X.509 propiamente dicho. La integridad de estos campos está protegida por la firma, y sus valores no se pueden modificar sin volver a firmar o emitir el certificado.

• Las propiedades de certificado son atributos que son metadatos del certificado o la clave privada. Algunas propiedades son intrínsecas del certificado o clave privada, como la huella digital de los certificados. Sin embargo, muchas propiedades se pueden modificar sin que haya que volver a firmar el certificado.

  Por ejemplo, el cmdlet Enable-ExchangeCertificate permite agregar servicios a las propiedades de los certificados después de que se han creado. Los certificados se pueden habilitar para su uso por parte de IIS, por ejemplo Outlook Web Access o Exchange ActiveSync, por parte de SMTP, como confianza directa o seguridad de dominio, IMAP, POP y mensajería unificada. La habilitación de un certificado para un servicio concreto actualiza las propiedades del certificado. Para obtener más información, consulte Enable-ExchangeCertificate.

Los atributos se pueden ver mediante la ejecución del cmdlet Get-ExchangeCertificate con el argumento |FL en un certificado determinado. Si está usando la versión RTM de Exchange 2007, debe ejecutar el cmdlet con el argumento |FL* para que se muestren todos los datos de los atributos.

Algunos de los campos y propiedades especificados en la salida del cmdlet Get-ExchangeCertificate se asignan a campos de la extensión X.509 que se pueden ver con el Administrador de certificados de Microsoft Management Console (MMC). Para obtener más información acerca del Administrador de certificados, consulte Cómo agregar el Administrador de certificados a la Microsoft Management Console. Para obtener más información acerca del cmdlet Get-ExchangeCertificate, consulte Get-ExchangeCertificate.

Campos de certificado

Como ya se ha mencionado, los campos de certificado son atributos que están dentro de los datos firmados del certificado X.509 propiamente dicho. En esta sección se describen los campos de certificado usados por los servicios de Microsoft Exchange y que se muestran en la salida del cmdlet Get-ExchangeCertificate.

Algunos de estos certificados son también parámetros que se pueden configurar al crear un certificado o una solicitud de certificado con el cmdlet New-ExchangeCertificate. Para obtener más información acerca del cmdlet New-ExchangeCertificate, consulte New-ExchangeCertificate.

Cada campo de certificado de esta sección se enumera en función de la salida del cmdlet Get-ExchangeCertificate. Cada nombre de campo de certificado de Exchange de esta sección se asigna a un nombre de extensión del certificado X.509.

Issuer

En este campo se muestra el nombre común que identifica al emisor del certificado. Los certificados autofirmados creados por Exchange durante la configuración o mediante el cmdlet New-ExchangeCertificate muestran cn=nombre de host, donde nombre de host es el nombre del servidor local.

Los certificados emitidos por las CA suelen mostrar el nombre común completo de la CA en el campo del emisor.

El nombre de extensión del certificado X.509 es también Issuer.

El campo Issuer no cuentan con un parámetro equivalente que se pueda establecer en el cmdlet New-ExchangeCertificate. El campo Issuer es especificado por la entidad que emite el certificado.

Subject

Este campo identifica el sujeto del certificado. Subject es una cadena de X.500 que suele representar un nombre único usado para tener acceso al servicio que utiliza el certificado. Cuando el cmdlet New-ExchangeCertificate crea un certificado, si el sujeto no se proporciona explícitamente, Subject será el primer valor de la lista del parámetro DomainName cuando se ejecute el cmdlet New-ExchangeCertificate. Pueden aparecer los siguientes campos de X.500:

• C = País

• ST = Estado o provincia

• L = Ubicación

• O = Organización

• OU = Unidad organizativa

• CN = Nombre común

Algunos de estos campos son necesarios al generar solicitudes de certificado para CA externas. Para obtener información pormenorizada sobre el campo Subject, consulte Creación de un certificado o de una solicitud de certificado para TLS.

Si se está ejecutando Microsoft Internet Security and Acceleration (ISA) Server 2006 delante de Exchange para el protocolo de puente, no olvide leer la información sobre nombres de sujeto y el comportamiento de ISA Server en el blog Los certificados con varias entradas SAN pueden interrumpir la publicación en Internet de ISA Server (página en inglés).

Cuando Exchange genera un certificado autofirmado sin ningún argumento del usuario, crea un certificado con el nombre de sujeto de CN=nombre de host.

El nombre de extensión del certificado X.509 es también Subject.

El campo Subject se establece especificando el parámetro SubjectName en el cmdlet New-ExchangeCertificate.

CertificateDomains

El campo CertificateDomains identifica todos los nombres de dominio DNS asociados a un certificado. Los nombres de dominio DNS pueden estar en el atributo de nombre común (cn=) del sujeto o en la extensión SAN de un certificado. La salida del cmdlet Get-ExchangeCertificate muestra la adición del dominio del campo Subject y los dominios encontrados en la extensión SAN.

Los valores del campo CertificateDomains pueden incluir el nombre de host o el FQDN usados para tener acceso al servidor. Para usar un certificado, el FQDN que utiliza un cliente para conectarse al servidor debe aparecer en el campo CertificateDomains del certificado.

Por ejemplo, si un cliente se va a conectar a un servidor con POP3 con mail.fourthcofee.com como nombre de servidor, el certificado asociado a la configuración de POP3 puede contener mail.fourthcofee.com en su campo CertificateDomains.

También puede haber certificados con nombres con caracteres comodín, como *.fourthcofee.com, que es un dominio aceptable. Sin embargo, debe saber que algunos clientes heredados y dispositivos móviles no admiten nombres con caracteres comodín en los certificados y, por lo tanto, podrían no aceptar el uso de dominios con caracteres comodín.

Para obtener información pormenorizada sobre el uso de las extensiones SAN y los nombres con caracteres comodín, consulte Creación de un certificado o de una solicitud de certificado para TLS. Consulte también el blog del equipo de Exchange, Exchange 2007 lessons learned - generating a certificate with a 3rd party CA (página en inglés), donde encontrará instrucciones sobre cómo crear una solicitud de certificado con varias SAN.

El nombre de extensión del certificado X.509 es Subject Alternative Name pero, como ya se ha mencionado, la salida del cmdlet Get-ExchangeCertificate agrega también el valor de la extensión de certificado Subject a la lista de nombres del campo CertificateDomains.

El campo CertificateDomains se establece especificando los parámetros DomainName y Subject del cmdlet New-ExchangeCertificate.

NotBefore y NotAfter

Los valores de los campos NotBefore y NotAfter representan un intervalo de fechas en que se puede usar el certificado, es decir, es válido. Si la fecha actual es posterior a la fecha de NotAfter, se considera que el certificado ha expirado. Microsoft Exchange puede usar certificados expirados, pero los clientes mostrarán advertencias y el servidor registrará los eventos correspondientes en el registro de eventos.

El nombre de extensión del certificado X.509 que se asigna al valor NotBefore es Valid from. El nombre de extensión del certificado X.509 que se asigna al valor NotAfter es Valid to.

Los campos NotBefore y NotAfter no cuentan con un parámetro equivalente que se pueda establecer en el cmdlet New-ExchangeCertificate. La entidad que emite el certificado define estos campos. Los certificados autofirmados generados por el programa de instalación de Exchange o por el cmdlet New-ExchangeCertificate tienen una validez de un año.

CertificateRequest

Este valor sólo aparece en los certificados que todavía están en el estado de solicitud. Las solicitudes de certificados no son certificados X.509 válidos y, por lo tanto, Exchange no los usará.

El campo CertificateRequest se habilita especificando el modificador de parámetro GenerateRequest del cmdlet New-ExchangeCertificate.

Propiedades de certificado

Como ya se ha explicado, las propiedades de certificado son atributos que son metadatos del certificado o la clave privada. Ciertas propiedades son intrínsecas al certificado o clave privada, por ejemplo la huella digital de los certificados, pero muchas propiedades se pueden modificar sin que haya que volver a firmar el certificado.

Salvo la propiedad Thumbprint, ninguna propiedad de certificado de Exchange corresponde a una extensión del certificado X.509.

En esta sección se describen las propiedades de certificados.

IsSelfSigned

La propiedad IsSelfSigned indica si un certificado está autofirmado. Por lo general, un certificado autofirmado es un certificado raíz. Se trata de un certificado que no tiene otro certificado en la cadena de certificados. En Exchange, certificado autofirmado suele hacer referencia a los siguientes tipos de certificado:

• Un certificado que se genera al instalar Exchange en un servidor en el que no hay un certificado válido

• Un certificado resultante de la ejecución del cmdlet New-ExchangeCertificate.

Cuando están instaladas las funciones del servidor Transporte de concentradores, Transporte perimetral, Mensajería unificada o Acceso de cliente, el programa de instalación de Exchange genera un certificado autofirmado. Si hay un certificado válido en el almacén de certificados Personal del equipo host, se usará, y no se usará el certificado autofirmado generado por el programa de instalación de Exchange. Los valores válidos son True o False.

RootCAType

La propiedad RootCAType identifica el tipo de CA que emitió el certificado. Si el parámetro IsSelfSigned está establecido en True, el valor de la propiedad RootCAType debe ser None. De no ser así, el certificado podría hacer que se produjeran resultados inesperados en el proceso de selección de certificado. Otros valores posibles son:

• Registry   Una CA raíz de PKI privada interna que se haya instalado manualmente en el almacén de certificados.

• ThirdParty   Una CA raíz externa pública.

• GroupPolicy   Una CA raíz de PKI privada interna que se haya implementado con directiva de grupo.

• Enterprise   Una CA raíz de PKI privada interna que se haya implementado con Active Directory.

• Unknown   Exchange no puede determinar el tipo de certificado que se instala.

Saber cómo se ha instalado el certificado de CA raíz en un equipo puede ayudar a diagnosticar si las directivas de confianza son incoherentes. Estas incoherencias podrían hacer que los certificados se validen en algunos servidores pero no en otros.

Por ejemplo, un valor de Registry indica que alguien ha instalado manualmente el certificado en un servidor. Este valor puede crear incoherencias si el servidor no se ha instalado en otros servidores de la organización. Se recomienda distribuir los certificados en todos los equipos con la directiva de grupo o Active Directory.

Services

La propiedad Services identifica los servicios con los que se puede usar un certificado. Los valores válidos son SMTP, POP, IMAP, UM y IIS.

El valor del campo Services se establece especificando el parámetro Services del cmdlet Enable-ExchangeCertificate. Para obtener más información, consulte Enable-ExchangeCertificate.

Status

La propiedad Status indica si un certificado es válido. El campo Status resulta muy útil para solucionar problemas de los certificados. Si el valor Status de un certificado determinado no es Valid, el servidor de Exchange no lo usará para ningún servicio. Los valores de la propiedad Status son los siguientes:

• Unknown   Este valor suele indicar que no se puede comprobar el estado del certificado porque no está disponible la lista de revocación de certificados (CRL) o el servidor no se puede conectar con ella. Asegúrese de que el equipo se puede conectar a la entidad de revocación de certificados. Para obtener más información, consulte Cómo configurar el proxy para WinHTTP.

• Valid   El certificado funciona correctamente.

• Revoked   La CRL indica que este certificado se ha revocado. Es necesario generar otro.

• DateInvalid   Este valor indica que la hora del sistema no es correcta, el certificado ha expirado, o la hora del sistema que firmó el certificado no es correcta. Compruebe que se cumplan las siguientes condiciones:

  • El reloj del equipo local es preciso.

  • El certificado no ha expirado.

  • El reloj del sistema remitente es preciso.

  Si el certificado ha expirado, debe generar uno nuevo.

• Untrusted   Este valor indica que el certificado no es autofirmado. Sin embargo, está firmado por una CA que no es de confianza en el equipo local. Se debe agregar el certificado de la CA al almacén de entidades de certificación raíz de confianza del equipo. Para obtener más información acerca de cómo agregar certificados manualmente al almacén de certificados local, consulte el archivo de Ayuda del Administrador de certificados de MMC.

• Invalid   Otra emisión ha anulado este certificado, por ejemplo un certificado no válido, revocado o que no es de confianza en algún lugar de la ruta de acceso de los certificados.

Para obtener más información sobre la solución de problemas, consulte los siguientes temas:

• Cómo solucionar los errores de validación del certificado

• Cómo probar la configuración PKI y del proxy

• Cómo configurar el proxy para WinHTTP

HasPrivateKey

La propiedad HasPrivateKey indica si el certificado instalado tiene una clave privada. Esta propiedad es muy importante, porque el servicio de transporte de Microsoft Exchange, el servicio POP3 de Microsoft Exchange y el servicio IMAP4 de Microsoft Exchange no usarán un certificado que no tenga una clave privada.

Huella digital

La propiedad Thumbprint es una cadena única que identifica el certificado. Si hay un certificado instalado en varios servidores de Exchange, puede identificar cada uno de ellos por su huella digital. Un mismo certificado se instala en varios servidores de Exchange si hay más de un servidor de transporte perimetral que acepta correo electrónico con el mismo FQDN, por ejemplo mail.fourthcoffee.com. Es mucho más rentable instalar el mismo certificado en varios servidores que solicitar uno distinto para cada servidor. Con todo, el certificado debe tener una clave privada exportable.

La propiedad Thumbprint se usa para especificar un certificado para los siguientes cmdlets:

• Get-ExchangeCertificate

• Remove-ExchangeCertificate

• Export-ExchangeCertificate

• Enable-ExchangeCertificate

El nombre de extensión del certificado X.509 que se asigna al valor Thumbprint es también Thumbprint.

Volver al principio

Certificados de confianza y su validación

Para usar un certificado en la autenticación, dicho certificado debe estar validado y ser de confianza.

Para validar un certificado X.509 determinado, debe confiar en la CA de raíz que emitió el certificado. Una CA raíz es la de mayor confianza. Se encuentra en la parte superior de una CA. El CA de raíz tiene un certificado autofirmado. Al ejecutar una aplicación que dependa de un certificado de autenticación, cada certificado debe tener una cadena de certificados que termine en un certificado en el contenedor raíz de confianza del equipo local. El contendor raíz de confianza contiene certificados de entidades de certificación de raíz.

Un certificado está unido a una CA mediante otro certificado. Ese certificado también podría haber sido emitido por una CA y, por lo tanto, estaría unido a ella. Este encadenamiento de certificados se denomina también ruta de certificación. Todos los certificados de la ruta de certificación de un certificado deben ser válidos para que éste también lo sea. Además, el certificado superior de la cadena debe ser una CA raíz de confianza.

Hay dos tipos de CA raíz de confianza que se pueden usar para implementar aplicaciones que dependen de la autenticación de certificados: CA raíz externas públicas y CA raíz privadas.

Entidades de certificación raíz externas públicas

Windows, Windows Mobile y diversos sistemas operativos de otros fabricantes incluyen un conjunto de CA raíz externas públicas. Si confía en los certificados emitidos por estas CA raíz externas públicas, puede comprobar los certificados emitidos por ellas.

La confianza es automática si se dan las siguientes condiciones:

• La organización usa la instalación predeterminada de Windows.

• El software de cliente y los dispositivos usados en la organización también confían en las CA raíz externas públicas integradas.

En este caso, no se necesita configuración de confianza adicional.

Entidades de certificación raíz de confianza privadas

Una CA raíz de confianza privada es una CA raíz implementada mediante una PKI privada o interna. Por ejemplo, cuando en la organización se haya implementado una PKI interna con un certificado raíz propio, es necesario realizar una configuración adicional de la confianza.

Por lo general, no es recomendable usar certificados emitidos por una PKI privada para aplicaciones cliente que admiten conexiones con la organización desde el exterior.

Si se usan CA raíz privadas, se debe actualizar el almacén de certificados Raíz de confianza de Windows en todos los dispositivos, clientes y sistemas operativos de Windows en que sea necesaria la autenticación de certificados.

Es posible configurar la confianza de dos maneras: confianza de raíz directa e intercambio de certificaciones.

Confianza de raíz directa

Si desea confiar en un certificado emitido por una CA raíz privada, puede agregar manualmente dicho certificado raíz al almacén de certificados Raíz de confianza de un equipo en que se esté ejecutando Windows. En ciertos casos, también puede agregar el certificado raíz al almacén raíz de confianza de clientes móviles. Para obtener más información acerca de cómo agregar certificados manualmente al almacén de certificados local de un equipo en que se esté ejecutando Windows, consulte el archivo de Ayuda del Administrador de certificados de MMC. Para obtener más información acerca de cómo instalar certificados en dispositivos con Windows Mobile, consulte Cómo instalar certificados raíz en un dispositivo con Windows Mobile.

Intercambio de certificaciones

El intercambio de certificaciones ocurre cuando un CA firma un certificado generado por otra CA. El intercambio de certificaciones se usa para construir confianza entre un PKI y otro PKI. Si dispone de su propia PKI, en lugar de usar la confianza manual directa para una CA raíz de otra PKI privada, puede crear un intercambio de certificaciones para la otra CA bajo la suya propia. En este caso, la confianza se establece porque, en última instancia, el intercambio de certificaciones se encadena con la CA raíz de confianza.

Configurar el acceso a la lista de certificados revocados

Cuando un servicio concreto, como el servicio de transporte de Microsoft Exchange si se usa SMTP/TLS o IIS si se usa HTTPS, recupera un certificado, el servicio valida la cadena del certificado y el certificado. La validación del certificado es un proceso en el que se confirman muchos atributos del certificado. La aplicación del equipo local que solicita el certificado puede confirmar la mayoría de estos atributos. Por ejemplo, el uso que se quiere dar al certificado, la fecha de expiración del certificado y los atributos similares se pueden comprobar fuera del contexto de un PKI. Sin embargo, es necesario que la comprobación de que no se ha revocado el certificado se valide con la CA que emitió el certificado. Por lo tanto, la mayoría de CA elaboran una lista de certificados revocados (CRL) disponible al público para validar el estado de revocación.

Para que la autenticación con certificados se realice correctamente, las CRL de las CA que use deben estar a disposición de los servicios que autentican el cliente. Si la comprobación de la revocación genera un error, se generará un error en el servicio de autenticación.

Los servidores que se encargan de la autenticación deben poder tener acceso a las CRL de las CA externas.

Todas las CA externas cuentan con CRL disponibles públicamente con la que se pueden poner en contacto los servidores de la organización. En algunos casos, las CRL para PKI internas privadas sólo están disponibles con el Protocolo ligero de acceso a directorios (LDAP). En la mayoría de los casos, con CA públicas, las CRL se publican mediante HTTP. Asegúrese de que los puertos de salida y proxies apropiados están configurados para permitir que los servidores y los clientes se pongan en contacto con la CRL. Puede determinar qué protocolo acepta un determinado punto de distribución CRL abriendo un certificado en MMC, en el campo Puntos de distribución CRL.

En algunos casos, podría tener que hacer que la CRL de la CA que emite los certificados esté disponible públicamente. Por ejemplo, si va a implementar la seguridad de dominio, debe ser consciente de que incluso cuando un servidor de transporte perimetral recupera un certificado de la propia organización, valida la cadena de certificados para validar el certificado. Por lo tanto, la CRL de su CA debe estar disponible para sus propios servidores de transporte perimetral. Además, todos los socios con los que intercambia correo electrónico seguro deben poder tener acceso a la CRL de la CA que emite los certificados.

Configuración de Proxy para WinHTTP

Los servidores de Exchange 2007 dependen de los servicios HTTP de Windows (WinHTTP) subyacentes para administrar todo el tráfico HTTP y HTTPS. Por ejemplo, los servidores de transporte de concentradores y los de transporte perimetral pueden usar HTTP para tener acceso a las actualizaciones del filtro contra correo electrónico no deseado estándar de Exchange 2007 y a Microsoft Forefront Security para el servicio de actualización contra el correo no deseado de Exchange Server. Todas las funciones del servidor de Exchange usan WinHTTP para habilitar la validación de las CRL.

Para obtener más información, consulte Cómo configurar el proxy para WinHTTP.

Probar la configuración de proxy y PKI

Para comprobar la configuración de la PKI y el proxy para un servidor de Exchange determinado, use Certutil.exe para comprobar la cadena de certificados del certificado de servidor. Certutil.exe es una herramienta de la línea de comandos que se instala como parte de los servicios de certificados en los sistemas operativos Windows Server. Para obtener más información, consulte Cómo probar la configuración PKI y del proxy.

Volver al principio

Creación, importación y habilitación de certificados

Existen varios métodos para obtener un certificado instalado y operativo en Exchange 2007. El método que se elija depende de las necesidades concretas. Exchange 2007 genera un conjunto de certificados autofirmados para habilitar la protección de la configuración predeterminada. Con el tiempo, el conjunto se debe renovar para contribuir a garantizar la seguridad del sistema. Exchange no genera automáticamente solicitudes de firma por parte de entidades de certificación. Tanto si desea crear un nuevo certificado autofirmado como si desea crear una solicitud de certificado para una entidad de certificación, puede usar el mismo cmdlet.

En esta sección se ofrece una descripción general de las operaciones que se pueden realizar en los certificados que usa Exchange 2007. Léala si no está familiarizado con los cmdlets de ExchangeCertificate. Más adelante en este documento se proporcionan ejemplos y procedimientos específicos de las aplicaciones, con POP3 como ejemplo. También en esta sección encontrará vínculos a documentación específica de las aplicaciones.

Cmdlets de certificados

En las versiones anteriores de Exchange Server, toda la administración de los certificados se realizaba mediante IIS y el Administrador de certificados de MMC. En Exchange 2007, la mayoría de las tareas de administración de certificados relativas a Exchange se llevan a cabo con uno de los siguientes cmdlets de ExchangeCertificate con el Shell de administración de Exchange:

• New-ExchangeCertificate   Este cmdlet genera certificados autofirmados y solicitudes de certificado para entidades de certificación.

• Import-ExchangeCertificate   Este cmdlet importa certificados que se han exportado previamente y archivos de certificado generados por las CA.

• Export-ExchangeCertificate   Este cmdlet exporta certificados para las copias de seguridad o para su uso en varios servidores.

• Enable-ExchangeCertificate   Este cmdlet habilita servicios específicos en un certificado.

• Get-ExchangeCertificate   Este cmdlet muestra los atributos de un certificado.

• Remove-ExchangeCertificate   Este cmdlet quita certificados de Exchange Server y el almacén de certificados local.

Para obtener más información acerca de cómo crear solicitudes de certificados para autoridades de certificación, consulte Creación de un certificado o de una solicitud de certificado para TLS.

En las siguientes secciones se ofrecen ejemplos breves que ilustran el uso de los cmdlets de ExchangeCertificate para realizar las tareas habituales de los certificados. Para obtener más información y ejemplos, consulte la Ayuda del cmdlet ExchangeCertificate en Cmdlets globales.

Generación de certificados autofirmados

Para generar un certificado autofirmado para que lo use el servicio SMTP para un servidor con el nombre de host Server1 y el dominio fourthcoffee.com, ejecute el siguiente comando:

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Clonación de certificados autofirmados

Si es necesario renovar un certificado autofirmado, puede clonarlo ejecutando el siguiente comando:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

El marcador de posición thumbprint es la huella digital del certificado que se va a renovar. Los servicios para el nuevo certificado también se pueden especificar en el comando, como se muestra a continuación:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

A continuación, este certificado se puede habilitar ejecutando el siguiente comando:

Enable-ExchangeCertificate <thumbprint>

Creación de solicitudes de certificados e instalación de certificados de confianza

La instalación de un certificado externo público es un proceso más complejo. Es necesario generar una solicitud de certificado, importar el certificado emitido y todos los certificados de CA necesarios y, a continuación, habilitar el certificado emitido para los usos que se desee.

En esta sección se proporciona un ejemplo de cómo habilitar el servicio POP3 para el uso de certificados. En el ejemplo, los clientes se conectan al servicio POP3 conectándose al FQDN popserver.fourthcoffee.com.

Solicitud de certificados

Puesto que el certificado resultante procede de una CA externa pública, primero debe generar una solicitud de certificado ejecutando el siguiente comando:

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

Si la solicitud de certificado se genera correctamente, se creará un archivo de solicitud de certificado (.cer o .der) en la raíz de la unidad del sistema y en el Shell de administración de Exchange se mostrará una huella digital para la solicitud.

En el comando anterior, el parámetro PrivateKeyExportable está establecido en $True, de manera que este certificado se pueda exportar junto con la clave privada para su uso en varios servidores de Exchange a los que podría tener acceso con el mismo FQDN. Por ejemplo, puede establecerse el equilibrio de carga entre varios servidores de acceso de cliente para que admitan conexiones POP3.

El comando anterior especifica también el parámetro Subjectname como un nombre X.500. La mayoría de las CA externas requieren que especifique un nombre X.500 válido como nombre de sujeto del certificado. Casi todas ellas requieren, como mínimo, que la organización mencionada en el campo organizationName (o=) sea la propietaria del dominio que aparece en el campo commonName (cn=) del servidor web.

Una vez que se ha completado la solicitud, el archivo de solicitud se puede enviar a un proveedor para obtener un certificado.

Importación de un certificado

Una vez que una CA devuelve un certificado, debe importarlo en el servidor de Exchange. Para importar correctamente un certificado para el que se generó una solicitud mediante el cmdlet New-ExchangeCertificate, ejecute el siguiente comando:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

Si el certificado se importa correctamente, el comando devolverá una huella digital de certificado que se puede usar para habilitar servicios concretos.

Habilitación de un certificado

La habilitación de certificados permite especificar los servicios que pueden usar un certificado determinado. El siguiente comando habilita el certificado emitido para el servicio POP3:

Enable-ExchangeCertificate <thumprint> -Services:"POP"

Un certificado se puede importar y habilitar a la vez, ejecutando el siguiente comando:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Validación de la instalación de certificados

Para comprobar que se han llevado a cabo todos los pasos necesarios y que los certificados están instalados y operativos, ejecute el siguiente comando:

Get- ExchangeCertificate <thumbprint> | fl *

La salida de este comando devuelve datos parecidos a los siguientes:

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Examine la salida de este comando para validar que se cumple lo siguiente:

• Los nombres de dominio que se esperan se enumeran en el campo CertificateDomains.

• La propiedad HasPrivateKey está establecida como True.

• La propiedad RootCAType está establecida correctamente. Para obtener más información sobre la propiedad RootCAType, consulte la sección anterior de este documento Propiedades de certificado.

• Los servicios necesarios están habilitados para el certificado.

• El estado está establecido como Valid.

Servicios de certificados

En un certificado se pueden habilitar servicios como POP, IMAP, IIS y SMTP. Los servicios no son campos del certificado propiamente dicho. Son propiedades de los metadatos de los certificados. En consecuencia, se pueden cambiar sin que el certificado pierda su validez.

Cuando se habilitan los servicios, se producen cambios en la configuración de otros componentes, como la metabase de IIS y el sistema de archivos, o en la configuración de IMAP4 y POP3. En esta sección se describen los cambios de configuración que tienen lugar cuando se habilita un servicio determinado mediante la ejecución del cmdlet Enable-ExchangeCertificate.

POP e IMAP

Cuando se agregan a un certificado POP e IMAP como servicios adicionales, el atributo x509CertificateName de los objetos POPSettings o IMAPSettings se actualiza para incluir el dominio en el sujeto del certificado.

Por ejemplo, para comprobar que el objeto POPSettings se ha actualizado, ejecute el siguiente comando:

Get-POPSettings | fl *

IIS

Cuando IIS está habilitado, el sitio web predeterminado de IIS se actualiza para que use este certificado concreto.

Se puede habilitar un certificado para IIS con el cmdlet Enable-ExchangeCertificate para el sitio web predeterminado de IIS únicamente. Si Outlook Web Access o la detección automática están hospedados en sitios web que no son el predeterminado de IIS, se debe usar el Administrador de IIS para asociar un certificado concreto a dichos sitios web.

SMTP

Cuando el servicio SMTP está habilitado en un certificado, se concede a la cuenta de servicio de red acceso de lectura al archivo de clave privada adecuado del directorio Documents and Settings\All Users\Datos de programa\Microsoft\Crypto\RSA\MachineKeys. Esta acción proporciona el permiso requerido para que el servicio de transporte de Microsoft Exchange tenga acceso a la clave privada y la use para descifrar mensajes protegidos mediante TLS.

Servicio de mensajería unificada de Microsoft Exchange

Cuando el servicio de mensajería unificada de Microsoft Exchange está habilitado en un certificado, la propiedad del certificado se actualiza para que incluya la mensajería unificada. El certificado se usa si se dan las siguientes condiciones:

• La función del servidor Mensajería unificada está instalada en el equipo.

• El certificado contiene el FQDN físico del equipo local en el campo CertificateDomains.

Volver al principio

Selección de certificados

La selección de certificados es un proceso que realizan los componentes de Exchange para determinar qué certificado se debe usar para una conexión entrante. SMTP STARTTLS, POP3 e IMAP4 llevan a cabo un proceso de selección similar para determinar qué certificado usar para una sesión concreta. Este proceso es bastante determinista. Sin embargo, puede ser confuso, sobre todo si hay más de un certificado instalado en el equipo.

En esta sección se describe el proceso de selección de certificados para SMTP STARTTLS, SMTP X-AnonymousTLS, POP3 e IMAP4. Para obtener más información acerca de la selección de certificados específica del transporte, consulte Selección de certificado TLS de SMTP.

SMTP STARTTLS

STARTTLS es el verbo de SMTP que inicia una sesión TLS segura. Exchange sólo anuncia STARTTLS si en el equipo en que se está ejecutando Exchange hay un certificado válido.

Para anunciar o usar STARTTLS, Exchange selecciona un certificado basado en el FQDN y un valor coincidente del campo CertificateDomains de un certificado. El FQDN se basa en la siguiente información:

• Outbound STARTTLS   El certificado se selecciona en función del valor de FQDN de un conector de envío.

• Inbound STARTTLS   El certificado se selecciona en función del valor de FQDN de un conector de recepción.

  Nota

  Para STARTTLS saliente y entrante, si no se especifica el FQDN del conector, se usa el FQDN físico del servidor de Exchange para realizar la comparación.

Una vez que se ha determinado el FQDN, Exchange busca todos los certificados válidos en el almacén de certificados Personal del equipo host. Un certificado es válido para su uso con TLS si cumple los siguientes requisitos:

• EL campo Uso mejorado de clave contiene el identificador de objeto Autenticación de servidor (denominado también OID) o tiene un valor nulo.

• En la extensión de certificado PKI aparece una clave RSA con un mínimo de 1024 bits.

• El certificado valida la cadena de certificados hasta una raíz de confianza o es autofirmado.

• El certificado y la cadena de certificados superan la comprobación de revocación.

• La clave privada existe y está disponible.

• La clave privada no está almacenada en un dispositivo extraíble.

• La clave privada no está protegida mediante contraseña.

Si se encuentra más de un certificado válido, Exchange selecciona uno en función de los siguientes criterios:

• El valor del campo NotBefore   Exchange selecciona el certificado válido más reciente.

• Certificados emitidos por una CA de confianza o certificados autofirmados   Exchange selecciona certificados emitidos por una CA de confianza antes que certificados autofirmados.

En la mayoría de los casos, Exchange selecciona un certificado emitido por una CA de confianza antes que otro autofirmado independientemente de su antigüedad. Si no se encuentra un certificado válido, no se anuncia STARTTLS.

SMTP X-AnonymousTLS

X-AnonymousTLS se usa para contribuir a proteger la comunicación entre dos servidores de transporte de concentradores y entre servidores de transporte de concentradores y servidores de transporte perimetral. En Exchange 2007 SP1, el proceso de selección de certificados se ha simplificado de forma que, si no se encuentra un certificado, se genera una clave de cifrado temporal para la sesión.

Exchange busca un certificado de transporte interno. Si no se encuentra ninguno, Exchange busca un certificado de CA válido.

En consecuencia, en las comunicaciones de concentrador a concentrador en que se use la autenticación Kerberos, la ausencia de un certificado de transporte interno no genera un error de la sesión SMTP. La sesión SMTP se cifra mediante una clave de cifrado temporal. En ese caso, se registra un evento y se debe crear un nuevo certificado de transporte interno mediante la ejecución del cmdlet New-ExchangeCertificate sin argumentos en el equipo que genera el evento.

En las comunicaciones de servidor de concentradores a servidor perimetral, en las que el servidor de transporte está suscrito a la organización, si no se encuentra un certificado de transporte interno válido, se produce un error en la sesión y dicho error se registra. En ese caso, se debe ejecutar el cmdlet New-ExchangeCertificate sin argumentos en el equipo que genera el evento y, a continuación, volver a ejecutar el servicio Microsoft Exchange EdgeSync.

POP3 e IMAP4

Al igual que en el proceso de selección de certificados para SMTP STARTTLS, en el proceso para POP3 e IMAP4, Exchange debe seleccionar un FQDN y encontrar un certificado en función de un valor coincidente en el campo CertificateDomains. El FQDN se elige en función del atributo X509CertificateName de la configuración de los servicios POP3 o IMAP4. El atributo X509CertificateName se puede ver ejecutando los cmdlet Get-POPSettings o Get-IMAPSettings. Para obtener más información, consulte Get-POPSettings y Get-IMAPSettings.

El proceso de selección para POP3 e IMAP4 en Exchange 2007 SP1 es el mismo que el de SMTP STARTTLS.

Mensajería unificada

Si el servicio de mensajería unificada de Microsoft Exchange se inicia en modo seguro, consultará al almacén de certificados Personal local para encontrar un certificado válido que se pueda usar con TLS con el fin de habilitar el cifrado. El servicio de mensajería unificada de Microsoft Exchange buscará primero un certificado válido que haya sido emitido por una PKI privada o una CA pública. Si no se encuentra un certificado adecuado, buscará un certificado autofirmado. Si no se encuentra ningún certificado de PKI, público o autofirmado, el servicio de mensajería unificada de Microsoft Exchange creará un certificado autofirmado para usarlo durante el inicio en modo seguro. Si el servidor de MU se inicia en modo no seguro, no se necesita ningún certificado.

Todos los detalles del certificado usado para el inicio en modo seguro se registran cada vez que se utiliza o se cambia dicho certificado. La información que se registra incluye, entre otros, los siguientes detalles:

• Nombre del emisor

• Número de serie

• Huella digital

La huella digital es el hash Algoritmo hash seguro (SHA1). Se puede usar para identificar de forma exclusiva el certificado utilizado. El certificado usado por el servicio de mensajería unificada de Microsoft Exchange se puede exportar desde el almacén de certificados local para el inicio en modo seguro. También se puede importar en las puertas de enlace IP de mensajería unificada y en las PBX IP de la red, en el almacén de certificados de confianza.

Una vez que se ha encontrado y usado un certificado adecuado, el servicio de mensajería unificada de Microsoft Exchange registra un evento un mes antes de la expiración del certificado. Si no se realiza ningún cambio en el certificado durante este tiempo, el servicio de mensajería unificada de Microsoft Exchange registrará un evento al día hasta que expire el certificado, y uno al día después de que haya expirado.

Cuando un servidor de mensajería unificada busca un certificado para que Mutual TLS establezca un canal cifrado, busca en el almacén de certificados raíz de confianza. Si hay varios certificados válidos y de diferentes emisores, el servidor de mensajería unificada elegirá el certificado válido al que le quede más tiempo para expirar. Si existen varios certificados, el servidor de mensajería unificada los elegirá en función del emisor y de la fecha de expiración. El servicio de mensajería unificada busca un certificado válido con el siguiente orden de prioridad:

1. Certificado de PKI o público con la fecha de expiración más lejana.

2. Certificado de PKI o comercial con la fecha de expiración más cercana.

3. Certificado autofirmado con la fecha de expiración más lejana.

4. Certificado autofirmado con la fecha de expiración más cercana.

Volver al principio

Para obtener más información

En este tema se ha hecho referencia a la siguiente documentación:

• Los certificados con varias entradas SAN pueden interrumpir la publicación en Internet de ISA Server(en inglés)

• Creación de un certificado o de una solicitud de certificado para TLS

• Creación de un certificado o de una solicitud de certificado para TLS

• Referencia de seguridad de rutas de datos

• Enable-ExchangeCertificate

• Exchange 2007 lessons learned - generating a certificate with a 3rd party CA(página en inglés)

• Export-ExchangeCertificate

• Get-ExchangeCertificate

• Get-IMAPSettings

• Get-POPSettings

• Cómo agregar el Administrador de certificados a la Microsoft Management Console

• Cómo configurar el proxy para WinHTTP

• Cómo probar la configuración PKI y del proxy

• Import-ExchangeCertificate

• Lecciones aprendidas: Generación de un certificado con un CA de terceros

• Administración de la seguridad del acceso de cliente

• Administración de la seguridad de POP3 e IMAP4

• New-ExchangeCertificate

• Remove-ExchangeCertificate

• Selección de certificado TLS de SMTP

• Funcionalidad de la TLS y terminología relacionada en Exchange 2007

• Descripción del proceso de sincronización de EdgeSync

• Descripción de la planeación del espacio de nombres para Exchange Server 2007

• Descripción de la seguridad de la mensajería unificada VoIP

• Empresas colaboradoras de certificados de comunicaciones unificadas para Exchange 2007 y para Communications Server 2007

• White Paper: Exchange 2007 Autodiscover Service(página en inglés)

Volver al principio