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

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

Última modificación del tema: 2011-11-04

En este tema se explica cómo crear certificados X.509 de Seguridad de nivel de transporte (TLS) o una solicitud de certificado, usando los cmdlets ExchangeCertificate en el Shell de administración de Exchange.

En términos criptográficos, el certificado y las claves privadas relacionadas que se generan mediante el cmdlet New-ExchangeCertificate son claves TLS. El cmdlet New-ExchangeCertificate permite especificar metadatos acerca del certificado, de forma que los diferentes servicios puedan usar el mismo certificado y la misma clave privada. Antes de crear certificados o solicitudes de certificado para servicios Exchange que usen TLS, es necesario que entienda los metadatos que usan los certificados para los servicios SSL y TLS. A estos metadatos se les llama "campos" en el certificado resultante.

Para ver los campos de los certificados del equipo en un determinado equipo, puede usar el cmdlet Get-ExchangeCertificate en el Shell de administración de Exchange. Como alternativa, puede usar el complemento Administrador de certificados en la Consola de administración de Microsoft (MMC). Para obtener más información acerca de cómo usar el complemento Administrador de certificados, consulte Cómo agregar el Administrador de certificados a la Microsoft Management Console.

Comprensión de los campos que usan los certificados para servicios TLS

Si usa el cmdlet New-ExchangeCertificate para generar una solicitud de certificado de terceros o de otra entidad de certificación (CA) de infraestructura de clave pública (PKI), asegúrese de que valida qué campos de certificado y qué formato de certificado son necesarios para la CA.

Esta sección explica los campos de certificado más importantes y proporciona algunas recomendaciones para generar certificados y solicitudes de certificados.

Nombre del sujeto

El Nombre del sujeto de un certificado es el campo que usan los servicios a través de DNS. El campo Nombre del sujeto vincula un certificado con un determinado servidor o nombre de dominio.

Un nombre del sujeto es un nombre X.500 distintivo que consta de uno o más nombres distintivos relativos, también conocidos como RDN. En la siguiente tabla se mencionan los nombres distintivos relativos para la identificación de organizaciones o entidades de servidor.

Los códigos de país o región son los códigos ISO 3166-1. Si desea más información, consulte los nombres de países y elementos de código en inglés (en inglés).

Componente de dominio y país o región son por convención mutuamente excluyentes. Es recomendable hacer referencia al nombre por país o región o hacer referencia al nombre por el nombre del Sistema de nombres de dominio (DNS). Asimismo, debe ser consciente de que el tamaño máximo del Componente de dominio (255 caracteres) es el total de todos los valores del componente de dominio.

Implementación de nombres distintivos relativos

Los nombres de sujetos están representados en el cmdlet New-ExchangeCertificate como un único parámetro que consta de una serie de nombres separados por comas. Cada nombre está identificado por la abreviatura para el nombre distintivo relativo. Por ejemplo, el siguiente nombre del sujeto representa País o región = US, Organización = Contoso Corp y Nombre común = mail1.contoso.com:

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

En el resto de ejemplos de nombres de sujetos que pueden representar al mismo servidor se incluyen los siguientes:

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

Si ha registrado un nombre DNS que usa para enviar correo SMTP, es recomendable usar la convención de componente de dominio y el nombre DNS para el nombre del certificado, como DC=contoso, DC=com, CN=correo1.contoso.com.

No obstante, cuando se genera una solicitud de certificado para un proveedor CA, tiene que entender las necesidades del campo Nombre del sujeto del CA y sus necesidades exclusivas de PKI. En algunos casos, puede que tenga que usar el código de País o región ("C"). Si es así, tiene que registrar el nombre distintivo relativo con una autoridad de registro X.500.

Nombres internacionales de sujetos

Para los nombres de sujetos que contienen caracteres que no son ASCII, puede escribir el parámetro SubjectName como nombre distintivo, encerrado entre comillas, tal y como sigue:

-SubjectName " C=ES,O=Diversión de Bicicleta,CN=correo1. DiversiondeBicicleta.com"

Nombres de sujetos y nombres de dominio

Por convención, un nombre común puede contener un nombre de dominio completo (FQDN). Aunque esta práctica está generalizada y recomendable, es necesario que sea consciente de los dos puntos siguientes.

En primer lugar, el tamaño máximo del campo de nombre común es de 64 caracteres. Es decir, menos caracteres que el tamaño máximo de un FQDN. Por tanto para un FQDN que conste de más de 64 caracteres, tiene que poner el nombre de dominio en el Nombre alternativo del sujeto. El parámetro DomainName es el parámetro que se asigna al Nombre de alternativo del sujeto en el certificado resultante.

