Enumeración y requisitos de certificados

• Se aplica a:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

En este tema para los desarrolladores de tarjetas inteligentes y profesionales de TI se describe cómo se administran y usan los certificados para el inicio de sesión con tarjeta inteligente.

Cuando se inserta una tarjeta inteligente, se realizan los pasos siguientes.

Nota

A menos que se mencione lo contrario, todas las operaciones se realizan de forma silenciosa (CRYPT_SILENT se pasa a CryptAcquireContext).

1. La base de datos del administrador de recursos de tarjeta inteligente busca el proveedor de servicios criptográficos (CSP) de la tarjeta inteligente.

2. Un nombre de contenedor completo se construye mediante el nombre del lector de tarjeta inteligente y se pasa al CSP. El formato es \\.<Reader name>\

3. Se llama a CryptAcquireContext para recuperar un contexto en el contenedor predeterminado. Si se produce un error, la tarjeta inteligente no se puede usar para el inicio de sesión de tarjeta inteligente.

4. El nombre del contenedor se recupera mediante el parámetro PP_CONTAINER con CryptGetProvParam.

5. Con el contexto adquirido en el paso 3, se consulta el CSP para el parámetro PP_USER_CERTSTORE. Para obtener más información, consulte Arquitectura de tarjeta inteligente. Si la operación se realiza correctamente, se devuelve el nombre de un almacén de certificados y el flujo del programa se omite en el paso 8.

6. Si se produce un error en la operación del paso 5, se consulta el contexto de contenedor predeterminado del paso 3 para la clave de AT_KEYEXCHANGE.

7. A continuación, se consulta el certificado desde el contexto de clave mediante KP_CERTIFICATE. El certificado se agrega a un almacén de certificados en memoria.

8. Para cada certificado del almacén de certificados del paso 5 o del paso 7, se realizan las siguientes comprobaciones:

   1. El certificado debe ser válido, según el reloj del sistema del equipo (no expirado o válido con una fecha futura)
   2. El certificado no debe estar en la parte AT_SIGNATURE de un contenedor
   3. El certificado debe tener un nombre principal de usuario (UPN) válido.
   4. El certificado debe tener el uso de la clave de firma digital.
   5. El certificado debe tener el EKU de inicio de sesión de tarjeta inteligente

   Cualquier certificado que cumpla estos requisitos se muestra al usuario con el UPN del certificado (o dirección de correo electrónico o asunto, dependiendo de la presencia de las extensiones de certificado)

9. A continuación, el proceso elige un certificado y se escribe el PIN.

10. LogonUI.exe empaqueta la información y la envía a Lsass.exe para procesar el intento de inicio de sesión

11. Si se ejecuta correctamente, LogonUI.exe se cierra. Esto hace que se libere el contexto adquirido en el paso 3.

Flujo de inicio de sesión de tarjeta inteligente en Windows

La mayoría de los problemas durante la autenticación se producen debido a cambios en el comportamiento de la sesión. Cuando se producen cambios, la autoridad de seguridad local (LSA) no vuelve a obtener el contexto de sesión; se basa en su lugar en el proveedor de servicios criptográficos para controlar el cambio de sesión.

Los certificados de cliente que no contienen un UPN en el subjectAltName campo (SAN) del certificado se pueden habilitar para el inicio de sesión, que admite una variedad más amplia de certificados y admite varios certificados de inicio de sesión en la misma tarjeta.

La compatibilidad con varios certificados en la misma tarjeta está habilitada de forma predeterminada. Los nuevos tipos de certificado deben habilitarse a través de la directiva de grupo.

Si habilita la directiva Permitir claves de firma válidas para la directiva de proveedor de credenciales de inicio de sesión, los certificados que estén disponibles en la tarjeta inteligente con una clave de solo firma aparecerán en la pantalla de inicio de sesión. Esto permite a los usuarios seleccionar su experiencia de inicio de sesión. Si la directiva está deshabilitada o no está configurada, los certificados basados en clave de firma de tarjeta inteligente no se muestran en la pantalla de inicio de sesión.

