Compartir a través de

Consideraciones de diseño de PKI mediante Servicios de certificados de Active Directory

  • Artículo

Hay cosas que debe tener en cuenta al planear la implementación de una infraestructura de clave pública mediante Servicios de certificados de Active Directory. Aquí puede encontrar lo que necesita planear para instalar y configurar correctamente el entorno de PKI.

En un nivel alto, debería hacer lo siguiente:

  • Planear una infraestructura de clave pública (PKI) que sea adecuada para la organización.
  • Instalar y configurar un módulo de seguridad de hardware (HSM) conforme a las instrucciones del proveedor del HSM (si se prevé usar uno).
  • Crear un archivo CAPolicy.inf apropiado, si se quiere modificar la configuración de instalación predeterminada.
  • Elegir opciones criptográficas
  • Determinar el nombre de la entidad de certificación
  • Determinar el período de validez
  • Seleccionar la base de datos de la entidad de certificación
  • Configuración del punto de distribución de la lista de revocación de certificados y el acceso a la información de entidad

Planear la PKI

La implementación de la PKI se debe planear correctamente para procurar que la organización saque el máximo partido de la instalación de Servicios de certificados de Active Directory (AD CS). Antes de instalar un CA, debe definir el número de CA que va a instalar y en qué configuración. Por ejemplo, ¿necesita una CA raíz empresarial o una CA raíz independiente? ¿Cómo se manejarán las solicitudes de aprobación de certificados? ¿Cómo se administrará la revocación de certificados? Crear un diseño de PKI adecuado puede ser una tarea bastante prolongada, pero es muy importante para que la PKI funcione correctamente.

Usar un HSM

Un HSM es un dispositivo de hardware dedicado que se administra de forma independiente con respecto al sistema operativo. Estos módulos proporcionan un almacén de hardware seguro para las claves de CA, además de un procesador criptográfico dedicado con el que se aceleran las operaciones de firma y cifrado. El sistema operativo usa el HSM mediante interfaces de CryptoAPI, y el HSM funciona como un dispositivo de proveedor de servicios criptográficos (CSP).

Normalmente, los HSM son adaptadores PCI, pero también están disponibles como dispositivos basados en red, dispositivos serie y dispositivos USB. Si una organización tiene previsto implementar dos o más CA, se puede instalar un único HSM de red y compartirlo entre varias CA.

Para configurar una CA mediante un HSM, el HSM debe estar instalado y configurado antes de configurar CA con claves que se tienen que almacenar en dicho HSM.

Considerar un posible archivo CAPolicy.inf

El archivo CAPolicy.inf no es necesario para instalar AD CS, pero puede servir para personalizar la configuración de la CA. El archivo CAPolicy.inf contiene varias opciones que se usan al instalar una CA o al renovar el certificado de CA. Para que pueda usarse, el archivo CAPolicy.inf se debe crear y almacenar en el directorio %systemroot% (normalmente, C:\Windows).

La configuración que se incluya en el archivo CAPolicy.inf dependerá en gran medida del tipo de implementación que quieras crear. Así, por ejemplo, una CA raíz podría tener un archivo CAPolicy.inf como el siguiente:

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0

Seleccionar opciones criptográficas

La selección de opciones criptográficas relativas a una entidad de certificación (CA) puede conllevar diversas implicaciones en cuanto a seguridad, rendimiento y compatibilidad de dicha CA. Aunque las opciones criptográficas predeterminadas pueden ser adecuadas para la mayoría de las CA. La posibilidad de implementar opciones personalizadas puede resultar útil a los administradores y desarrolladores de aplicaciones que tengan más conocimientos de criptografía y que precisen de esta flexibilidad. Las opciones criptográficas se pueden implementar por medio de proveedores de servicios criptográficos (CSP) o proveedores de almacenamiento de claves (KSP).

Los CSP son componentes de hardware y software en los sistemas operativos Windows que proporcionan funciones de criptografía genéricas. Los CSP se pueden escribir para ofrecer varios algoritmos de firma y cifrado.

Cuando seleccione el proveedor, el algoritmo hash y la longitud de clave, debe tener especial cuidado a la hora de decidir qué opciones criptográficas van a admitir las aplicaciones y dispositivos que quiere usar. Aunque es una práctica recomendada seleccionar las opciones de seguridad más seguras, no todos los dispositivos y aplicaciones pueden admitirlo.

