Guía de la entidad de certificación

 

Se aplica a: Windows Server 2012 R2, Windows Server 2012

Una entidad de certificación (CA) se encarga de avalar la identidad de usuarios, equipos y organizaciones. Las CA autentican una entidad y responden por ella emitiendo un certificado firmado digitalmente. Asimismo, administran, revocan y renuevan certificados.

Una entidad de certificación puede hacer referencia a lo siguiente:

• Una organización que responde por la identidad de un usuario final

• Un servidor que la organización usa para emitir y administrar certificados

Si se instala el servicio de rol Entidad de certificación de Servicios de certificados de Active Directory (AD CS), el servidor de Windows se podrá configurar para las funciones de CA.

Antes de instalar el servicio de rol de CA, se debe:

1. Planear una infraestructura de clave pública (PKI) que sea adecuada para la organización.

2. Instalar y configurar un módulo de seguridad de hardware (HSM) conforme a las instrucciones del proveedor del HSM (si se prevé usar uno).

3. Crear un archivo CAPolicy.inf apropiado, si se quiere modificar la configuración de instalación predeterminada.

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, deberás definir el número de CA que vas a instalar y en qué configuración. Crear un diseño de PKI adecuado puede ser una tarea bastante prolongada, pero es muy importante para que la PKI funcione correctamente.

Para obtener más información y recursos, consulte la Guía de diseño de PKI en Microsoft TechNet.

Usar un HSM

El uso de un módulo de seguridad de hardware (HSM) puede mejorar la seguridad de la CA y el PKI.

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

Los HSM suelen ser adaptadores PCI, aunque también pueden estar disponibles como dispositivos de red, dispositivos en 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 almacenarán 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, este archivo 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

Por su parte, un archivo CAPolicy.inf para una empresa que emite un CA sería así:

[Version]
Signature= "$Windows NT$"
[PolicyStatementExtension]
Policies = LegalPolicy, LimitedUsePolicy
[LegalPolicy]
OID = 1.1.1.1.1.1.1.1.1
URL = "https://www.contoso.com/pki/Policy/USLegalPolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt"
[LimitedUsePolicy]
OID = 2.2.2.2.2.2.2.2.2
URL = "https://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt"
LoadDefaultTemplates=0

Seleccionar opciones de configuración de CA

En las siguientes secciones se detallan las opciones de configuración que deberás seleccionar después de instalar los archivos de instalación binarios de la CA.

Seleccionar el tipo de configuración

Las CA empresariales están integradas en Servicios de dominio de Active Directory (AD DS). Publican certificados y listas de revocación de certificados (CRL) en AD DS. Las CA empresariales emplean la información almacenada en AD DS (cuentas de usuario y grupos de seguridad incluidos) para aprobar o rechazar solicitudes de certificado. Estas CA empresariales usan plantillas de certificado. Cuando se emite un certificado, las CA empresariales usan la información de la plantilla de certificado para generar un certificado con los atributos apropiados para ese tipo de certificado.

Recurre a las CA empresariales para emitir certificados en caso de que quieras que la aprobación de certificados y la inscripción de certificados de usuario se produzcan de forma automatizada. Estas características solo están disponibles si la infraestructura de CA está integrada en Active Directory. Además, las CA empresariales son las únicas que pueden emitir certificados que permiten los inicios de sesión de tarjeta inteligente, dado que este proceso requiere que los certificados de tarjeta inteligente estén asignados automáticamente a las cuentas de usuario en Active Directory.

Las CA independientes no necesitan AD DS ni usan plantillas de certificado. Si usas CA independientes, toda la información sobre el tipo de certificado solicitado deberá estar incluida en la solicitud de certificado. Todas las solicitudes de certificado que se envían a CA independientes se ponen de forma predeterminada en una cola pendiente hasta que un administrador de CA las aprueba. Se pueden configurar CA independientes que emitan certificados a petición automáticamente, pero esto entraña más riesgos y no suele ser recomendable, puesto que las solicitudes no se autentican.

En cuando al rendimiento, el uso de CA independientes con emisión automática permite emitir certificados a mayor velocidad que con las CA empresariales; sin embargo, y a menos que se use la emisión automática, las CA independientes suelen conllevar un coste administrativo más elevado, ya que debe haber un administrador que revise manualmente cada solicitud de certificado para, luego, aprobarla o rechazarla. Por ello, el mejor uso que se puede dar a las CA independientes es en situaciones de seguridad de claves públicas en extranets o en Internet, donde los usuarios no tienen cuentas de usuario y el volumen de certificados que se emite y administra es relativamente bajo.