En el diagrama siguiente se muestra cómo funciona el inicio de sesión de tarjeta inteligente en las versiones compatibles de Windows.

Flujo de inicio de sesión de tarjeta inteligente

Estos son los pasos que se realizan durante el inicio de sesión de una tarjeta inteligente:

1. Winlogon solicita la información de credenciales de la interfaz de usuario de inicio de sesión

2. De forma asincrónica, se inicia el administrador de recursos de tarjeta inteligente y el proveedor de credenciales de tarjeta inteligente hace lo siguiente:

   1. Obtiene información de credenciales (una lista de credenciales conocidas o, si no existen credenciales, la información del lector de tarjetas inteligentes detectada por Windows)
   2. Obtiene una lista de lectores de tarjetas inteligentes (mediante la API WinSCard) y la lista de tarjetas inteligentes insertadas en cada una de ellas.
   3. Enumera cada tarjeta para comprobar que hay un certificado de inicio de sesión controlado por la directiva de grupo. Si el certificado está presente, el proveedor de credenciales de tarjeta inteligente lo copia en una caché temporal y segura en el equipo o terminal.

   Nota

   Las entradas de caché de tarjeta inteligente se crean para certificados con un nombre de firmante o con un identificador de clave de firmante. Si el certificado tiene un nombre de firmante, se almacena con un índice que se basa en el nombre del firmante y el emisor del certificado. Si se usa otro certificado con el mismo nombre de firmante y emisor de certificados, reemplazará la entrada almacenada en caché existente. Un cambio en este comportamiento permite la condición cuando el certificado no tiene un nombre de firmante, la memoria caché se crea con un índice que se basa en el identificador de clave del firmante y el emisor del certificado. Si otro certificado tiene el mismo identificador de clave de firmante y emisor de certificados, se reemplaza la entrada de caché. Cuando los certificados no tienen un nombre de firmante ni un identificador de clave de firmante, no se crea una entrada almacenada en caché.

   1. Notifica a la interfaz de usuario de inicio de sesión que tiene nuevas credenciales

3. La interfaz de usuario de inicio de sesión solicita las nuevas credenciales del proveedor de credenciales de tarjeta inteligente. Como respuesta, el proveedor de credenciales de tarjeta inteligente proporciona cada certificado de inicio de sesión a la interfaz de usuario de inicio de sesión y se muestran los iconos de inicio de sesión correspondientes. El usuario selecciona un icono de certificado de inicio de sesión basado en tarjeta inteligente y Windows muestra un cuadro de diálogo PIN

4. El usuario escribe el PIN y, a continuación, presiona ENTRAR. El proveedor de credenciales de tarjeta inteligente cifra el PIN

5. El proveedor de credenciales que reside en el sistema LogonUI recopila el PIN. Como parte del empaquetado de credenciales en el proveedor de credenciales de tarjeta inteligente, los datos se empaquetan en una estructura de KERB_CERTIFICATE_LOGON. El contenido principal de la estructura de KERB_CERTIFICATE_LOGON son el PIN de tarjeta inteligente, los datos de CSP (como el nombre de lector y el nombre del contenedor), el nombre de usuario y el nombre de dominio. El nombre de usuario es necesario si el dominio de inicio de sesión no está en el mismo bosque porque permite asignar un certificado a varias cuentas de usuario

6. El proveedor de credenciales encapsula los datos (como el PIN cifrado, el nombre del contenedor, el nombre del lector y la especificación de la clave de tarjeta) y los envía de vuelta a LogonUI.

7. Winlogon presenta los datos de LogonUI a LSA con la información del usuario en LSALogonUser

8. LSA llama al paquete de autenticación Kerberos (Kerberos SSP) para crear una solicitud de servicio de autenticación Kerberos (KRB_AS_REQ), que contiene un preautorizador (como se especifica en RFC 4556: Criptografía de clave pública para la autenticación inicial en Kerberos (PKINIT)).

   Si la autenticación se realiza mediante un certificado que usa una firma digital, los datos de autenticación previa constan del certificado público del usuario y del certificado firmado digitalmente con la clave privada correspondiente.

   Si la autenticación se realiza mediante un certificado que usa el cifrado de claves, los datos de autenticación previa constan del certificado público del usuario y el certificado cifrado con la clave privada correspondiente.