Permitir interacción del administrador cuando la CA obtiene acceso a la clave privada es una opción que se suele usar con los módulos de seguridad de hardware (HSM). Esta opción permite que el proveedor de servicios criptográficos puede pedir al usuario más autenticación cuando accede a la clave privada de la CA. Por ejemplo, exigir al administrador que escriba una contraseña antes de cada operación criptográfica.

Los proveedores de servicios criptográficos integrados admiten las longitudes de clave y algoritmos hash concretos recogidos en la siguiente tabla.

Proveedor de servicios criptográficos Longitud de clave Algoritmo hash
Proveedor de servicios criptográficos básicos de Microsoft, versión 1.0 - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
Proveedor de servicios criptográficos DSS básicos de Microsoft - 512
- 1024		 SHA1
Proveedor de servicios criptográficos de tarjeta inteligente básicos de Microsoft - 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
Proveedor de servicios criptográficos mejorados de Microsoft, versión 1.0 - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
Proveedor de servicios criptográficos seguros de Microsoft - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
RSA#Proveedor de almacenamiento de claves de software de Microsoft - 512
- 1024
- 2048
- 4096		 - SHA1
- SHA256
- SHA384
- SHA512
- MD2
- MD4
- MD5
DSA#Proveedor de almacenamiento de claves de software de Microsoft - 512
- 1024
- 2048		 SHA1
ECDSA_P256#Proveedor de almacenamiento de claves de software de Microsoft 256 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P384#Proveedor de almacenamiento de claves de software de Microsoft 384 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P521#Proveedor de almacenamiento de claves de software de Microsoft 521 - SHA1
- SHA256
- SHA384
- SHA512
RSA#Proveedor de almacenamiento de claves de tarjeta inteligente de Microsoft - 1024
- 2048
- 4096		 - SHA1
- SHA256
- SHA384
- SHA512
- MD2
- MD4
- MD5
ECDSA_P256#Proveedor de almacenamiento de claves de tarjeta inteligente de Microsoft 256 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P384#Proveedor de almacenamiento de claves de tarjeta inteligente de Microsoft 384 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P521#Proveedor de almacenamiento de claves de tarjeta inteligente de Microsoft 521 - SHA1
- SHA256
- SHA384
- SHA512

Determinar el nombre de entidad de certificación

Antes de configurar entidades de certificación en la organización, conviene establecer una convención de nomenclatura de CA.

Para crear un nombre se puede usar cualquier carácter Unicode, pero si la interoperabilidad es un factor que hay que tener en cuenta, probablemente sea mejor usar un juego de caracteres ANSI. Así, por ejemplo, hay algunos enrutadores que no pueden usar el Servicio de inscripción de dispositivos de red para inscribirse en los certificados si el nombre de CA contiene caracteres especiales, como un carácter de subrayado.

Si se usan caracteres no latinos (como caracteres cirílicos, árabes o chinos), el nombre de CA debe contener menos de 64 caracteres. Si solamente se usan caracteres no latinos, el nombre de CA no podrá tener más de 37 caracteres de longitud.

En Active Directory Domain Services (AD DS), el nombre que se especifique al configurar un servidor como CA será el nombre de la CA. El nombre común se refleja en cada certificado que emite la entidad de certificación. Por ello, es importante no usar el nombre de dominio completo como nombre común de la CA. De este modo, los usuarios malintencionados que obtengan una copia de un certificado no pueden identificar ni usar el nombre de dominio completo de la CA para crear un serio peligro para la seguridad.

El nombre de CA no debe ser exactamente igual que el nombre del equipo (nombre NetBIOS o DNS). De igual modo, el nombre de un servidor no se puede cambiar después de instalar Servicios de certificados de Active Directory (AD CS), puesto que se invalidarían todos los certificados que la CA emita.

Para cambiar el nombre de servidor después de haber instalado AD CS, hay que desinstalar la CA, modificar el nombre del servidor, volver a instalar la CA con las mismas claves y, por último, modificar el Registro de forma que use la base de datos y claves de CA existentes. No es necesario reinstalar una CA cuando se cambia el nombre de un dominio, sin embargo, sí será necesario volver a configurarla para que refleje el cambio de nombre.

Determinar el período de validez

