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.

Nota:

Los certificados autofirmados creados por Exchange expiran en un año. Los componentes internos que dependen de los certificados autofirmados predeterminados siguen funcionando incluso cuando estos certificados han expirado. Con todo, una vez que ha expirado un certificado autofirmado, se registran eventos en el Visor de eventos. Es aconsejable renovar los certificados autofirmados antes de que expiren.

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.
  

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)
  

Importante:
Los clientes en los que se ejecuta Windows Mobile 5.0 no admiten un canal cifrado con servidores en los que se usan nombres con caracteres comodín en el certificado.

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

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

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

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.

Nota:
El campo SAN no se expone a través de Exchange directamente. Sólo se puede ver en el Administrador de certificados de MMC o a través del Administrador de Internet Information Services (IIS). Los certificados enlazados a un sitio web, como los usados por IIS para Outlook Web Access, Exchange ActiveSync o la detección automática, también se pueden ver en el Administrador de IIS.

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.

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

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.

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

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.

Importante:

Es probable que no pueda instalar certificados en todos los equipos y dispositivos que los usuarios van a usar para tener acceso a Exchange. Por ejemplo, puede haber usuarios que traten de tener acceso a Outlook Web Access desde un equipo público o desde el de un amigo. En ese caso, los usuarios reciben una advertencia pero no se les impide que tengan acceso al correo. Este comportamiento, en la práctica, habitúa a los usuarios a no hacer caso de las advertencias sobre certificados, por lo que no es aconsejable. Por el contrario, se recomienda el uso de certificados emitidos por CA externas de confianza.

 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.

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.

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

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.

Nota:
Los certificados devueltos por los proveedores admitirán distintas extensiones para el archivo de solicitud de certificado, como .der o .cer. Estas extensiones representan el método de codificación usado en el archivo de certificado. De forma predeterminada, el cmdlet New-ExchangeCertificate creará un archivo codificado en base 64 (.cer). Use el parámetro BinaryEncoded para crear un archivo .der.

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.

Nota:
El parámetro PrivateKeyExportable es opcional. Sólo se debe especificar al generar solicitudes de certificado para CA de confianza. Si se establece el parámetro PrivateKeyExportable en $True, el certificado y sus claves asociadas se pueden mover y archivar. Esto no es necesario con los certificados autofirmados.

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.

Nota:

El cmdlet Get-ExchangeCertificate devuelve certificados y también certificados cuya solicitud sigue pendiente. Para distinguir ambos tipos de certificado, las solicitudes contienen el atributo CertificateRequest que muestra la salida almacenada en el archivo de solicitud de certificado. Esta información puede resultar útil si, por error, se elimina el archivo de solicitud de certificado o la solicitud se genera sin el parámetro. Los datos de CertificateRequest están codificados en Base64 y se pueden copiar en un archivo y enviar a la CA para solicitar 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.

Importante:
El certificado se debe importar en el mismo equipo en que se generó su solicitud. No use el Administrador de certificados de MMC para importar certificados de Exchange.

 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 *

Nota:
Si se está ejecutando Exchange 2007 SP1 o versiones posteriores, no incluya el asterisco (*) en el argumento del comando.

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.
  

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 *

Nota:
Si se está ejecutando Exchange 2007 SP1 o versiones posteriores, no incluya el asterisco (*) en el argumento del comando.

 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

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.

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.

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.

Nota:

En la versión RTM de Exchange 2007 hay dos excepciones importantes en los procesos de selección de certificados para POP3 e IMAP4. Los certificados emitidos por una CA de confianza no tienen prioridad sobre los autofirmados. En lugar de ello, Exchange 2007 selecciona el certificado más reciente. Además, en la versión RTM de Exchange 2007, POP3 e IMAP4 no admiten dominios con caracteres comodín en los certificados. Esto significa que si el atributo X509CertificateName se establece en mail.fourthcoffee.com para la configuración de POP3 o IMAP4, Exchange 2007 no admitirá un certificado que sólo tenga *.fourthcoffee.com como dominio del certificado.

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