Usa CA independientes para emitir certificados cuando uses un servicio de directorio que no sea de Microsoft o cuando AD DS no esté disponible. En una misma organización se pueden usar entidades de certificación tanto empresariales como independientes, tal y como se refleja en la siguiente tabla.

Opción	CA empresarial	CA independiente
Publicar certificados en Active Directory y usar Active Directory para validar solicitudes de certificado.	Sí	No
Desconectar la CA.	No recomendada	Sí
Configurar la CA para emitir certificados automáticamente.	Sí	No recomendada
Permitir a los administradores aprobar solicitudes de certificado manualmente.	Sí	Sí
Permitir el uso de plantillas de certificado.	Sí	No
Autenticar solicitudes para Active Directory.	Sí	No

Elegir el tipo de CA

Las CA empresariales e independientes se pueden configurar como CA raíz o como CA subordinadas. Las CA subordinadas se pueden configurar además como CA intermedias (también denominadas CA de directiva) o CA emisoras.

Designar una CA raíz

Una CA raíz es una CA que está en el primer nivel de la jerarquía de certificación. Los clientes de la organización deben confiar en ella de forma incondicional. Todas las cadenas de certificados acaban en una CA raíz. Es necesario designar una CA raíz, tanto si se usan CA empresariales como independientes.

Como la CA raíz se encuentra en el primer nivel de la jerarquía de certificación, el campo Sujeto de un certificado emitido por una CA raíz tiene el mismo valor que el campo Emisor de dicho certificado. De igual modo, como la cadena de certificados acaba cuando llega a una CA autofirmada, todas las CA autofirmadas son CA raíz. La decisión de designar una CA como CA raíz de confianza se puede tomar a nivel empresarial, o bien hacerlo localmente un administrador de TI individual.

Las CA raíz sirven de base para el modelo de confianza de entidades de certificación. Así, garantiza que la clave pública del sujeto coincida con la información de identidad reflejada en el campo Sujeto de los certificados que emite. Cada CA puede comprobar esta relación mediante distintos estándares, de ahí que sea importante conocer las directivas y procedimientos de la entidad de certificación raíz antes de decidir confiar en ella para verificar claves públicas.

La CA raíz es la CA más importante de la jerarquía. Si la CA raíz está en riesgo, se considerará que también lo están todas las CA de la jerarquía y todos los certificados emitidos. Para mejorar la seguridad de la CA raíz, mantenla desconectada de la red y usa CA subordinadas para emitir certificados a otras CA subordinadas o usuarios finales.

CA subordinadas

Las CA que no son CA raíz se consideran subordinadas. La primera CA subordinada de una jerarquía obtiene su certificado de CA de la CA raíz. Esta primera CA subordinada puede usar esta clave para emitir certificados que confirmen la integridad de otra CA subordinada. Esta CA subordinada con un nivel superior se conoce como CA intermedia. Una CA intermedia está subordinada a una CA raíz, pero ostenta una posición de entidad de certificación superior ante una o varias CA subordinadas.

A menudo, las CA intermedias se denominan CA de directiva, porque se suelen usar para separar tipos de certificado que pueden distinguirse mediante directivas. Por ejemplo, la separación mediante directiva incluye el nivel de control que una CA reporta o la ubicación geográfica de la CA para, así, poder distinguir diferentes poblaciones de entidad final. Una CA de directiva puede tener un estado conectado o desconectado.

Almacenar una clave privada

La clave privada forma parte de la identidad de la CA y, como tal, se debe proteger de posibles riesgos. Muchas organizaciones protegen las claves privadas de CA con un módulo de seguridad de hardware (HSM). Si no se usa uno, la clave privada se almacenará en el equipo de la CA. Para obtener más información, consulte Módulo de seguridad de hardware (HSM) en Microsoft TechNet.

Las CA sin conexión deben almacenarse en ubicaciones seguras y no estar conectadas a la red. Las CA emisoras usan sus claves privadas cuando emiten certificados, con lo cual la clave privada debe poder estar accesible (esto es, en línea) mientras la CA esté operativa. En cualquier caso, la CA y su clave privada correspondiente deben estar protegidas físicamente.

Buscar una clave existente

Si ya hay una clave privada existente que quieras usar durante la instalación, puedes usar la pantalla Clave existente para dar con ella. Puedes usar el botón Cambiar para modificar el proveedor de servicios criptográficos y, de manera alternativa, la CA en la que quieras buscar una clave existente.

Buscar un certificado existente