9. Para firmar la solicitud digitalmente (según RFC 4556), se realiza una llamada al CSP correspondiente para una operación de clave privada. Dado que la clave privada en este caso se almacena en una tarjeta inteligente, se llama al subsistema de tarjeta inteligente y se completa la operación necesaria. El resultado se devuelve al proveedor de soporte técnico de seguridad de Kerberos (SSP).

10. El SSP de Kerberos envía una solicitud de autenticación para un vale de concesión de vales (TGT) (por RFC 4556) al servicio del Centro de distribución de claves (KDC) que se ejecuta en un controlador de dominio.

11. El KDC busca el objeto de cuenta del usuario en Active Directory Domain Services (AD DS), como se detalla en Requisitos y asignaciones de certificados de cliente, y usa el certificado del usuario para comprobar la firma.

12. El KDC valida el certificado del usuario (tiempo, ruta de acceso y estado de revocación) para asegurarse de que el certificado procede de un origen de confianza. El KDC usa CryptoAPI para crear una ruta de certificación desde el certificado del usuario a un certificado de entidad de certificación raíz (CA) que reside en el almacén raíz en el controlador de dominio. A continuación, el KDC usa CryptoAPI para comprobar la firma digital en el autenticador firmado que se incluyó en los campos de datos de autenticación previa. El controlador de dominio comprueba la firma y usa la clave pública del certificado del usuario para demostrar que la solicitud se originó en el propietario de la clave privada que corresponde a la clave pública. El KDC también comprueba que el emisor es de confianza y aparece en el almacén de certificados NTAUTH.

13. El servicio KDC recupera la información de la cuenta de usuario de AD DS. El KDC crea un TGT, que se basa en la información de la cuenta de usuario que recupera de AD DS. Los campos de datos de autorización del TGT incluyen el identificador de seguridad (SID) del usuario, los SID de los grupos de dominios universales y globales a los que pertenece el usuario, y (en un entorno multidominio) los SID para los grupos universales de los que el usuario es miembro.

14. El controlador de dominio devuelve el TGT al cliente como parte de la respuesta KRB_AS_REP.

    Nota

    El paquete KRB_AS_REP consta de:

    • Certificado de atributo de privilegio (PAC)
    • SID del usuario
    • SID de cualquier grupo del que el usuario sea miembro
    • Una solicitud para el servicio de concesión de vales (TGS)
    • Datos de autenticación previa

    TGT se cifra con la clave maestra del KDC y la clave de sesión se cifra con una clave temporal. Esta clave temporal se deriva en función de RFC 4556. Con CryptoAPI, se descifra la clave temporal. Como parte del proceso de descifrado, si la clave privada está en una tarjeta inteligente, se realiza una llamada al subsistema de tarjeta inteligente mediante el CSP especificado para extraer el certificado correspondiente a la clave pública del usuario. (Las llamadas mediante programación para el certificado incluyen CryptAcquireContext, CryptSetProvParam con el PIN, CryptgetUserKey y CryptGetKeyParam). Una vez obtenida la clave temporal, el SSP de Kerberos descifra la clave de sesión.

15. El cliente valida la respuesta del KDC (tiempo, ruta de acceso y estado de revocación). Primero comprueba la firma del KDC mediante la construcción de una ruta de certificación desde el certificado del KDC a una CA raíz de confianza y, a continuación, usa la clave pública del KDC para comprobar la firma de respuesta.

16. Ahora que se ha obtenido un TGT, el cliente obtiene un vale de servicio, que se usa para iniciar sesión en el equipo local.

17. Con éxito, LSA almacena los vales y devuelve un mensaje de éxito a LSALogonUser. Una vez emitido este mensaje de éxito, se selecciona y establece el perfil de usuario del dispositivo, se crea una instancia de actualización de directiva de grupo y se realizan otras acciones.