En segundo lugar, el FQDN está restringido a un subconjunto del juego de caracteres ASCII. Por tanto, el nombre común (CN) admite Unicode. Por consiguiente, puede crear un certificado válido con un CN que parezca un nombre DNS pero que no sea un nombre DNS válido. Un programa de software que busque un FQDN en un CN de certificado, no devolverá el resultado correcto, si el CN contiene caracteres que no son ASCII. Por ejemplo, si crea un certificado con un Nombre del sujeto en el que CN=mail.microsoft.com, el nombre se ignorará como FQDN, porque contiene un carácter Unicode (el carácter ï con el diacrítico (x00ef)). A simple vista, el CN de Unicode se puede confundir fácilmente con un FQDN, debido a la ligera diferencia entre el carácter ï con el diacrítico (x00ef) y la ASCII i (x0069). La tarea de certificado de Exchange no requiere ni exige que el CN del sujeto sea un FQDN válido. Como opción predeterminada, esto significa que el cmdlet incluye el FQDN del servidor como CN predeterminado.

Nombres de dominio de certificado

Para TLS, los certificados tienen que contener nombres DNS, porque el TLS es un protocolo basado en DNS. Los clientes comprueban el nombre DNS del servidor al que se están conectando con el nombre DNS al que esperan estar conectándose. Esto es así en exploradores Web que se conectan con sitios Web a través de HTTPS y para servidores SMTP que transmiten correo electrónico a través de Internet o una intranet.

Un solo servidor puede admitir varios nombres DNS por los siguientes motivos:

• Un servidor SMTP admite varios dominios aceptados

• Un cliente puede tener acceso a un servidor de correo electrónico mediante el nombre del servidor, por el nombre de dominio, por un nombre local de FQDN o por un nombre de equilibrio de carga.

Cuando se establece una conexión TLS, si el cliente encuentra el nombre que está buscando, ignorará los otros nombres del certificado. Varios dominios y nombres de servidor se pueden agregar en el campo Nombre alternativo de sujeto de un certificado TLS. Puede crear un certificado que contenga varios nombres alternativos de sujeto, si usa el parámetro DomainName del cmdlet New-ExchangeCertificate. El parámetro DomainName tiene múltiples valores, por lo que puede aceptar varios nombres.

Los certificados X.509 pueden contener cero, uno o varios nombres DNS en la extensión del certificado Nombre alternativo de sujeto (SubjectAltName). Los nombres DNS de la extensión SubjectAltName coinciden exactamente con las restricciones de un nombre DNS. No pueden superar los 255 caracteres y tienen que constar de A-Z, a-z, 0-9 y guión (-).

Lógica de coincidencia de nombre para la función de seguridad de dominio

La lógica de coincidencia de nombre de certificado para la función de seguridad de dominio comprueba si un nombre de dominio del certificado recibido coincide con el nombre de dominio cuando envía correo electrónico a ese dominio. Como ejemplo, considere que el FQDN del dominio del destinatario es woodgrovebank.com. La lógica de coincidencia de nombre de certificado busca a través de los nombres DNS de los certificados y cuando un nombre DNS coincide, el certificado se comprueba como una coincidencia para el dominio especificado.

En este ejemplo, la lógica de coincidencia de nombre de certificado acepta un certificado con una coincidencia de dominio exacta como woodgrovebank.com. También permite el uso de nombres de dominio con caracteres comodín de forma que se acepte como coincidencia un certificado con nombre DNS *.woodgrovebank.com. Para obtener más información acerca de los nombres de dominio con caracteres comodín, consulte "Nombres de dominio con caracteres comodín", más adelante en este tema.

La lógica de coincidencia de nombre de certificado también realiza búsquedas de DNS de un nodo de profundidad. Por lo tanto, mail1.woodgrovebank.com también se acepta como coincidencia para woodgrovebank.com. Sin embargo, los nombres DNS de más de dos nodos de profundidad no se acepan. Por lo tanto, mail1.us.woodgrovebank.com, por ejemplo, no se aceptaría como una coincidencia de woodgrovebank.com.

Para obtener más información acerca de cómo Exchange selecciona certificados, consulte Selección de certificado TLS de SMTP.

Recomendaciones para nombres de dominio para SMTP de Internet

Cuando se crea un certificado o una solicitud de certificado para un servidor de transporte perimetral que ejecuta SMTP TLS sobre Internet, el conjunto de nombres de dominio que debería incluir en la solicitud es como sigue:

• El nombre completo de Internet del servidor   Puede ser diferente del FQDN interno que se usa entre los servidores de transporte perimetral y los servidores de transporte perimetral, y debería coincidir con el registro A que se publica en el servidor DNS (público) de Internet. Este nombre debería introducirse como un CN en el parámetro SubjectName del cmdlet New-ExchangeCertificate.

• Todos los nombres de dominio aceptados de la organización   Use el parámetro IncludeAcceptedDomain del cmdlet New-ExchangeCertificate para cumplimentar el Nombre alternativo de sujeto en el certificado resultante.

• El FQDN del conector no está cubierto por ninguno de los elementos anteriores   Use el parámetro DomainName del cmdlet New-ExchangeCertificate para cumplimentar el Nombre alternativo del sujeto en el certificado resultante.

Recomendaciones de nombres de dominio para un servidor de acceso de cliente

Cuando se crea un certificado o una solicitud de certificado para un servidor de acceso de cliente, el conjunto de nombres de dominio que debería incluir en la solicitud es el siguiente:

• Nombre local o de NetBIOS del servidor, por ejemplo: owa1

• Todos los nombres de dominio aceptados de la organización, por ejemplo: contoso.com