Si ya hay un certificado que contiene la clave privada de la CA, puedes usar la pantalla Certificado existente para encontrarlo. Puedes usar el botón Importar para abrir el cuadro de diálogo Importar certificado existente y, luego, buscar el archivo PKCS #12 existente.

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 probablemente las opciones criptográficas predeterminadas sean aptas 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 una serie de algoritmos de firma y cifrado.

KSP puede proporcionar protección de clave segura para equipos que ejecutan una versión de servidor mínima de Windows Server 2008 R2 y una versión de cliente mínima de Windows Vista.

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). Con esta opción, el proveedor de servicios criptográficos puede pedir al usuario más autenticación cuando accede a la clave privada de la CA. Esta opción se puede usar para evitar un uso inapropiado de la CA y de su clave privada, ya que requiere que el administrador escriba una contraseña antes de poder realizar una 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

Establecer un nombre de CA

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 van a poder usar el Servicio de inscripción de dispositivos de red para inscribirse para un certificado si el nombre de CA contiene caracteres especiales, como un carácter de subrayado.

En Servicios de dominio de Active Directory (AD DS), el nombre que se especifique al configurar un servidor como CA será el nombre de la CA y, como tal, aparecerá reflejado en todos los certificados que dicha CA emita. Por ello, es importante no usar el nombre de dominio completo como nombre común de la CA, ya que, así, los usuarios malintencionados que obtengan una copia de un certificado no podrán identificarse ni usar el nombre de dominio completo de la CA para crear una posible vulnerabilidad de seguridad.

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, si bien sí que será necesario volver a configurarla para que refleje el cambio de nombre.

Obtener una solicitud de certificado

Una vez instalada una entidad de certificación raíz, muchas organizaciones instalarán una o más CA subordinadas con objeto de imponer restricciones de directiva en la infraestructura de clave pública (PKI) y emitir certificados a los clientes finales. El uso de al menos una CA subordinada contribuye a proteger la CA raíz de una exposición innecesaria. Cuando se instala una CA subordinada, hay que obtener un certificado de la CA primaria.

Si la CA primaria está conectada, puede usar la opción Enviar una solicitud de certificado a una CA primaria y seleccionar la CA primaria por el nombre de CA o el nombre de equipo.

Si la CA primaria no está conectada, debes usar la opción Guardar una solicitud de certificado en un archivo del equipo de destino. El procedimiento para ello será exclusivo de la CA primaria. Como mínimo, la CA primaria debe proporcionar un archivo que contenga el certificado que la CA subordinada acaba de emitir, preferiblemente, la ruta de certificación completa.

Si se obtiene un certificado de CA subordinada que no incluye la ruta de certificación completa, la nueva CA subordinada que se instale deberá ser capaz de crear una cadena de CA válida cuando se inicie. Haz lo siguiente para crear una ruta de certificación válida:

• Instala el certificado de la CA primaria en el almacén de certificados Entidades de certificación intermedias del equipo (si la CA primaria no es una CA raíz).

• Instala los certificados de cualquier otra CA intermedia de la cadena.

• Instala el certificado de la CA raíz en el almacén Entidades de certificación raíz de confianza.

Comprobar 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. De igual modo, los nombres garantizados mediante un certificado posiblemente 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 tengas prevista esta fecha y procurar que quede registrada como una tarea en el futuro.

Elegir una base de datos de CA

Como otras muchas bases de datos, 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. Es muy probable que el acceso a estos archivos sea muy frecuente y simultáneo, de modo que lo mejor es tener la base de datos o los registros de transacciones en discos duros separados o en configuraciones de disco de alto rendimiento, como un volumen seccionado.

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

Configurar la CA

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. Así, se procura que los clientes de PKI sufran el menor 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 seguirán 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 HTTP:// 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.

Windows PowerShell y certutil admiten números de variables (precedidos del símbolo porcentual [%]), lo que facilita la publicación de ubicaciones de CDP y AIA. La pestaña Propiedades de extensión de la entidad de certificación admite variables entre corchetes. En la siguiente tabla se establece una equivalencia entre las variables y las interfaces y se explican sus correspondientes significados.