18. Una vez cargado el perfil de usuario, el servicio de propagación de certificación (CertPropSvc) detecta este evento, lee los certificados de la tarjeta inteligente (incluidos los certificados raíz) y, a continuación, los rellena en el almacén de certificados del usuario (MYSTORE)

19. La comunicación del administrador de recursos de CSP a tarjeta inteligente se produce en el canal LRPC.

20. Si la autenticación se realiza correctamente, el servicio de propagación de certificados (CertPropSvc) propaga los certificados al almacén del usuario de forma asincrónica.

21. Cuando se quita la tarjeta, se quitan los certificados del almacén de caché seguro temporal. Los certificados ya no están disponibles para el inicio de sesión, pero permanecen en el almacén de certificados del usuario.

Nota

Se crea un SID para cada usuario o grupo en el momento en que se crea una cuenta de usuario o una cuenta de grupo en la base de datos de cuentas de seguridad local o en AD DS. El SID nunca cambia, incluso si se cambia el nombre de la cuenta de usuario o grupo.

Para obtener más información sobre el protocolo Kerberos, consulte Microsoft Kerberos.

De forma predeterminada, el KDC comprueba que el certificado del cliente contiene el EKU de autenticación de cliente de tarjeta inteligente szOID_KP_SMARTCARD_LOGON. Sin embargo, si está habilitada, la opción Permitir certificados sin atributo de certificado de uso de clave extendida permite que el KDC no requiera el EKU SC-LOGON. Sc-LOGON EKU no es necesario para las asignaciones de cuentas basadas en la clave pública.

Certificado KDC

Servicios de certificados de Active Directory proporciona tres tipos de plantillas de certificado:

• Controlador de dominio
• Autenticación del controlador de dominio
• Autenticación Kerberos

En función de la configuración del controlador de dominio, uno de estos tipos de certificados se envía como parte del paquete de AS_REP.

Asignaciones y requisitos de certificado de cliente

Los requisitos de certificado se enumeran en las versiones del sistema operativo Windows. La asignación de certificados describe cómo se asigna la información del certificado a la cuenta de usuario.

Requisitos de certificados

Componente	Requisitos
Ubicación del punto de distribución CRL	No obligatorio
Uso de claves	Firma digital
Restricciones básicas	No obligatorio
uso de clave extendida (EKU)	No se requiere el identificador de objeto de inicio de sesión de tarjeta inteligente. Nota Si hay un EKU, debe contener el EKU de inicio de sesión de la tarjeta inteligente. Los certificados sin EKU se pueden usar para el inicio de sesión.
Nombre alternativo del firmante	El identificador de correo electrónico no es necesario para el inicio de sesión con tarjeta inteligente.
Sujeto	No obligatorio
Intercambio de claves (campo AT_KEYEXCHANGE)	No es necesario para los certificados de inicio de sesión de tarjeta inteligente si está habilitada una configuración de directiva de grupo. (De forma predeterminada, la configuración de directiva de grupo no está habilitada).
CRL	No obligatorio
UPN	No obligatorio
Notas	Puede habilitar cualquier certificado para que sea visible para el proveedor de credenciales de tarjeta inteligente.

Asignaciones de certificados de cliente

La asignación de certificados se basa en el UPN contenido en el campo subjectAltName (SAN) del certificado. También se admiten certificados de cliente que no contienen información en el campo SAN.

SSL/TLS puede asignar certificados que no tienen SAN y la asignación se realiza mediante los atributos AltSecID en las cuentas de cliente. El altSecID X509, que se usa en la autenticación de cliente SSL/TLS, tiene el formato "X509: <Issuer Name><Subject Name. y <Issuer Name><Subject Name> se toman del certificado de cliente, con '\r' y '\n' reemplazadas por ','.

Puntos de distribución de lista de revocación de certificados

UPN en el campo Nombre alternativo del firmante

Campos Asunto y Emisor

Esta asignación de cuentas es compatible con el KDC, además de otros seis métodos de asignación. En la ilustración siguiente se muestra un flujo de lógica de asignación de cuentas de usuario que usa el KDC.

Flujo de alto nivel de procesamiento de certificados para el inicio de sesión

