Compartir a través de

Descripción de los certificados TLS

  • Artículo

Se aplica a: Exchange Server 2010

Última modificación del tema: 2010-01-25

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 equipo específico, 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).

¿Está buscando las tareas de administración relacionadas con los certificados TLS? Consulte Administración de certificados TLS.

Contenido

Campos que usan los certificados para servicios TLS

Selección de certificados

Creación de certificados TLS

Referencias

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.

En esta sección se explican los campos de certificado más importantes y se ofrecen 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 enlaza 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.

Nombre Abreviatura Tipo Tamaño máx. Frecuencia Máx.\Recomendado en certificado\solicitud Orden del asunto

País o región

C

ASCII

2

1\1

1

Componente del dominio

DC

ASCII

255

Muchos

1

Estado o provincia.

S

Unicode

128

1

2

Localidad

L

Unicode

128

1

3

Organización

O

Unicode

64

1\1

4

Unidad organizativa

OU

Unicode

64

Muchos\Muchos

5

Nombre común

CN

Unicode

64

Muchos\1

6

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

El componente de dominio y país o región son, por convención, mutuamente excluyentes. El procedimiento recomendado es 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.

Importante

Aunque los certificados pueden tener más de un campo de nombre común, algunos servicios se implementan sobre la presunción de que solo existe un nombre común. Por tanto, varios nombres comunes pueden dar lugar a problemas de interoperatividad. Se recomienda que el certificado o la solicitud del certificado que desea crear contenga solo un nombre común.

Especificación de nombres distintivos relativos

Cuando se crean solicitudes de certificado con el cmdlet New-ExchangeCertificate, los nombres de sujetos se representan 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"

Entre otros 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, el procedimiento recomendado es 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, es posible que tenga que usar el código de País o región ("C"). En tal caso, debe 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, como se indica a continuación:

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1. 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 éste es un procedimiento generalizado, tenga en cuenta los dos problemas a continuación que se generan con este método.

En primer lugar, el tamaño máximo del campo Nombre común es de 64 caracteres. Esto representa menos caracteres que el tamaño máximo de un FQDN. Por lo tanto, para los FQDN que consten de más de 64 caracteres, debe colocar 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. Sin embargo, el nombre común (CN) es compatible con 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.mïcrosoft.com, el nombre se omitirá 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 leve 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. De forma predeterminada, esto significa que el cmdlet incluye el FQDN del servidor como CN predeterminado.

Nombres de dominio de certificado

Para TLS, los certificados deben contener nombres DNS porque TLS depende de la resolución 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 un sitio 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. Se pueden agregar varios dominios y nombres de servidor en el campo Nombre alternativo de sujeto de un certificado TLS. Puede crear un certificado que contenga varios Nombres alternativos de sujeto con el parámetro DomainName del cmdlet New-ExchangeCertificate. El parámetro DomainName tiene varios 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. Por 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 admite 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 aceptan. Por lo tanto, mail1.us.woodgrovebank.com, por ejemplo, no se aceptaría como una coincidencia de woodgrovebank.com.

Procedimientos recomendados 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 debe incluir en la solicitud es el que se detalla a continuación:

  • 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 debe coincidir con el registro A que se publica en el servidor DNS (público) de Internet. Este nombre se debe especificar 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 IncludeAcceptedDomains del cmdlet New-ExchangeCertificate para completar 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 completar el Nombre alternativo del sujeto en el certificado resultante.

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 contoso.com y todos los subdominios 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 de forma considerable.

Selección de certificados

Exchange sigue procesos de selección de certificado distintos en función del tipo de conexión SMTP.

Cuando los servidores de transporte de concentradores se comunican entre sí o con los servidores de transporte perimetral de la organización, se usan certificados TLS anónimos. Para obtener más información, consulte Selección de certificados anónimos de entrada TLS y Selección de certificados TLS anónimos salientes.

Cuando un host o cliente SMTP se conecta a los servidores de transporte de concentradores o de trasporte perimetral, se usa el proceso de selección de certificados STARTTLS. Para obtener más información, consulte Selección de certificados STARTTLS entrantes.

Creación de certificados TLS

Durante la instalación, Exchange 2010 crea un certificado autofirmado que usa todos los nombres de servidor y dominio que Exchange conoce en el momento de la instalación. Puede clonar este certificado para usarlo en servidores adicionales. También puede reemplazarlo con certificados emitidos por una entidad de certificación CA de terceros. En los temas siguientes se proporcionan instrucciones paso a paso para cada tarea.

Referencias

Para obtener más información acerca de las tecnologías y conceptos de certificados y criptografía, consulte las siguientes publicaciones:

  • Windows Server 2008 PKI y seguridad de certificados
  • Housley, Russ y Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. Nueva York: John Wiley & Son, Inc., 2001.
  • Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. Nueva York: John Wiley & Son, Inc., 1996.