Variable	Nombre de la pestaña de extensiones	Descripción
%1	<ServerDNSName>	Nombre DNS del equipo de la CA. Si existe una conexión a un dominio DNS, es el nombre de dominio completo; de lo contrario, es el nombre de host del equipo.
%2	<ServerShortName>	Nombre NetBIOS del servidor de la CA.
%3	<CaName>	Nombre de la CA.
%4	<CertificateName>	Permite que cada revisión extra del certificado tenga un sufijo único.
%4	Ninguno	No se utiliza.
%6	<ConfigurationContainer>	Ubicación del contenedor de configuración en Servicios de dominio de Active Directory (AD DS).
%7	<CATruncatedName>	Nombre de la CA truncado a 32 caracteres con un hash al final.
%8	<CRLNameSuffix>	Inserta un sufijo en el nombre de archivo al publicar una CRL en un archivo o ubicación URL.
%9	<DeltaCRLAllowed>	Cuando se publica una diferencia CRL, se reemplaza la variable por un sufijo aparte para distinguir la diferencia CRL de la CRL.
%10	<CDPObjectClass>	Identificador de clase de objeto de los puntos de distribución de CRL que se usa al publicar en una dirección URL de LDAP.
%11	<CAObjectClass>	Identificador de clase de objeto de la CA que se usa al publicar en una dirección URL de LDAP.

Publicar la extensión AIA

La extensión AIA señala a los equipos cliente dónde pueden encontrar el certificado que se ha de comprobar, lo que permite que el cliente pueda confirmar si el certificado es o no de confianza.

La extensión AIA se puede configurar mediante la interfaz de la entidad de certificación, Windows PowerShell o el comando certutil. En la siguiente tabla se detallan las opciones que se pueden usar con la extensión AIA por medio de estos métodos.

Nombre de casilla de la interfaz	Parámetro de Windows PowerShell	Valor de Certutil
Incluir en la extensión AIA de los certificados emitidos	-AddToCertificateAia	2
Incluir en la extensión del Protocolo de estado de certificados en línea (OCSP)	-AddToCertificateOcsp	32

Los ejemplos de esta sección para publicar la extensión AIA representan el siguiente escenario:

• El nombre de dominio es corp.contoso.com.

• Hay un servidor web llamado App1 en el dominio.

• App1 tiene una carpeta compartida denominada PKI que concede los permisos de lectura y escritura de CA.

• App1 tiene un DNS CNAME de www y un directorio virtual compartido llamado PKI.

• El primer protocolo que los equipos cliente deben usar para obtener la información de AIA es HTTP.

• El segundo protocolo que los equipos cliente deben usar para obtener la información de AIA es LDAP.

• La CA que se está configurando es una CA emisora conectada.

• No se utiliza OCSP.

Usar la interfaz para publicar la extensión AIA

La interfaz usa las variables y los nombres de casilla reflejados en las tablas anteriores. Puedes acceder a la interfaz a través de la interfaz de la entidad de certificación. En el panel de contenido, haz clic con el botón secundario en la CA, haz clic en Propiedades y, luego, en Extensiones. En Seleccionar extensión, haz clic en Acceso a la información de entidad emisora (AIA).

Figura 1   Menú de extensión AIA

Las ubicaciones y configuración establecidas en la interfaz de usuario son las siguientes:

• C:\Windows\system32\CertSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt

• https://www.contoso.com/pki/\<ServerDNSName>_<CaName><CertificateName>.crt

  • Incluir en la extensión AIA de los certificados emitidos

• file://\\App1.corp.contoso.com\pki\<ServerDNSName>_<CaName><CertificateName>.crt

• ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>

  • Incluir en la extensión AIA de los certificados emitidos

Usar Windows PowerShell para publicar la extensión AIA

Los siguientes comandos de Windows PowerShell pueden servir para configurar la extensión AIA del escenario que nos ocupa:

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia https://www.contoso.com/pki/%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia file://\\App1.corp.contoso.com\pki\%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Usar certutil para publicar la extensión AIA

El siguiente comando de certutil puede servir para configurar la extensión AIA del escenario que nos ocupa:

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:https://www.contoso.com/pki/%1_%3%4.crt\n1:file://\\App1.corp.contoso.com\pki\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Publicar la extensión CDP

La extensión CDP señala a los equipos cliente dónde pueden encontrar la CRL más reciente para poder confirmar que un certificado concreto no se ha revocado.

La extensión CDP se puede configurar mediante la interfaz de la entidad de certificación, Windows PowerShell o el comando certutil. En la siguiente tabla se detallan las opciones que se pueden usar con la extensión CDP por medio de estos métodos.

Nombre de casilla de la interfaz	Parámetro de Windows PowerShell	Valor de Certutil
Publicar las listas de revocación de certificados (CRL) en esta ubicación	-PublishToServer	1
Incluir en todas las CRL (Especifica dónde publicar en Active Directory cuando se hace manualmente).	-AddToCrlCdp	8
Incluir en las CRL (Los clientes la usan para encontrar la ubicación de diferencias CRL).	-AddToFreshestCrl	4
Incluir en la extensión CDP de los certificados emitidos	-AddToCertificateCdp	2
Publicar diferencias CRL en esta ubicación	-PublishDeltaToServer	64
Incluir en la extensión IDP de CRL emitidas	-AddToCrlIdp	128

