Lista de comprobación sobre la creación de una autoridad certificadora (CA) raíz e intermedia sin conexión

Solución:

Nota: Este es un compendio (muy, muy extenso) de varias recomendaciones y acciones que han dicho Microsoft, NIST y otros expertos en criptografía y PKI muy respetados. Si ve algo que requiere la más mínima revisión, hágamelo saber.

Antes de comenzar a configurar la CA y sus subs, es bueno saber que, aunque CryptoAPI de MSFT requiere una raíz autofirmada, algunos software que no son de MSFT pueden seguir RFC 3280 y permitir que cualquier CA sea la raíz confiable para fines de validación. Una razón puede ser que el software que no es MSFT prefiere una longitud de clave más baja.

Aquí hay algunas notas de configuración y orientación sobre cómo configurar una CA ROOT y los Subs:

Almacenamiento de la clave privada de la CA

• Mejor: Almacene la clave en un HSM que admita el conteo de claves. Cada vez que se utiliza la clave privada de la CA, el contador aumentará. Esto mejora su perfil de auditoría. Busque FIPS140 Nivel 3 o 4

• Bueno: guarde la clave privada en una tarjeta inteligente. Aunque no conozco ninguna tarjeta inteligente que ofrezca recuento de claves, habilitar el recuento de claves puede dar resultados inesperados en el registro de eventos.

• Aceptable: almacene la clave privada en Windows DPAPI. Asegúrese de que estas claves y el agente de inscripción de claves no terminen en Credenciales de roaming. Consulte también: Cómo enumerar DPAPI y credenciales móviles

Longitud clave

• No use 1024 como longitud de clave … NIST lo eliminó gradualmente en 2011, MSFT nunca lo agregará a su tienda Trusted Root CA ya que no cumple con los criterios técnicos mínimos aceptados.

• CA raíz que admite aplicaciones heredadas nunca debe ser superior a 2048 bits. Motivo: MSFT Support ve muchos casos en los que las aplicaciones Java o los dispositivos de red solo admiten tamaños de clave de 2048 bytes. Guarde las longitudes de bits más altas en las CA que están restringidas para un propósito específico (dispositivos Windows frente a dispositivos de red), etc.

• El NIST recomienda 2048 o 3072 bits. Se admite ECC, aunque puede causar problemas con la interoperabilidad del dispositivo.

• Planifique el cifrado más sólido posible (longitud de clave) en toda la PKI; de lo contrario, espere beneficios de seguridad mixtos.

• Los clientes móviles tienen problemas (CPU alta) o incompatibilidad con claves grandes

Vencimiento

El algoritmo y la longitud de la clave pueden influir en cuánto tiempo desea que los certificados sean válidos, ya que determinan efectivamente cuánto tiempo podría tardar un atacante en crackear, es decir, cuanto más fuerte sea la criptografía, más tiempo estará preparado para tener certificados válidos.

Un enfoque consiste en establecer cuál es la validez más larga que necesitará para los certificados de entidad final, duplicarla para las ca emisoras y luego duplicarla nuevamente para la ca raíz (en dos niveles). Con este enfoque, renovaría rutinariamente cada certificado CA cuando se alcanzara la mitad de su vida útil; esto se debe a que CA no puede emitir certificados con una fecha de vencimiento posterior a la del certificado CA en sí.

Los valores adecuados solo pueden ser determinados realmente por la política de seguridad y de su organización, pero normalmente una CA raíz tendría una vida útil del certificado de 10 o 20 años.

Si le preocupa la compatibilidad, establezca la fecha de vencimiento por debajo de 2038. Esto se debe a los sistemas que codifican datos como segundos desde el 1 de enero de 1970 sobre un entero de 32 bits con signo. Lea más sobre este problema aquí.

Elegir un hash

• Es posible que desee imitar la Autoridad de administración federal de PKI y configurar dos raíces de PKI. Un SHA-256 moderno para todos los dispositivos que lo admitan y un SHA-1 heredado. Luego, use certificados cruzados para mapear entre las dos implementaciones.