El objeto de certificado se analiza para buscar contenido para realizar la asignación de cuentas de usuario.

• Cuando se proporciona un nombre de usuario con el certificado, el nombre de usuario se usa para localizar el objeto de cuenta. Esta operación es la más rápida, ya que se produce la coincidencia de cadenas.
• Cuando solo se proporciona el objeto de certificado, se realizan varias operaciones para buscar el nombre de usuario para asignar el nombre de usuario a un objeto de cuenta.
• Cuando no hay información de dominio disponible para la autenticación, el dominio local se usa de forma predeterminada. Si se va a usar cualquier otro dominio para la búsqueda, se debe proporcionar una sugerencia de nombre de dominio para realizar la asignación y el enlace.

La asignación basada en atributos genéricos no es posible porque no hay ninguna API genérica para recuperar atributos de un certificado. Actualmente, el primer método que localiza una cuenta detiene correctamente la búsqueda. Pero se produce un error de configuración si dos métodos asignan el mismo certificado a cuentas de usuario diferentes cuando el cliente no proporciona el nombre de cliente a través de las sugerencias de asignación.

En la ilustración siguiente se muestra el proceso de asignación de cuentas de usuario para el inicio de sesión en el directorio mediante la visualización de varias entradas en el certificado.

Lógica de procesamiento de certificados

NT_AUTH directiva se describe mejor en la sección de parámetros CERT_CHAIN_POLICY_NT_AUTH de la función CertVerifyCertificateChainPolicy. Para obtener más información, vea CertVerifyCertificateChainPolicy.

Inicio de sesión con tarjeta inteligente para un único usuario con un certificado en varias cuentas

Un único certificado de usuario se puede asignar a varias cuentas. Por ejemplo, es posible que un usuario pueda iniciar sesión en una cuenta de usuario y también iniciar sesión como administrador de dominio. La asignación se realiza mediante el AltSecID construido en función de los atributos de las cuentas de cliente. Para obtener información sobre cómo se evalúa esta asignación, consulte Requisitos y asignaciones de certificados de cliente.

Nota

Dado que cada cuenta tiene un nombre de usuario diferente, se recomienda habilitar la opción Permitir directiva de grupo de sugerencias de nombre de usuario (clave del Registro X509HintsNeeded ) para proporcionar los campos opcionales que permiten a los usuarios escribir sus nombres de usuario e información de dominio para iniciar sesión.

En función de la información disponible en el certificado, las condiciones de inicio de sesión son:

1. Si no hay ningún UPN presente en el certificado:
   1. El inicio de sesión puede producirse en el bosque local o en otro bosque si un único usuario con un certificado necesita iniciar sesión en cuentas diferentes
   2. Se debe proporcionar una sugerencia si la asignación no es única (por ejemplo, si varios usuarios están asignados al mismo certificado).
2. Si un UPN está presente en el certificado:
   1. El certificado no se puede asignar a varios usuarios en el mismo bosque
   2. El certificado se puede asignar a varios usuarios en bosques diferentes. Para que un usuario inicie sesión en otros bosques, se debe proporcionar una sugerencia X509 al usuario.

Inicio de sesión con tarjeta inteligente para varios usuarios en una sola cuenta

Un grupo de usuarios podría iniciar sesión en una sola cuenta (por ejemplo, una cuenta de administrador). Para esa cuenta, los certificados de usuario se asignan para que estén habilitados para el inicio de sesión.

Se pueden asignar varios certificados distintos a una sola cuenta. Para que esto funcione correctamente, el certificado no puede tener UPN.

Por ejemplo, si Certificate1 tiene CN=CNName1, Certificate2 tiene CN=User1 y Certificate3 tiene CN=User2, el AltSecID de estos certificados se puede asignar a una sola cuenta mediante la asignación de nombres Usuarios y equipos de Active Directory.

Inicio de sesión con tarjeta inteligente entre bosques

Para que la asignación de cuentas funcione entre bosques, especialmente en los casos en los que no hay suficiente información disponible en el certificado, el usuario podría escribir una sugerencia en forma de nombre de usuario, como dominio o usuario, o un UPN completo, como user@contoso.com.