Si va a permitir la publicación de diferencias CRL en un servidor web de Internet Information Services (IIS), deberá modificar la configuración de IIS predeterminada estableciendo allowDoubleEscaping=true del elemento requestFiltering en la sección system.web de la configuración de IIS. Por ejemplo, en caso de que quiera permitir el doble escape en el directorio virtual de PKI del sitio web predeterminado en IIS, ejecute el siguiente comando en el servidor web de IIS: appcmd set config "Default Web Site/pki" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true. Para obtener más información, consulte AD CS: el servidor web debe permitir un URI que contenga el carácter “+” para habilitar la publicación de diferencias CRL.

Los ejemplos de esta sección para publicar la extensión CDP representan el siguiente escenario:

• El nombre de dominio es corp.contoso.com.

• Hay un servidor web llamado App1 en el dominio.

• App1 tiene una carpeta compartida denominada PKI que concede los permisos de lectura y escritura de CA.

• App1 tiene un DNS CNAME de www y un directorio virtual compartido llamado PKI.

• El primer protocolo que los equipos cliente deben usar para obtener la información de CDP es HTTP.

• El segundo protocolo que los equipos cliente deben usar para obtener la información de CDP es LDAP.

• La CA que se está configurando es una CA emisora conectada.

• No se utiliza IDP.

Usar la interfaz para publicar la extensión CDP

La interfaz usa las variables y los nombres de casilla reflejados en las tablas anteriores. Puedes acceder a la interfaz a través de la interfaz de la entidad de certificación. En el panel de contenido, haz clic con el botón secundario en la CA, haz clic en Propiedades y, luego, en Extensiones. En Seleccionar extensión, haz clic en Puntos de distribución de lista de revocación de certificados (CDP).

Figura 2   Menú de extensión CDP

Las ubicaciones y configuración establecidas en la interfaz son las siguientes:

• C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  • Publicar las listas de revocación de certificados (CRL) en esta ubicación

  • Publicar diferencias CRL en esta ubicación

• https://www.contoso.com/pki/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  • Incluir en las CRL Los clientes la usan para encontrar la ubicación de diferencias CRL.

  • Incluir en la extensión CDP de los certificados emitidos

• file://\\App1.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

  • Publicar las listas de revocación de certificados (CRL) en esta ubicación

  • Publicar diferencias CRL en esta ubicación

• ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

  • Incluir en todas las CRL Especifica dónde publicar en Active Directory cuando se hace manualmente.

  • Incluir en la extensión CDP de los certificados emitidos

Usar Windows PowerShell para publicar la extensión CDP

Los siguientes comandos de Windows PowerShell sirven para configurar la extensión CDP del escenario que nos ocupa:

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl
Add-CACRLDistributionPoint -Uri file://\\App1.corp.contoso.com\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10" -AddToCrlCdp -AddToCertificateCdp

Usar certutil para publicar la extensión CDP

El siguiente comando de certutil configura la extensión CDP del escenario que nos ocupa:

certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:https://www.contoso.com/pki/%3%8%9.crl\n65:file://\\App1.corp.contoso.com\pki\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

Para publicar la CRL, puede ejecutar el comando certutil -crl en la CA desde Windows PowerShell o en un símbolo del sistema ejecutado como administrador. Para obtener más información sobre la configuración y publicación de CRL, consulte Configuración de revocación de certificados.

Comprobar la configuración

Para comprobar la configuración de la CA, puedes ejecutar los siguientes comandos desde Windows PowerShell o desde una ventana de símbolo del sistema:

Comando	Descripción
Certutil -CAInfo	Muestra el estado de los nombres, configuración regional, identificadores de objeto (OID) y CRL de la CA.
Certutil -getreg	Muestra la configuración del Registro de CA.
Certutil -ADCA	Confirma la configuración de las CA empresariales.

Puedes recurrir a la herramienta Enterprise PKI View (PKIView.msc) para comprobar las configuraciones de publicación de AIA y CDP. Para obtener más información, consulte PKI de empresa.

También puedes usar el servicio del rol Respondedor en línea para comprobar la revocación de certificados. Para obtener más información sobre el Respondedor en línea, consulte Guía de instalación, configuración y solución de problemas del Respondedor en línea.

Contenidos relacionados

• Foro de seguridad de Windows Server

• Preguntas más frecuentes (P+F) sobre la infraestructura de clave pública (PKI) de los Servicios de certificados de Active Directory (AD CS)

• Biblioteca y referencia de documentación de Windows PKI

• Blog de Windows PKI