• Revise esta lista de compatibilidad SHA-2 para software de Microsoft

Notablemente:

• Los clientes de Windows 2003 y XP pueden necesitar un parche para los algoritmos SHA2 que incluyen SHA256, SHA384 y SHA512. Ver más información técnica

• Authenticode y S / MIME con hash SHA2 no son compatibles con XP o 2003

• “Con respecto a la compatibilidad con SHA-224, SHA-224 ofrece menos seguridad que SHA-256 pero requiere la misma cantidad de recursos. Además, SHA-224 generalmente no es utilizado por protocolos y aplicaciones. Los estándares de la Suite B de la NSA tampoco lo incluyen”. fuente

• “No use la suite SHA2 en ninguna parte de la jerarquía de la CA si planea que XP confíe en el certificado, valide el certificado, use el certificado en la validación en cadena o reciba un certificado de la CA. Aunque XP SP3 permite la validación de los certificados que utilice SHA2 en la jerarquía de CA, y KB 968730 permite la inscripción limitada de certificados firmados por una CA mediante SHA2, cualquier uso de firmas discretas bloquea XP por completo “. (fuente)

Elegir un proveedor criptográfico

• Vea esta lista de proveedores para obtener más información

Habilitar la generación de números de serie aleatorios

A partir de 2012, esto es obligatorio si usa MD5 como hash. Sigue siendo una buena idea si se utiliza SHA1 o superior. Consulte también este “cómo” de Windows 2008R2 para obtener más información.

Cree una declaración de prácticas de certificación

Una declaración de prácticas de certificación es una declaración de las prácticas que utiliza TI para administrar los certificados que emite. Describe cómo se interpreta la política de certificados de la organización en el contexto de la arquitectura del sistema de la organización y sus procedimientos operativos. El departamento de TI es responsable de preparar y mantener la declaración de prácticas de certificación. (fuente)

NOTA: En algunas situaciones, como cuando se utilizan firmas digitales en contratos vinculantes, la declaración de prácticas de certificación también se puede considerar una declaración legal sobre el nivel de seguridad que se proporciona y las salvaguardas que se utilizan para establecer y mantener el nivel de seguridad. .

Para obtener ayuda para escribir una declaración de CPS, aquí hay una “Ayuda laboral” producida por Microsoft

Práctica recomendada: aunque es posible poner texto de forma libre en este campo (consulte notice a continuación), la solución ideal es utilizar una URL. Esto permite que la política se actualice sin volver a emitir los certificados, y también evita la saturación innecesaria del almacén de certificados.

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.microsoft.com/policy/isspolicy.asp"

Políticas de certificado

También conocido como políticas de emisión o políticas de garantía (en MSFT), este es un OID autodefinido que describe la cantidad de confianza que uno debe depositar en su certificado (alta, media, baja, etc.). Vea esta respuesta de StackExchange para saber cómo usar correctamente este campo.

Asegúrese de que las políticas de la aplicación y las políticas de EKU coincidan

Las políticas de aplicación son una convención opcional de Microsoft. Si está emitiendo certificados que incluyen tanto la política de la aplicación como las extensiones EKU, asegúrese de que las dos extensiones contengan identificadores de objeto idénticos.

Habilitar la verificación de CRL

Normalmente, una CA de Windows Server 2003 siempre comprobará la revocación de todos los certificados en la jerarquía de PKI (excepto el certificado de CA raíz) antes de emitir un certificado de entidad final. Para deshabilitar esta función, use el siguiente comando en la CA y luego reinicie el servicio de CA:

 certutil –setreg caCRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

Punto de distribución de CRL

Orientación especial para las CA raíz

• Esto es opcional en una CA raíz y, si se hace incorrectamente, puede exponer su clave privada.

• Toda la publicación de CRL se realiza manualmente desde una RootCA fuera de línea a todas las demás CA secundarias. Una alternativa es utilizar un cable de audio para facilitar la comunicación unidireccional desde la raíz a la CA secundaria.

