Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Hay algunas 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:
- Planee una infraestructura de clave pública (PKI) adecuada para su organización.
- Instale y configure un módulo de seguridad de hardware (HSM) según las instrucciones del proveedor de HSM, si planea usar uno.
- Cree un adecuado
CAPolicy.infsi desea modificar la configuración de instalación predeterminada. - Elegir opciones criptográficas
- Determinación del nombre de la entidad de certificación
- Determinar el período de validez
- Selección de la base de datos de CA
- Configuración del acceso a la información de autoridad y del punto de distribución de la lista de revocación de certificados.
Planear la PKI
Para asegurarse de que su organización puede aprovechar al máximo la instalación de Servicios de certificados de Active Directory (AD CS), debe planear la implementación de PKI de forma adecuada. Debe determinar cuántas CA necesita y en qué configuración antes de instalar cualquier CA. Por ejemplo, ¿necesita una Autoridad de Certificación Raíz de Empresa o una Autoridad de Certificación Raíz Independiente? ¿Cómo se controlarán las solicitudes de aprobación de certificados? ¿Cómo administrará la revocación de certificados? La creación de un diseño PKI adecuado puede llevar mucho tiempo, pero es importante para el éxito de la PKI.
Usar un HSM
Un HSM es un dispositivo de hardware dedicado que se administra por separado del sistema operativo. Estos módulos proveen un almacén de hardware seguro para las claves de CA, además añaden un procesador criptográfico dedicado que acelera las operaciones de firma y cifrado. El sistema operativo utiliza el HSM a través de las interfaces CryptoAPI y 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 planea implementar dos o más CA, puede instalar un único HSM basado en red y compartirlo entre varias CA.
Para configurar una Autoridad de Certificación mediante un HSM, el HSM debe estar instalado y configurado antes de configurar cualquier Autoridad de Certificación con claves que deban almacenarse en el HSM.
Considere la posibilidad de usar un archivo CAPolicy.inf
El CAPolicy.inf archivo no es necesario para instalar AD CS, pero se puede usar 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. El CAPolicy.inf archivo debe crearse y almacenarse en el %systemroot% directorio (normalmente C:\Windows) para que se use.
La configuración que incluya en el CAPolicy.inf archivo depende en gran medida del tipo de implementación que desea crear. Por ejemplo, una autoridad de certificación raíz podría tener un archivo CAPolicy.inf que se asemeje al siguiente:
[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0
Selección de opciones criptográficas
La selección de opciones criptográficas para una entidad de certificación (CA) puede tener implicaciones significativas de seguridad, rendimiento y compatibilidad para esa entidad de certificación. Aunque las opciones criptográficas predeterminadas pueden ser adecuadas para la mayoría de las CA. La capacidad de implementar opciones personalizadas puede ser útil para los administradores y desarrolladores de aplicaciones con un conocimiento más avanzado de la criptografía y una necesidad de esta flexibilidad. Las opciones criptográficas se pueden implementar mediante proveedores de servicios criptográficos (CSP) o proveedores de almacenamiento de claves (CSP).
Los CSP son componentes de hardware y software en sistemas operativos Windows que proporcionan funciones criptográficas genéricas. Los CSP se pueden escribir para proporcionar varios algoritmos de cifrado y firma.
Al seleccionar el proveedor, el algoritmo hash y la longitud de clave, tenga en cuenta cuidadosamente qué opciones criptográficas admiten las aplicaciones y los dispositivos que quiere usar. Aunque es un procedimiento recomendado seleccionar las opciones de seguridad más seguras, no todas las aplicaciones y dispositivos pueden admitirlas.
Permitir la interacción del administrador cuando la entidad de certificación accede a la clave privada es una opción que normalmente se usa con módulos de seguridad de hardware (HSM). Esta opción permite al proveedor criptográfico solicitar al usuario la autenticación adicional cuando se accede a la clave privada de la ENTIDAD de certificación. Por ejemplo, exigir al administrador que escriba una contraseña antes de cada operación criptográfica.
Los proveedores criptográficos integrados admiten longitudes de clave específicas y algoritmos hash, como se describe en la tabla siguiente.
| Cryptographic provider | Key lengths | Hash algorithm |
|---|---|---|
| Proveedor criptográfico base de Microsoft v1.0 | - 512 - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| Proveedor criptográfico de DSS base de Microsoft | - 512 - 1024 |
SHA1 |
| Proveedor criptográfico de tarjeta inteligente base de Microsoft | - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| Proveedor criptográfico mejorado de Microsoft v1.0 | - 512 - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| Proveedor criptográfico seguro 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 |
Determinación del nombre de la entidad de certificación
Antes de configurar las entidades de certificación (CAs) en su organización, debe establecer una convención de nomenclatura para las CAs.
Puede crear un nombre mediante cualquier carácter Unicode, pero es posible que desee usar el juego de caracteres ANSI si la interoperabilidad es un problema. Por ejemplo, ciertos tipos de enrutadores no pueden usar el servicio de inscripción de dispositivos de red para inscribirse para certificados si el nombre de la entidad de certificación contiene caracteres especiales, como un carácter de subrayado.
Si usa caracteres no latinos (como caracteres cirílicos, árabes o chinos), el nombre de ca debe contener menos de 64 caracteres. Si utiliza solo caracteres no latinos, el nombre del CA no puede tener más de 37 caracteres.
En Active Directory Domain Services (AD DS), el nombre que especifique al configurar un servidor como una ENTIDAD de certificación se convierte en el nombre común de la ENTIDAD de certificación. 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 obtienen una copia de un certificado no pueden identificar y usar el nombre de dominio completo de la ENTIDAD de certificación para crear una posible vulnerabilidad de seguridad.
El nombre de la ENTIDAD de certificación no debe ser idéntico al nombre del equipo (NetBIOS o nombre DNS). Además, no puede cambiar el nombre de un servidor después de instalar Servicios de certificados de Active Directory (AD CS) sin invalidar todos los certificados emitidos por la ENTIDAD de certificación.
Para cambiar el nombre del servidor después de instalar AD CS, debe desinstalar la CA, cambiar el nombre del servidor, reinstalar la CA con las mismas claves y modificar el registro del sistema para usar las claves y la base de datos de CA existentes. No tiene que volver a instalar una ENTIDAD de certificación si cambia el nombre de un dominio; sin embargo, debe volver a configurar la entidad de certificación para admitir el cambio de nombre.
Determinar el período de validez
La criptografía basada en certificados usa criptografía de clave pública para proteger y firmar datos. Con el tiempo, los atacantes podrían obtener datos protegidos con la clave pública e intentar derivar la clave privada de ella. Dado el tiempo y los recursos suficientes, esta clave privada podría verse comprometida, dejando todos los datos protegidos sin protección. También es posible que los nombres garantizados por un certificado deban cambiarse a lo largo del tiempo. Dado que un certificado es un enlace entre un nombre y una clave pública, cuando se cambia, se debe renovar el certificado.
Cada certificado tiene un período de validez. Después del final del período de validez, el certificado ya no se considera 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 consiste en renovar el certificado de entidad de certificación cuando la mitad de su período de validez ha expirado. Al instalar una CA, conviene que tenga prevista esta fecha y asegurarse que quede registrada como una tarea futura.
Selección de la base de datos de CA
La base de datos de la entidad de certificación es un archivo en el disco duro. Además de este archivo, otros archivos sirven como registros de transacciones y reciben todas las modificaciones en la base de datos antes de realizar los cambios. Dado que se puede acceder a estos archivos con frecuencia y simultáneamente, es posible que desee mantener la base de datos y los registros de transacciones en volúmenes independientes.
La ubicación de los archivos de registro y la base de datos de certificados se conservan en la siguiente ubicación del Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
El registro contiene los siguientes valores:
DBDirectoryDBLogDirectoryDBSystemDirectoryDBTempDirectory
Configuración del acceso a la información de autoridad y del punto de distribución de la lista de revocación de certificados.
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. La extensión CDP indica dónde encontrar los CRL actualizados firmados por la CA. Estas extensiones se aplican a todos los certificados emitidos por esa entidad de certificación.
La configuración de estas extensiones garantiza que esta información se incluya en cada certificado que emite la ENTIDAD de certificación para que esté disponible para todos los clientes. El uso de las extensiones produce menos errores debido a cadenas de certificados no comprobados o revocaciones de certificados, lo que puede dar lugar a conexiones VPN incorrectas, inicios de sesión de tarjetas inteligentes con errores o firmas de correo electrónico no comprobadas.
Como administrador de CA, puede agregar, quitar o modificar puntos de distribución crL y las ubicaciones para la emisión de certificados CDP y AIA. La modificación de la dirección URL de un punto de distribución CRL solo afecta a los certificados recién emitidos. Los certificados emitidos anteriormente siguen haciendo referencia a la ubicación original, por lo que debe establecer estas ubicaciones antes de que la CA distribuya los certificados.
Tenga en cuenta estas directrices al configurar direcciones URL de extensión de CDP:
- Intente 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://yhttp://en la pestaña Extensiones de la pestaña Propiedades de extensión de la entidad de certificación según sus necesidades. - Publique una CRL en una ubicación http de Internet o extranet para que los usuarios y las aplicaciones fuera de la organización puedan realizar la validación de certificados. Puede publicar las direcciones URL LDAP y HTTP para las ubicaciones de CDP para permitir que los clientes recuperen datos CRL con HTTP y LDAP.
- Recuerde que los clientes de Windows siempre recuperan la lista de direcciones URL en orden secuencial hasta que se recupera una CRL válida.
- Use ubicaciones de HTTP CDP para proporcionar ubicaciones CRL accesibles para los clientes que ejecutan sistemas operativos que no son Windows.
Next steps
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.