> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/es/otro/troubleshooting/certifried.md).

# Vulnerabilidad de seguridad Certifried

Certifried es una vulnerabilidad de seguridad divulgada en mayo de 2022 como [CVE-2022-26921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26921) y [CVE-2022-26923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26923). [Oliver Lyak describió una vulnerabilidad de escalada de privilegios](https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4) que había descubierto utilizando autenticación mediante certificados. Describe que un atacante podría inscribir un certificado que le permita autenticarse como cuenta de equipo Domain Controller y, de ese modo, tomar el control de un dominio de Active Directory (y de un Tenant de Entra ID, si está conectado). Microsoft abordó las vulnerabilidades con [un parche en KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap). Este artículo describe cómo esto afecta a las organizaciones que ejecutan SCEPman y cómo SCEPman puede ayudar a mitigar el problema de seguridad.

## Resumen ejecutivo

* Los certificados de SCEPman no pueden usarse para ataques Certifried en la mayoría de los casos
* Usar SCEPman ayuda a mitigar los ataques Certifried, porque, a diferencia de los certificados de la CA de Microsoft, los certificados de CA de SCEPman normalmente no necesitan estar en el almacén NTAuth
* El parche de Microsoft no afectará a las instalaciones de SCEPman en la mayoría de los casos. En esos casos, habilitar el modo Full Enforcement es una buena idea.

## Consecuencias del parche de Microsoft

El parche en [KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap) solo agrega algunos eventos de auditoría adicionales de forma predeterminada. El modo Full Enforcement comienza el 11 de febrero de 2025, o antes si se habilita manualmente. Con el modo Full Enforcement, los certificados solo pueden usarse para la autenticación de usuarios y dispositivos si contienen el SID de una cuenta o, en el caso de los certificados de usuario, si el objeto de Active Directory del usuario contiene una referencia al certificado específico. La primera opción requiere una nueva extensión X.509 propietaria; la segunda se llama mapeo de certificados y utiliza el atributo altSecurityIdentities.