• Es perfectamente aceptable que la CA raíz emita diferentes ubicaciones de CRL para cada certificado emitido a las CA subordinadas.

• Tener una CRL en la raíz es una práctica recomendada si dos PKI confían entre sí y se realiza el mapeo de políticas. Esto permite revocar el certificado.

Obtener la CRL “correcta” es muy importante ya que depende de cada aplicación hacer la verificación de CRL. Por ejemplo, el inicio de sesión con tarjeta inteligente en los controladores de dominio siempre aplica la verificación de revocación y rechazará un evento de inicio de sesión si la verificación de revocación no se puede realizar o falla.

Nota Si algún certificado de la cadena no se puede validar o se encuentra revocado, toda la cadena adquiere el estado de ese certificado.

• Una CA raíz autofirmada no debe incluir ningún CDP. La mayoría de las aplicaciones de Windows no habilitan el indicador CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT y, por lo tanto, ignoran el CDP (este es el modo de validación predeterminado). Si el indicador está habilitado y el CDP está en blanco para el certificado raíz autofirmado, no se devuelve ningún error.

• No use HTTPS y LDAPS. Estas URL ya no se admiten como referencias de puntos de distribución. La razón es que las URL HTTPS y LDAPS utilizan certificados que pueden o no ser revocados. El proceso de verificación de revocación puede dar lugar a bucles de revocación cuando se utilizan URL HTTPS o LDAPS. Para determinar si el certificado está revocado, se debe recuperar la CRL. Sin embargo, la CRL no se puede recuperar a menos que se determine el estado de revocación de los certificados utilizados por HTTPS o LDAPS.

• Considere el uso de HTTP en lugar de LDAP: aunque AD DS permite la publicación de CRL en todos los controladores de dominio del bosque, implemente HTTP en lugar de LDAP para la publicación de información de revocación. Solo HTTP habilita el uso de ETag y Cache-Control: Max-age encabezados que brindan un mejor soporte para proxies e información de revocación más oportuna. Además, HTTP proporciona un mejor soporte heterogéneo ya que HTTP es compatible con la mayoría de los clientes de dispositivos de red, UNIX y Linux.