La criptografía basada en certificados emplea la criptografía de claves públicas para proteger y firmar datos. Con el tiempo, los atacantes podrían hacerse con los datos protegidos mediante la clave pública y tratar de derivar la clave privada. Con tiempo y recursos suficientes, esta clave privada podría ponerse en riesgo y, en última instancia, presentar todos los datos protegidos como desprotegidos. También es posible que los nombres garantizados con un certificado tengan que cambiarse con el tiempo. Un certificado es un enlace entre un nombre y una clave pública, por lo que, si uno de ellos cambia, el certificado deberá renovarse.

Todos los certificados tienen un período de validez. Transcurrido ese período, el certificado dejará de considerarse como una credencial aceptable o utilizable.

Las CA no pueden emitir certificados que sean válidos más allá de su propio período de validez. Un procedimiento recomendado a este respecto consiste en renovar el certificado de CA cuando haya transcurrido la mitad de su período de validez. Al instalar una CA, conviene que tenga prevista esta fecha y asegurarse que quede registrada como una tarea futura.

Seleccionar la base de datos de la entidad de certificación

La base de datos de la entidad de certificación es un archivo en la unidad de disco duro. Aparte de este archivo, hay otros que sirven de archivos de registro de transacciones y que reciben todas las modificaciones en la base de datos antes de que estas se lleven a cabo. Dado que se puede acceder a estos archivos con frecuencia y de manera simultanea, es posible que quiera mantener la base de datos y los registros de transacciones en volúmenes independientes.

La ubicación de la base de datos y los archivos de registro de certificado es la siguiente ubicación del Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

El Registro contiene estos valores:

  • DBDirectory
  • DBLogDirectory
  • DBSystemDirectory
  • DBTempDirectory

Configuración del punto de distribución de la lista de revocación de certificados y el acceso a la información de entidad

Después de instalar una CA raíz o subordinada, es necesario configurar las extensiones de acceso a información de entidad emisora (AIA) y de puntos de distribución de CRL (CDP) para que la CA pueda emitir certificados. La extensión AIA indica dónde encontrar los certificados actualizados de la CA y la extensión CDP, dónde encontrar los CRL actualizados firmados por la CA. Estas extensiones son válidas para todos los certificados emitidos por la CA en cuestión.

Si se configuran estas extensiones, se garantiza que esta información va a estar incluida en cada certificado que la CA emita, con lo cual estará disponible para todos los clientes. El uso de las extensiones reduce el número de errores posible motivados por cadenas de certificados sin comprobar o revocaciones de certificados, que pueden provocar que no se establezcan conexiones de VPN, errores de inicio de sesión de tarjeta inteligente o firmas de correo electrónico sin comprobar.

En tanto que administrador de CA, puedes agregar, quitar o modificar puntos de distribución de CRL, así como las ubicaciones de emisión de certificados de CDP y AIA. Si se modifica la dirección URL de un punto de distribución de CRL, esto afecta únicamente a los certificados nuevos que se emitan. Los certificados que se hayan emitido anteriormente siguen haciendo referencia a la ubicación original, motivo por el cual estas ubicaciones se deben establecer antes de que la CA distribuya certificados.

Ten presentes las siguientes instrucciones al configurar direcciones URL de extensión CDP:

  • Intenta no publicar diferencias CRL en CA raíz sin conexión. En una CA raíz sin conexión no se suelen revocar muchos certificados, de ahí que una diferencia CRL probablemente no sea necesaria.
  • Ajuste las ubicaciones URL predeterminadas LDAP:// y https:// en la pestaña Extensiones de la pestaña Propiedades de extensión de la entidad de certificación según sus necesidades.
  • Publica una CRL en una ubicación HTTP de Internet o extranet para que los usuarios y aplicaciones ajenos a la organización puedan validar certificados. Se pueden publicar las direcciones URL HTTP y de LDAP de las ubicaciones de CDP para que los clientes puedan recuperar datos de CRL mediante HTTP y LDAP.
  • Recuerda que los clientes de Windows siempre recuperan la lista de direcciones URL de manera secuencial hasta encontrar una CRL válida.
  • Utiliza ubicaciones de CDP HTTP para proporcionar ubicaciones de CRL accesibles a clientes que ejecutan sistemas operativos que no son de Windows.

Pasos siguientes

Para obtener más información sobre la implementación de AD CS, consulte Implementación y administración de Servicios de certificados de Active Directory.