En general, esto solo afecta a las autenticaciones de AD. Requiere agregar el certificado de la CA al almacén NTAuth del bosque. De forma predeterminada, SCEPman no se agrega al almacén NTAuth si no haces esto explícita y manualmente. Si aún no lo has hecho y no piensas hacerlo, el parche no tiene ningún efecto en tu instancia de SCEPman. Hay un caso de uso en el que la documentación de SCEPman recomienda agregar el certificado de la CA de SCEPman al almacén NTAuth, que es cuando quieres [permitir que SCEPman emita certificados Domain Controller para autenticación Kerberos](/es/gestion-de-certificados/domain-controller-certificates.md#trust-the-ca-certificate-in-the-domain-for-kerberos-authentication).

### Certificados de dispositivo de Intune

Los certificados de dispositivo podrían ser utilizables para [Windows Hello for Business Certificate Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust). Si agregaste el nombre DNS de AD a los certificados de dispositivo para usarlos con Certificate Trust, podrías verse afectado. Esto requiere un objeto de dispositivo tanto en Entra ID como en AD. Para este caso de uso poco frecuente, recomendamos cambiar a [WHfB Cloud Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).

### Certificados de usuario de Intune

Los certificados de usuario pueden usarse para Windows Hello for Business Certificate Trust. También podrían usarse para otras formas de autenticación de AD basada en certificados, como sesiones RDP a equipos unidos al dominio o autenticación WiFi basada en NPS. Si quieres hacer esto, puedes usar la configuración [AppConfig:AddSidExtension](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-addsidextension) para permitir que SCEPman cree certificados de Strong Certificate Mapping. Los certificados de usuario para usuarios sincronizados entre AD y Entra ID reciben automáticamente la extensión con el OID 1.3.6.1.4.1.311.25.2 para vincularlos de forma fuerte con usuarios de AD.\
El equipo de Intune además [planea agregar un valor SAN](/es/configuracion-de-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates.md) para implementar el mapeo fuerte de certificados. También puedes usar este método como alternativa a la extensión SID.

### Certificados DC

Los certificados Domain Controller no se ven afectados por la vulnerabilidad y, por lo tanto, en general tampoco se ven afectados por el parche. Puede ocurrir que los certificados DC se usen para autenticación de cliente, para lo cual estaban permitidos anteriormente. Esto ya no funcionará una vez que se active Full Enforcement. Busca [Eventos de auditoría](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_auditevents) después de aplicar el parche para averiguar si esto podría afectarte. En la mayoría de los casos, esto no debería ser un problema.

## Ataques que usan certificados de SCEPman

El ataque Certifried solo puede usarse con certificados de CA en el almacén NTAuth. De forma predeterminada, este no es el caso del certificado de la CA de SCEPman. Por lo tanto, si usas SCEPman para inscribir certificados mediante Intune en lugar de Microsoft Active Directory Certificate Services, es probable que tu entorno sea inmune al ataque. Sin embargo, si tu SCEPman emite certificados Domain Controller, tu certificado de la CA de SCEPman está en el almacén NTAuth y deberías seguir leyendo.

Un atacante necesita un certificado con un UPN falsificado en la extensión Subject Alternative Name (SAN) y el uso ampliado de clave (EKU) Smart Card Logon, o un nombre DNS falsificado en el SAN y el EKU Client Authentication.

### Certificados de usuario de Intune

Supón que un atacante toma el control de una cuenta de usuario de Entra ID para permitir que SCEPman inscriba un certificado de usuario. ¿Cómo podría el atacante hacer que SCEPman emita un certificado utilizable para el ataque?

Los certificados de usuario suelen contener el EKU Client Authentication. Pero, si sigues las recomendaciones, no contienen un nombre DNS en el SAN. Por lo tanto, estos certificados no pueden usarse.

Si configuraste el EKU Smart Card Logon, el certificado puede usarse para autenticación, pero solo para la cuenta del UPN. El UPN proviene de Entra ID y se verifica, por lo que el atacante no puede introducir en el certificado un UPN de una cuenta de la que el atacante no se haya hecho ya con el control. Si además usas [mapeo fuerte de certificados](/es/configuracion-de-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates.md), puedes asegurarte de que los certificados no funcionen para una cuenta diferente si cambia el UPN.

### Certificados de dispositivo de Intune

Siguiendo nuestras recomendaciones básicas, los certificados de dispositivo tienen el EKU Client Authentication. Su SAN contiene una entrada URI en el SAN, que no puede usarse para el exploit. Sin embargo, además puedes agregar un nombre DNS al SAN, por ejemplo DeviceName.contoso.com. Si también importaste el certificado de la CA de SCEPman en el almacén NTAuth, estos certificados pueden usarse para autenticarse localmente como un dispositivo con el mismo nombre DNS. Como los usuarios pueden definir los nombres de sus dispositivos como quieran, podrían llamar a su dispositivo "PrimaryDomainController" y autenticarse localmente como PrimaryDomainController.contoso.com, incluso si ya existe un equipo así en AD. Por cierto, esto no es específico de SCEPman y también afectaría a otras implementaciones SCEP como NDES.

Por lo tanto, no debes agregar entradas de nombre DNS basadas en datos controlados por el usuario, como el nombre del dispositivo, con nombres de dominio que también se usan para dominios locales si usas la misma instancia de SCEPman también para certificados DC. Si aun así necesitas esto, debes habilitar el modo Full Enforcement para impedir el ataque de elevación de privilegios. También podrías ejecutar dos instancias separadas de SCEPman, una para certificados DC y otra para la inscripción en Intune.

### Certificados de usuario y dispositivo de Jamf Pro

Los certificados emitidos a través de Jamf Pro tendrán el EKU Client Authentication. Si sigues nuestra documentación, ningún tipo de certificado tendrá un nombre DNS en el SAN. Por ello, estos certificados son inutilizables para un ataque Certifried. Si tienes la CA de SCEPman en el NTAuthStore de tu AD, por ejemplo porque emites certificados DC, no debes agregar nombres DNS al SAN o asegurarte de habilitar el modo Full Enforcement en tu dominio de AD.

### Certificados de Certificate Master

Hay tres formas de emitir certificados mediante el componente Certificate Master a partir de la versión 2.1 de SCEPman.

[**Certificados de servidor TLS**](/es/gestion-de-certificados/certificate-master/tls-server-certificate-pkcs-12.md) no se ven afectados, ya que no contienen ni Smart Card Logon ni Client Authentication como EKU.

[**Certificados de cliente manuales**](/es/gestion-de-certificados/certificate-master/client-certificate-pkcs-12.md) tampoco se ven afectados. Contienen el EKU Client Authentication, pero ninguna entrada DNS SAN.

[**Solicitudes CSR personalizadas**](/es/gestion-de-certificados/certificate-master/certificate-signing-request-csr.md) son configurables libremente e incluyen certificados de autenticación. Como cualquiera que tenga acceso a la aplicación Certificate Master puede emitir un certificado de este tipo, deberías tomar al menos una de las siguientes precauciones:

* Asegúrate de que solo las cuentas privilegiadas puedan acceder a Certificate Master. Podrías, por ejemplo, [conceder acceso al componente Certificate Master](/es/despliegue-de-scepman/permissions/post-installation-config.md#granting-the-rights-to-request-certificates-via-the-certificate-master-website) solo a un único grupo de Entra ID que diseñes como [grupo de acceso privilegiado](https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-features).
* Usa instancias y certificados de CA de SCEPman separados para los certificados DC (cuyo certificado de CA está en el almacén NTAuth) y para Certificate Master.
* Habilita el modo Full Enforcement en tu dominio de AD.

### certificados de Domain Controller

Si un atacante tiene los permisos de acceso necesarios para emitir certificados Domain Controller, es probable que ya tenga control sobre un Domain Controller y sea ya el propietario del dominio. El atacante no necesita el ataque Certifried.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.scepman.com/es/otro/troubleshooting/certifried.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