• Otra razón para no usar LDAP es que la ventana de revocación es menor. Cuando se usa AD LDAP para replicar la información de CA, la ventana de revocación no puede ser menor que el tiempo para que todos los sitios de AD obtengan la actualización de CA. A menudo, esta replicación puede tardar hasta 8 horas … es decir, 8 horas hasta que se revoque el acceso de un usuario de tarjeta inteligente. ‘Todo: el nuevo tiempo de actualización de CRL recomendado es: ????? `

• Haga que todas las URL estén altamente disponibles (es decir, no incluya LDAP para hosts externos). Windows ralentizará el proceso de validación hasta 20 segundos y volverá a intentar la conexión fallida repetidamente al menos con una frecuencia de 30 minutos. Sospecho que la búsqueda previa hará que esto ocurra incluso si el usuario no está usando activamente el sitio.

• Supervise el tamaño de su CRL. Si el objeto CRL es tan grande que CryptoAPI no puede descargar el objeto dentro del umbral de tiempo de espera máximo asignado, se devuelve un error de “revocación fuera de línea” y se termina la descarga del objeto.

Nota: La distribución de CRL a través de HTTP con compatibilidad con ETAG puede causar problemas con IE6 cuando se usa Windows 2003 / IIS6, donde la conexión TCP se restablece continuamente.

• (Opcional) Habilitar CRL más reciente: esta extensión no crítica enumera los emisores y las ubicaciones desde las que recuperar las CRL delta. Si el atributo “CRL más reciente” no está presente en la CRL ni en el certificado, la CRL base se tratará como una CRL normal, no como parte de un par CRL base / CRL delta.

La CA de Microsoft no incluye la extensión “CRL más reciente” en los certificados emitidos. Sin embargo, es posible agregar la extensión “CRL más reciente” a un certificado emitido. Debería escribir código para agregarlo a la solicitud, escribir un módulo de política personalizado o usar certutil –setextension en una solicitud pendiente. Para obtener más información sobre la inscripción de certificados avanzados, consulte la documentación “Inscripción y administración de certificados avanzados” en el sitio web de Microsoft.

Advertencia Si las CRL delta están habilitadas en una CA, tanto la CRL base como la CRL delta deben inspeccionarse para determinar el estado de revocación del certificado. Si uno de los dos, o ambos, no están disponibles, el motor de encadenamiento informará que no se puede determinar el estado de revocación y una aplicación puede rechazar el certificado.

Dimensionamiento y mantenimiento de CRL (Partición de CRL)

La CRL aumentará en 29 bytes por cada certificado revocado. En consecuencia, los certificados revocados se eliminarán de la CRL cuando el certificado alcance su fecha de vencimiento original.

Dado que la renovación de un certificado de CA hace que se genere una CRL nueva / en blanco, las CA emisoras pueden considerar renovar la CA con una nueva clave cada 100-125 K certificados para mantener un tamaño de CRL razonable. Este número de emisión se basa en el supuesto de que aproximadamente el 10 por ciento de los certificados emitidos serán revocados antes de su fecha de vencimiento natural. Si la tasa de revocación real o planificada es mayor o menor para su organización, ajuste la estrategia de renovación de claves en consecuencia. Más información

También considere dividir la CRL con más frecuencia si el vencimiento es de más de 1 o dos años, ya que aumenta la probabilidad de revocación.

El inconveniente de esto es el aumento de los tiempos de inicio, ya que el servidor valida cada certificado.

Precauciones de seguridad de CRL

Si usa una CRL, no firme la CRL con MD5. También es una buena idea agregar aleatorización a la clave de firma de CRL.

Acceso a la información de la autoridad

Este campo permite que el subsistema de validación de certificados descargue certificados adicionales según sea necesario si no residen en la computadora local.

• Una CA raíz autofirmada no debe incluir ninguna ubicación AIA (consulte el motivo aquí)

• Se permite un máximo de cinco URL en la extensión AIA para cada certificado en la cadena de certificados. Además, también se admite un máximo de 10 URL para toda la cadena de certificados. Esta limitación en la cantidad de URL se agregó para mitigar el uso potencial de referencias de “Acceso a información de autoridad” en ataques de denegación de servicio.

• No uses HTTPS y LDAPS. Estas URL ya no se admiten como referencias de puntos de distribución. La razón es que las URL HTTPS y LDAPS utilizan certificados que pueden o no ser revocados. El proceso de verificación de revocación puede dar lugar a bucles de revocación cuando se utilizan URL HTTPS o LDAPS. Para determinar si el certificado está revocado, se debe recuperar la CRL. Sin embargo, la CRL no se puede recuperar a menos que se determine el estado de revocación de los certificados utilizados por HTTPS o LDAPS.

Habilitar la validación de OCSP

El respondedor OCSP está ubicado convencionalmente en: http://<fqdn of the ocsp responder>/ocsp. Esta URL debe habilitarse en el AIA. Consulte estas instrucciones para Windows.

Tenga en cuenta que la validación completa de OCSP está desactivada de forma predeterminada (aunque debería estar “activada” para los certificados de vehículos eléctricos de acuerdo con la especificación). Además, habilitar la verificación OCSP agrega latencia a la conexión inicial

Los sistemas más seguros querrán habilitar el monitoreo OCSP en el lado del cliente o del servidor

Duración de la caché OCSP

Todas las acciones OCSP ocurren a través del protocolo HTTP y, por lo tanto, están sujetas a las reglas típicas de caché de proxy HTTP.

Específicamente el Max-age El encabezado define el tiempo máximo que un servidor proxy o un cliente almacenará en caché una respuesta CRL u OCSP antes de usar un GET condicional para determinar si el objeto ha cambiado. Utilice esta información para configurar el servidor web para establecer los encabezados adecuados. Busque en otra parte de esta página los comandos específicos de AD-IIS para esto.

Definir una política en certificados emitidos

La CA principal define si permite o no las políticas de certificados de CA de las CA secundarias. Es posible definir esta configuración cuando es necesario incluir un emisor o una política de aplicación en una sub CA.

Las políticas de ejemplo incluyen una EKU para tarjetas inteligentes, autenticación o autenticación SSL / servidor.

• Tenga cuidado con los certificados sin Certificate Policies extensión, ya que puede complicar el árbol de políticas. Consulte RFC 5280 para obtener más información.

• Sepa que las asignaciones de políticas pueden reemplazar otras políticas en la ruta

• Hay una política especial llamada anypolicy que altera el procesamiento

• Hay extensiones que alteran anypolicy

• Si usa políticas de certificado, asegúrese de marcarlas como critical de lo contrario el calculado valid_policy_tree se vuelve vacío, convirtiendo la política en un comentario glorificado.

Supervisar la aplicación de la longitud del DN

La especificación CCITT original para el campo OU dice que debe limitarse a 64 caracteres. Normalmente, la CA hace cumplir los estándares de longitud de nombre x.500 en la extensión del sujeto de los certificados para todas las solicitudes. Es posible que las trayectorias de unidades organizativas profundas superen las restricciones de longitud normales.

Puntos de distribución de certificados cruzados

Esta función ayuda donde los entornos necesitan tener dos PKI instaladas, una para hardware / software heredado que no es compatible con la criptografía moderna y otra PKI para propósitos más modernos.

Restringir el EKU

En contraste con RFC 5280 que dice “en general, [sic] la extensión EKU aparecerá solo en los certificados de entidad final. “Es una buena idea poner restricciones en el uso de la clave CA.

Un certificado de CA independiente típico contendrá permisos para crear firmas digitales, firma de certificado y firma de CRL como valores clave. Esto es parte del problema con el problema de seguridad de FLAME.

La implementación de la tarjeta inteligente MSFT requiere cualquiera de los siguientes EKU y posiblemente una revisión

• Tarjeta inteligente de Microsoft EKU
• Criptografía de clave pública para la autenticación inicial del cliente (PKINIT) EKU de autenticación del cliente, según se define en PKINIT RFC 4556

También tiene restricciones interesantes sobre la validación de EKU (enlace tbd).

Si está interesado en tener restricciones de EKU, debería ver esta respuesta con respecto a los OID y esto con respecto a los certificados contraídos

Tenga cuidado con las restricciones básicas “Ruta”

La restricción básica debe describir si el certificado es una “entidad final” o no. Agregar una restricción de ruta a una CA intermedia puede no funcionar como se esperaba, ya que es una configuración poco común y es posible que los clientes no la respeten.

Subordinación calificada para CA intermedias

• Para limitar los tipos de certificados que una subCA puede ofrecer, vea este enlace, y este

• Si se realiza una subordinación calificada, revocar una raíz con firma cruzada puede resultar difícil, ya que las raíces no actualizan las CRL con frecuencia.

Identificador de clave de autoridad / Identificador de clave de asunto

Nota Si la extensión AKI de un certificado contiene un KeyID, CryptoAPI requiere que el certificado del emisor contenga un SKI coincidente. Esto difiere de RFC 3280 donde la coincidencia de SKI y AKI es opcional. (todo: ¿Por qué alguien elegiría implementar esto?)

Dale a la raíz y a la CA un nombre significativo

Las personas interactuarán con su certificado al importarlo, revisar los certificados importados y solucionar problemas. La práctica y el requisito recomendados por MSFT es que la raíz tenga un nombre significativo que identifique a su organización y no algo abstracto y común como CA1.

La siguiente parte se aplica a los nombres de intermediarios / subCA que estarán restringidos para un propósito en particular: Autenticación vs Firma vs Cifrado

Sorprendentemente, los usuarios finales y los técnicos que no comprenden los matices de PKI interactuarán con los nombres de servidor que elija con más frecuencia de lo que cree si usa S / MIME o firmas digitales (etc.).

Personalmente, creo que es una buena idea cambiar el nombre de los certificados emisores a algo más fácil de usar, como "Company Signer 1" donde puedo decir de un vistazo

• De quién vendrá la firma (Texas A&M o su rival)
• ¿Para qué se usa esto? Cifrado vs firma

Es importante distinguir entre un mensaje cifrado entre dos partes y uno firmado. Un ejemplo en el que esto es importante es si puedo hacer que el destinatario se haga eco de una declaración que le envío. El usuario A podría decirle al usuario B “A, te debo $ 100”. Si B respondió con un eco de ese mensaje con la clave incorrecta, entonces efectivamente certificó digitalmente (en lugar de solo encriptar) una deuda ficticia de $ 100.

A continuación, se muestra un cuadro de diálogo de usuario de muestra para S / MIME. Espere interfaces de usuario similares para certificados basados ​​en navegador. Observe que el nombre del emisor no es fácil de usar.

Codificaciones alternativas

Nota: Hablando de nombres, si algún enlace de la cadena utiliza una codificación alternativa, es posible que los clientes no puedan verificar el campo del emisor en el asunto. Windows no normaliza estas cadenas durante una comparación, así que asegúrese de que los nombres de la CA sean idénticos desde una perspectiva binaria (a diferencia de la recomendación RFC).

Implementaciones de alta seguridad / Suite B

• Aquí hay información sobre los algoritmos de Suite B compatibles con Windows 2008 y R2

  ALGORITMO SECRETO TOP SECRET

  Cifrado: Estándar avanzado (AES) 128 bits 256 bits

  Firma digital: algoritmo de firma digital de curva elíptica (ECDSA) curva de 256 bits. Curva de 384 bits

  Intercambio de claves: Curva elíptica Diffie-Hellman (ECDH) Curva de 256 bits. Curva de 384 bits

  Hash: algoritmo hash seguro (SHA) SHA-256 SHA-384

• Para el cumplimiento de Suite B, el ECDSA_P384#Microsoft Software Key Service Provider así como el 384 tamaño de clave y SHA384 ya que el algoritmo hash también puede seleccionarse si el nivel de clasificación deseado es Top Secret. Deben utilizarse los ajustes que se correspondan con el nivel de clasificación requerido. ECDSA_P521 también está disponible como opción. Si bien el uso de una curva ECC de 521 bits puede exceder los requisitos criptográficos de Suite B, debido al tamaño de clave no estándar, 521 no forma parte de la especificación oficial de Suite B.

PKCS # 1 v2.1

• Los clientes XP y muchos sistemas que no son Windows no admiten este nuevo formato de firma. Esto debe desactivarse si es necesario admitir clientes más antiguos. Más información

• Solo recomendaría usarlo una vez que cambie a los algoritmos ECC para el cifrado asimétrico. (fuente)

Proteja los puertos DCOM de Microsoft CA

La CA de Windows Server 2003 no aplica el cifrado en las interfaces ICertRequest o ICertAdmin DCOM de forma predeterminada. Normalmente, esta configuración no es necesaria excepto en escenarios operativos especiales y no debe habilitarse. Solo las máquinas con Windows Server 2003 admiten de forma predeterminada el cifrado DCOM en estas interfaces. Por ejemplo, los clientes de Windows XP no aplicarán de forma predeterminada el cifrado en la solicitud de certificado a una CA de Windows Server 2003. fuente

Almacenamiento de claves privadas CNG vs almacenamiento CSP

Si inscribe la plantilla de certificado v3, la clave privada se almacena en el almacenamiento de claves privadas de CNG en la computadora cliente. Si inscribe la plantilla de certificado v2 o v1, la clave privada pasa al almacenamiento de CSP. Los certificados serán visibles para todas las aplicaciones en ambos casos, pero no sus claves privadas, por lo que la mayoría de las aplicaciones mostrarán el certificado como disponible, pero no podrán firmar ni descifrar datos con la clave privada asociada a menos que sean compatibles con el almacenamiento de CNG.

No puede distinguir entre almacenamientos de GNC y CSP utilizando el Certificado MMC. Si desea ver qué almacenamiento está usando un certificado en particular, debe usar CERTUTIL -repairstore my * (o CERTUTIL -user -repairstore my *) y eche un vistazo al campo Proveedor. Si dice “… Proveedor de almacenamiento de claves”, entonces es CNG mientras que todos los demás proveedores son CSP.

Si crea la solicitud de certificado inicial manualmente (Crear solicitud personalizada en MMC), puede seleccionar entre “Almacenamiento CNG” y “Clave heredada”, donde heredado significa CSP. La siguiente es mi lista basada en la experiencia de lo que no es compatible con GNC: no puede encontrar un lista autorizada en cualquier lugar, por lo que esto surge de mis investigaciones a lo largo del tiempo:

• EFS No compatible con Windows 2008 / Vista, compatible con Windows 7 / 2008R2
• certificados de cifrado de usuario

• Cliente VPN / WiFi (EAPTLS, PEAP Client)

• Windows 2008/7 No compatible con autenticación de certificado de usuario o equipo

• Certificados de servidor TMG 2010 en escuchas web
• Certificados de correo electrónico de usuario de Outlook 2003 para firmas o cifrado
• Certificados Kerberos Windows 2008 / Vista- DC
• Administrador de operaciones de System Center 2007 R2
• Administrador de configuración de System Center 2007 R2
• SQL Server 2008 R2-
• Gestión de certificados de Forefront Identity Manager 2010

Aquí encontrará más información sobre la compatibilidad con GNC (en checo, aunque Chrome maneja bien la traducción automática)

Tarjetas inteligentes y CA emisoras

Si planea dar a los usuarios una segunda tarjeta inteligente para la autenticación, use una segunda CA emisora ​​para eso. Motivo: requisitos de Windows 7

Usa el comando de Windows CERTUTIL -viewstore -enterprise NTAuth para solucionar problemas de inicio de sesión con tarjeta inteligente. El almacén NTAuth local es el resultado de la última descarga de directiva de grupo del almacén NTAuth de Active Directory. Es la tienda utilizada por el inicio de sesión con tarjeta inteligente, por lo que ver esta tienda puede ser útil para solucionar problemas de inicio de sesión con tarjeta inteligente.

Desmantelamiento de un árbol PKI

Si implementa dos árboles PKI, con la intención de retirar el árbol heredado en algún momento (donde todos los dispositivos antiguos se han vuelto obsoletos o actualizados), puede ser una buena idea establecer el campo Próxima actualización de CRL en Nulo. Esto evitará (¿debería?) El sondeo continuo de nuevas CRLS a los clientes. El razonamiento es que una vez que se desmantele la PKI, no habrá más administración ni más certificados revocados. Todos los certificados restantes simplemente se dejan expirar.

Más información sobre el desmantelamiento de PKI disponible aquí

Comandos específicos de AD CS

Esta es una lista de comandos relevantes para configurar un servidor CA de Windows 2008 R2. Los eliminé de la otra publicación porque esa información se estaba volviendo demasiado larga, y no todos los comandos se relacionan directamente con la configuración de una CA.

Esto es más de la sección Cómo, más bien del “qué y por qué”. También incluye diferencias específicas de la versión entre las versiones de CA (2000 vs 2003, vs 2008)

---

Enumere las marcas de edición de políticas de inscripción

Algunas solicitudes del cliente pueden eliminarse automáticamente en función de estas configuraciones de servidor ocultas.

C:UsersChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:Windowssystem32CertLog
  DBLogDirectory           REG_SZ = C:Windowssystem32CertLog
  DBTempDirectory          REG_SZ = C:Windowssystem32CertLog
  DBSystemDirectory        REG_SZ = C:Windowssystem32CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:UsersChrisLamont>certutil -getreg policyeditflags

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfigurationSecur
e Email Root v1PolicyModulesCertificateAuthority_MicrosoftDefault.PolicyEditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

La solución es ejecutar el comando certutil -setreg policyEditFlags -EDITF_ADDOLDKEYUSAGE que a su vez actualiza

     ConfigurationspatulaPolicyModulesCertificateAuthority_MicrosoftDefault.PolicyEditFlags:

Cómo definir una política por CA

Para incluir una política en los certificados emitidos, ingrese los siguientes comandos en un símbolo del sistema:

 certutil -v -setreg policyEnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

Puede deshabilitar la configuración con

  certutil -v -setreg policyEnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

Cómo definir la duración de la caché OCSP

Los siguientes comandos le permiten establecer, modificar y eliminar la configuración del encabezado Max-Age.

  appcmd set config /section:httpProtocol /+customHeaders.[name="cacheControlHeader",value="max-age=604800"]

Para ver los encabezados personalizados httpProtocol actuales

  appcmd list config /section:httpProtocol

Cómo importar certificados de CA sin conexión a AD

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

Cómo habilitar PKCS # 1 v1.21

Esto está habilitado cuando el archivo CAPolicy.inf tiene AlternateSignatureAlgorithm=1. Asegúrese de estar al tanto de los problemas de compatibilidad.

Finalmente, uno debe saber que instalar AD Certificate Services no es tan simple como agregar el rol. Debe verificar este script de instalación de VBS y asegurarse de que el archivo CAPolicy.inf se edite según sea necesario para su entorno

Cómo definir un punto de distribución de certificados cruzados

Los servicios de certificados de Windows AD habilitan esto en el archivo CAPolicy.info con el [CrossCertificateDistributionPointsExtension] entrada

Misc: diferencias de AIA al actualizar Windows 2000 CA a Windows 2003

Tenga en cuenta que hay un cambio de comportamiento entre las CA de Windows 2000 y 2003. La extensión AKI de los certificados emitidos por las CA de Windows difiere entre Windows 2000 y Windows Server 2003. De forma predeterminada, la siguiente información se almacena en la extensión AIA de los certificados emitidos.

• Windows 2000 La extensión AIA de los certificados emitidos por la CA incluye el DN LDAP de la CA emisora ​​(nombre del emisor), el número de serie del certificado de la CA emisora ​​y el hash de clave de la clave pública del certificado CA.

• Windows Server 2003 La extensión AIA de los certificados emitidos por la CA solo incluye un hash de la clave pública de la CA emisora, también conocida como Key-ID.

El cambio de comportamiento se debe a errores de encadenamiento que podrían ocurrir cuando se renovó el certificado de una CA. El comportamiento predeterminado de Windows 2000 podría resultar en cadenas incompletas si el certificado de CA utilizado para firmar el certificado emitido no estaba disponible para el cliente. Con el comportamiento predeterminado de Windows Server 2003, si la CA se renovó con el mismo par de claves, cualquier certificado de CA para la CA emisora ​​que utilice el mismo par de claves podría incluirse en la cadena de certificados.

Puede imitar el comportamiento anterior ejecutando este comando

 certutil -setreg policyEditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policyEditFlags -EDITF_ENABLEAKIISSUERSERIAL

Listado de certificados en AD

Este comando enumerará los certificados publicados en Active Directory.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

Compatibilidad con ISIS MTT v1.1 PKI

Consulte este artículo de KB para conocer los procedimientos, también aquí hay un método CAPolicy.inf alternativo para ISIS MTT v1.1

a menudo se pasa por alto un punto de la lista de verificación:

• BACKUPS
• BACKUPS
• BACKUPS

esp. si implementa una CA.

---

---

Utiliza Nuestro Buscador