• Nombre de dominio completo del servidor, por ejemplo, owa1.contoso.com

• El nombre de dominio de detección automática del dominio, por ejemplo: Autodiscover.contoso.com

• La identidad de equilibrio de carga del servidor, si usa uno; por ejemplo: owa.contoso.com

Nombres de dominio con caracteres comodín

Los nombres de dominio con caracteres comodín son una clase especial de nombres de dominios que representan a varios subdominios. Los nombres de dominio con caracteres comodín pueden simplificar los certificados, porque un solo nombre de dominio con comodín representa a todos los subdominios del dominio principal. Se representan mediante un asterisco ( * ) en el nodo DNS. Por ejemplo: *.contoso.com representa a contoso.com y a todos los dominios de contoso.com. Cuando se usa un carácter comodín para crear un certificado o una solicitud de certificado para todos los dominios aceptados, se puede simplificar la solicitud significativamente.

Clonación de un certificado existente

Exchange 2007 crea un certificado autofirmado durante la instalación, que usa todos los nombres de servidor y dominio que conoce Exchange en el momento de la instalación. Estos certificados son válidos por 12 meses. En algunos casos, puede que tenga sentido clonar estos certificados si los nombres de sujeto y alternativo de sujeto se pueden usar en otros equipos. Sea consciente de que sólo se clonan los metadatos del certificado, y no los conjuntos de claves.

Para ejecutar los siguientes cmdlet en un equipo que tenga instalada la función del servidor Transporte perimetral, debe iniciar sesión mediante una cuenta que sea miembro del grupo local de administradores de dicho equipo.

Para clonar un nuevo certificado a partir de uno existente, primero tiene que identificar el certificado actual para el dominio ejecutando el siguiente comando:

Get-ExchangeCertificate -DomainName mail1.contoso.com

Donde mail1.contoso.com es el nombre del servidor o el FQDN del que desee hacer un certificado clonado.

El primer certificado que aparece en la salida es el certificado SMTP TLS predeterminado del servidor.

Para clonar el certificado, ejecute el siguiente comando:

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

Donde el valor de Thumbprint procede del primer certificado que figuraba en la salida de Get-ExchangeCertificate.

Este comando extrae los nombres del certificado existente que se identifican mediante la huella digital, y los usa en el nuevo certificado firmado automáticamente.

Generación de solicitudes para servicios de certificados de terceros

Si usa una CA para generar certificados, tiene que proporcionar una solicitud de certificado según las necesidades del CA.

Para generar una solicitud de certificado, puede usar el nuevo cmdlet New-ExchangeCertificate. Para generar una solicitud de certificado, use el parámetro GenerateRequest junto con el parámetro Path para definir dónde se creará el archivo de solicitud. El archivo resultante será un archivo de solicitud PKCS #10 (.req). PKCS #10 es el estándar de sintaxis de solicitud de certificación que se especifica en RFC 2314 (http://www.ietf.org/rfc/rfc2314.txt) (en inglés).

En los siguientes ejemplos se muestran algunas solicitudes de certificado típicas.

El primer ejemplo genera una solicitud de certificado para el servidor de Contoso, mail1. El CN del Nombre de sujeto contiene el FQDN del servidor y el Nombre alternativo de sujeto contiene todos los dominios aceptados para Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

El segundo ejemplo genera una solicitud de certificado para el servidor de Contoso, mail1. Contoso tiene un conector de envío en cada servidor de transporte perimetral que tiene un FQDN de mail.contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

El tercer ejemplo crea una solicitud de certificado desde un certificado existente de Contoso.com.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

El último ejemplo muestra cómo crear una solicitud de certificado con un carácter comodín para todos los subdominios de Contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

Para obtener más ejemplos, consulte el blog del equipo de Microsoft Exchange, Lecciones impartidas: Generación de un certificado con un CA de terceros (en inglés).

Instalación de certificados emitidos a partir de solicitudes de certificado

Después de haber enviado la solicitud de certificado a una CA, ésta emite un certificado o cadena de certificados. En ambos casos, los certificados se entregan en forma de archivos que hay que instalar con el cmdlet Import-ExchangeCertificate.

El siguiente ejemplo muestra cómo importar un certificado para TLS de SMTP.

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

El siguiente ejemplo muestra cómo importar un certificado y habilitarlo para un servidor de acceso de cliente que admitan clientes con Protocolo de oficina de correos versión 3 (POP3).

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

Información adicional

Para obtener más información acerca de las entidades de certificación que actualmente operan con sitios web propios de Exchange, consulte el artículo 929395 en la Knowledge Base de Microsoft, Empresas colaboradoras de certificados de comunicaciones unificadas para Exchange 2007 y para Communications Server 2007.

Si desea información adicional acerca de las tecnologías de criptografía y certificados y los conceptos asociados, consulte las siguientes publicaciones:

• Housley, Russ y Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. Nueva York: John Wiley & Son, Inc., 2001.

• Adams, Carlisle y Steve Lloyd. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. Nueva York: John Wiley & Son, Inc., 1996.

• Recomendaciones para implementar una infraestructura de clave pública en Microsoft Windows Server 2003