Nota

Para que el campo de sugerencia aparezca durante el inicio de sesión de tarjeta inteligente, la opción Permitir directiva de grupo de sugerencias de nombre de usuario (clave del Registro X509HintsNeeded ) debe estar habilitada en el cliente.

Compatibilidad de OCSP con PKINIT

El Protocolo de estado de certificado en línea (OCSP), que se define en RFC 2560, permite a las aplicaciones obtener información oportuna sobre el estado de revocación de un certificado. Dado que las respuestas OCSP son pequeñas y están bien enlazadas, es posible que los clientes restringidos quieran usar OCSP para comprobar la validez de los certificados de Kerberos en el KDC, para evitar la transmisión de CRL de gran tamaño y para ahorrar ancho de banda en redes restringidas. Para obtener información sobre las claves del Registro CRL, consulte Directiva de grupo de tarjeta inteligente y Configuración del Registro.

Los KDC de Windows intentan obtener respuestas OCSP y usarlas cuando estén disponibles. Este comportamiento no se puede deshabilitar. CryptoAPI para OCSP almacena en caché las respuestas OCSP y el estado de las respuestas. El KDC solo admite respuestas OCSP para el certificado de firmante.

Los equipos cliente de Windows intentan solicitar las respuestas OCSP y las usan en la respuesta cuando estén disponibles. Este comportamiento no se puede deshabilitar.

Requisitos de certificado raíz de tarjeta inteligente para su uso con el inicio de sesión de dominio

Para que el inicio de sesión funcione en un dominio basado en tarjetas inteligentes, el certificado de tarjeta inteligente debe cumplir las condiciones siguientes:

• El certificado raíz de KDC de la tarjeta inteligente debe tener un punto de distribución DE CRL HTTP enumerado en su certificado.
• El certificado de inicio de sesión de tarjeta inteligente debe tener el punto de distribución HTTP CRL en su certificado.
• El punto de distribución CRL debe tener una CRL válida publicada y una CRL delta, si procede, incluso si el punto de distribución crl está vacío.
• El certificado de tarjeta inteligente debe contener uno de los siguientes elementos:
  • Campo de asunto que contiene el nombre de dominio DNS en el nombre distintivo. Si no lo hace, se produce un error en la resolución de un dominio adecuado, por lo que se produce un error en los servicios de Escritorio remoto y en el inicio de sesión del dominio con la tarjeta inteligente.
  • UN UPN donde el nombre de dominio se resuelve en el dominio real. Por ejemplo, si el nombre de dominio es Engineering.Corp.Contoso, el UPN es username@engineering.corp.contoso.com. Si se omite alguna parte del nombre de dominio, el cliente Kerberos no puede encontrar el dominio adecuado.

Para permitir el inicio de sesión con tarjeta inteligente en un dominio en estas versiones, haga lo siguiente:

1. Habilitación de puntos de distribución DE CRL HTTP en la entidad de certificación
2. Reinicio de la entidad de certificación
3. Volver a emitir el certificado KDC
4. Emitir o volver a emitir el certificado de inicio de sesión de la tarjeta inteligente
5. Propagar el certificado raíz actualizado a la tarjeta inteligente que desea usar para el inicio de sesión de dominio

La solución alternativa consiste en habilitar la opción Permitir directiva de grupo de sugerencias de nombre de usuario (clave del Registro X509HintsNeeded ), que permite al usuario proporcionar una sugerencia en la interfaz de usuario de credenciales para el inicio de sesión de dominio.

Si el equipo cliente no está unido al dominio o si está unido a otro dominio, el equipo cliente solo puede resolver el dominio del servidor examinando el nombre distintivo en el certificado, no el UPN. Para que este escenario funcione, el certificado requiere un asunto completo, incluido DC=<DomainControllerName>, para la resolución de nombres de dominio.

Para implementar certificados raíz en una tarjeta inteligente para el dominio unido actualmente, puede usar el siguiente comando:

certutil.exe -scroots update

Para obtener más información sobre esta opción para la herramienta de línea de comandos, vea -SCRoots.