> 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/otros/troubleshooting/general.md). # Problemas comunes ## Problemas al iniciar SCEPman ### Implementé SCEPman desde GitHub y antes funcionaba, pero ahora la Web App ya no se inicia Si el error es '503 Cannot download ZIP', entonces la aplicación web no puede descargar el ZIP con los binarios de la aplicación desde la URL configurada en la configuración de la aplicación WEBSITE\_RUN\_FROM\_PACKAGE (ver [Configuración de la aplicación](/es/configuracion-de-scepman/application-artifacts.md#change-artifacts)). La URL ** que habíamos recomendado para implementaciones de GitHub en versiones anteriores de esta documentación redirige a otra URL. Microsoft cambió el comportamiento de algunas de sus Web Apps y ahora algunas versiones no admiten redirecciones junto con WEBSITE\_RUN\_FROM\_PACKAGE. Por lo tanto, debes cambiar la URL a `https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip`. ### La Web App de Azure SCEPman no se está ejecutando Comprueba si el recurso de Azure está en funcionamiento. ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-fa1f838cc58fdfc0443c4d1e663643b3df01dd4e%2Fevent32_2%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(2\).png?alt=media) ### Mi App Service usa la versión incorrecta de .NET En el recurso App Service de SCEPman o Certificate Master, puedes comprobar qué Stack y versión están configurados para ese App Service en Settings -> Configuration -> General settings -> Stack settings. Aunque el Stack es .NET, es posible que la versión de .NET no coincida con lo que esperas para tu versión de SCEPman, por ejemplo, .NET 8 para SCEPman 2.8. Esto se debe a que algunas versiones comunes de .NET están disponibles automáticamente en todos los App Services de Windows, independientemente de qué versión de .NET selecciones en la configuración. Solo actualizamos SCEPman a una nueva versión de .NET cuando esta versión está incluida en este conjunto de versiones de .NET instaladas automáticamente. Hacemos esto porque nuestro mecanismo de actualización mediante [WEBSITE\_RUN\_FROM\_PACKAGE ](/es/configuracion-de-scepman/application-settings/basics.md#website_run_from_package)no nos da ningún control sobre la configuración de la versión de .NET. Por lo tanto, en realidad no importa qué se configure como versión de .NET. ### Mi App Service de SCEPman no funcionó el 2024-11-27 y dejó de funcionar por completo desde 2024-12-16 después de haber estado funcionando sin problemas durante muchos años Estamos cerrando el repositorio de artefactos obsoleto de SCEPman después de más de tres años trasladando los artefactos a la nueva ubicación . El miércoles, 2024-11-27, deshabilitamos temporalmente la ubicación anterior para advertir a los usuarios sobre el cierre permanente el lunes, 2024-12-16. Si te ves afectado, comprueba tu configuración de WEBSITE\_RUN\_FROM\_PACKAGE y [actualiza el valor](/es/configuracion-de-scepman/application-artifacts.md) a la nueva ubicación del paquete. Esto también actualizará tu versión de SCEPman de 1.8 a la versión más reciente, proporcionando [muchas mejoras](/es/changelog.md) con total compatibilidad hacia atrás. Si no estás seguro de si estás usando el repositorio más reciente, visita la página de inicio de SCEPman. Si aún está configurado en el repositorio antiguo, mostrará una advertencia (y lo ha hecho durante los últimos tres años ya) que se ve así:

SCEPman usando la ubicación antigua del paquete para WEBSITE_RUN_FROM_PACKAGE

## Problemas al emitir certificados ### El certificado raíz de confianza está implementado, pero mi certificado de dispositivo mediante el perfil SCEP da como resultado un error El perfil SCEP generará un error si la implementación del certificado no se realizó correctamente. Los errores pueden tener varias razones: ### El perfil de certificado SCEP está configurado con un error Esto podría ocurrir cuando se seleccionó un certificado raíz de confianza incorrecto en el perfil de certificado SCEP. Esto también se muestra en el registro de eventos: 1. Abre la aplicación de Eventos de Windows 2. Haz clic en **Registros de aplicaciones y servicios** 3. A continuación, haz clic en **Microsoft** 4. Luego, haz clic en **Windows** 5. Desplázate hacia abajo y busca **DeviceManagement-Enterprise-Diagnostics-Provider** y haz clic en él. 6. En la ventana que aparecerá, haz clic en **Admin** 7. Desplázate por la lista y busca el ID de evento **32** 8. Contiene un breve informe de error * SCEP: La inscripción del certificado falló. Resultado (El valor hash no es correcto.). ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-4e964c4cda9f70b7c0a4c24a293f0bf7133844c3%2Fevent32_1%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(12\).png?alt=media) Si estás usando una CA intermedia, ten en cuenta que debes [seleccionar el certificado de la CA intermedia](/es/despliegue-de-scepman/intermediate-certificate.md#intermediate-cas-and-intune-scep-profiles) y no el certificado de la CA raíz en el perfil de configuración SCEP. Ten en cuenta que esto es específico de la plataforma Windows y, por ejemplo, Android requiere seleccionar el certificado de la CA raíz en el perfil de configuración SCEP. ### Mi certificado no tiene la entrada correcta de URL de OCSP {% hint style="info" %} Este es solo un problema anterior a la versión 1.2 {% endhint %} Si el certificado del dispositivo tiene una URL localhost para la entrada de OCSP en el certificado como esta: ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-13206c885994d08c4ec6e5996ea261b2d3ee5912%2Fevent32_7%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media) A App Service le falta una configuración importante de la aplicación con el nombre **AppConfig:BaseUrl** establecido en la URL de azurewebsite. Para corregir esto, agrega la variable y guarda la configuración de App Service: ``` AppConfig:BaseUrl https://scepman-XXXXX.azurewebsites.net ``` Elimina este certificado del dispositivo y realiza la sincronización MDM. Si lo haces, verás una URL adecuada para la entrada de OCSP: ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-7729e8388eaa003c5561f926e7f26c54972fd5b2%2Fevent32_8%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media) ### Mi perfil de configuración SCEP muestra pendiente y no se aplica El perfil de configuración SCEP depende del perfil de certificado de Trusted Root. Asigna ambos perfiles al mismo usuario o grupo de dispositivos de Microsoft Entra ID (Azure AD) para asegurarte de que el usuario o dispositivo se superponga y ambos perfiles se destinen al dispositivo. No mezcles grupos de usuarios y de dispositivos. Si ves el estado pendiente para los perfiles de configuración en Intune durante mucho tiempo, probablemente la asignación sea incorrecta. ### Algunas máquinas Windows no inscriben ni renuevan certificados Puedes comprobar ambos desde el lado de SCEPman y desde el lado del cliente. Dependiendo del problema, que a menudo no sabes de antemano, la causa raíz se muestra solo en uno de los dos lados. Comprueba si hay alguna `[ERROR]` entrada en los registros de SCEPman. Posiblemente también busca el término de búsqueda `[WARN`, pero esto puede generar algunos falsos positivos. Oliver Kieselbach y Christoph Hannebauer escribieron [un artículo de blog sobre el análisis de problemas de solicitud o renovación de certificados](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) que te ayuda a localizar problemas de inscripción en el lado del cliente. El cliente SCEP de Windows solo admite TLS hasta la versión 1.2. Establecer la versión mínima de TLS entrante en 1.3 en el App Service de SCEPman provoca entradas de error particulares en el `DeviceManagement-Enterprise-Diagnostics-Provider` registro de eventos. Aquí hay un ejemplo de una máquina Windows 11: {% code overflow="wrap" fullWidth="false" %} ``` TimeCreated : 7/2/2025 12:51:06 PM ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider Id : 32 Message : SCEP: La inscripción del certificado falló. Resultado: (Unknown Win32 Error code: 0x80072f8f). TimeCreated : 7/2/2025 12:51:06 PM ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider Id : 307 Message : SCEP: Failed LogError Message : (SCEPInstallCertificateWithScepHelper:Failed to Initialize Inscripción SCEP con el servidor NDES 'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', huella digital del certificado de la CA '24C45EF4284A5093A9C3886A6466C1D6D84EE058' y certificados del servidor ''. LogError 0x80) ``` {% endcode %} ### Los dispositivos Windows 10 no pueden inscribirse con AutoPilot Actualmente, algunos dispositivos Windows 10 no tienen la hora correcta durante la experiencia OOBE. Esto no es fácil de ver, ya que la pantalla no muestra un reloj. Esto causa un problema con los certificados recién emitidos, ya que aún no son *todavía* válidos. Luego, Windows descarta estos certificados "inválidos" y muestra un error. Los certificados se emiten por defecto con 10 minutos de anticipación para resolver problemas menores de reloj, pero recientemente hemos visto dispositivos Windows 10 que están hasta 9 horas atrasados. Puedes continuar con la inscripción y, una vez finalizada, el dispositivo obtendrá un certificado correctamente, ya que entonces el reloj es correcto. También puedes usar la nueva opción [**AppConfig:ValidityClockSkewMinutes**](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-validityclockskewminutes) para retroceder la fecha de los certificados durante más de 10 minutos. Usa 1440 minutos para retroceder la fecha de los certificados durante un día completo. Esta será la configuración predeterminada para nuevas instalaciones de SCEPman para abordar este problema. ### Emití un certificado hoy, pero la fecha de emisión dice que fue ayer Esto se debe a que SCEPman retrocede la fecha del certificado un día para contrarrestar problemas con dispositivos cuyo reloj va atrasado, ver [Los dispositivos Windows 10 no pueden inscribirse con AutoPilot](#windows-10-devices-cannot-enroll-with-autopilot). ## Problemas con la validez de los certificados ### Comprobar certificado local #### Máquina Windows Primero, debes verificar la validez del certificado del dispositivo. Para ello, abre una línea de comandos como administrador y escribe el siguiente comando: ``` certutil -verifyStore MY ``` Observa el certificado con el ID del dispositivo emitido por SCEPman-Device-Root-CA-V1 y verifica si el certificado es válido (ver la última línea). ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-cb549f4e3708565d2455a9f459c2e54254ee26e8%2Fscepman_revocation1%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media) Para verificar que el respondedor OCSP está funcionando, puedes consultar la caché de la URL OCSP con el siguiente comando: ``` certutil -urlcache OCSP ``` ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-6c46d2b65ee1277d01b26b0f496975a577d35f21%2Fscepman_revocation2%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media) #### Máquina macOS Para comprobar la validez de un certificado en una máquina macOS usando OCSP, sigue estos pasos: 1. Exporta el certificado SCEPman Root CA desde **Acceso a Llaveros** (**Llaveros del sistema > Raíces del sistema**) como archivo \*.cer y colócalo en una carpeta (alternativamente, puedes descargarlo desde el sitio web de tu instancia de SCEPman). 2. Exporta el certificado de autenticación de cliente que quieres verificar desde **Acceso a Llaveros** (**Llaveros del sistema > Sistema > Mis certificados**) como archivo \*.cer en la misma carpeta. 3. Extrae la URL del respondedor OCSP del **Acceso a la información de autoridad** (AIA):
4. Abre una **Terminal** sesión y `cd` a la carpeta que contiene los certificados exportados. 5. Ejecuta el siguiente comando: ``` openssl ocsp -issuer -cert -text -url ``` 6. Hacia el final de la respuesta, se muestra el estado de revocación:\\
### Comprobar certificados de otras máquinas Como alternativa, puedes exportar el certificado del dispositivo y usar `certutil` en una máquina Windows para mostrar una pequeña interfaz de certutil para la comprobación OCSP: ``` certutil -url ``` ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-d3dffe20c2939eddc1ea08c0e4164440e9c7a3c3%2Fscepman_revocation4%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media) ### Revocar un usuario Si quieres revocar un **usuario** certificado, tienes dos opciones:‌ 1. Eliminar al usuario de Microsoft Entra ID (Azure AD) o 2. Bloquear el inicio de sesión del usuario Si quieres revocar un **dispositivo** certificado, tienes varias opciones dependiendo de [Validación de Intune](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory): 1. Microsoft Entra ID (Azure AD): Eliminar o deshabilitar el dispositivo ([Portal de Microsoft Entra ID (Azure AD)](https://aad.portal.azure.com/): "Dispositivos" - "Todos los dispositivos"). 2. **Intune**: Eliminar el dispositivo o desencadenar una acción remota (varios estados de administración como "WipePending" revocan automáticamente los certificados, como se indica en [Validación de Intune](/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-revokecertificatesonwipe)). 3. **Ambos directorios**: Ejecutar acciones para Microsoft Entra ID (Azure AD) **y** Intune, como se describe. {% hint style="info" %} Para más detalles sobre los directorios de dispositivos, lee el artículo [Directorios de dispositivos](/es/configuracion-de-scepman/device-directories.md). {% endhint %} El siguiente ejemplo revoca un certificado de dispositivo a través de Microsoft Entra ID (Azure AD): 1. Ve a **Dispositivos - Todos los dispositivos** en tu Microsoft Entra ID (Azure AD) 2. Elige un dispositivo 3. Haz clic en **Deshabilitar** A continuación, vuelve a escribir el siguiente comando: ``` certutil -verifyStore MY ``` Como puedes ver en la última línea, el **Certificado está REVOCADO** ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-42dfe633eca8d878a1bce1a117ef10e83ec46734%2Fscepman_revocation3%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media) Cuando habilites de nuevo el dispositivo en Microsoft Entra ID (Azure AD) y vuelvas a escribir el comando anterior, el certificado debería marcarse como válido. {% hint style="info" %} Puede tardar hasta 5 minutos antes de que aparezca el mensaje 'Marcado como válido'. {% endhint %} ### El Access Point no puede verificar un certificado de autenticación que SCEPman ha emitido *Síntomas*: Cisco ISE muestra un error de OCSP inaccesible. Aruba ClearPass también tiene este problema. El servidor, aparentemente SCEPman, responde con un paquete de reinicio TCP a la solicitud OCSP. *Causa*: Tanto Cisco ISE como Aruba ClearPass no admiten HTTP 1.1 al consultar OCSP y no envían un encabezado host en su solicitud OCSP. Por lo tanto, no pueden conectarse a una instancia general de SCEPman que se ejecute en Azure App Services. El mensaje de error podría verse así: ![](https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-73190ac3e2e77c25974776ffa48e74b2c33f96da%2Fcisco-ocsp-error%20\(2\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(2\)%20\(1\).jpg?alt=media) *Solución*: Consulta [aquí](/es/otros/troubleshooting/cisco-ise-host-header-limitation.md). ### Los certificados de dispositivo en mis sistemas Android (dedicados) no son válidos En sistemas Android (dedicados), Intune o Android ponen accidentalmente el ID de dispositivo de Intune en el certificado en lugar del ID de dispositivo de AAD en casos aleatorios, aunque configures la variable en el perfil de configuración SCEP. Entonces SCEPman no puede encontrar un dispositivo con este ID en AAD y por lo tanto considera el certificado revocado. Esto solo ocurre cuando usas el método de inscripción en modo compartido de Microsoft Entra ID (Azure AD) para dispositivos dedicados de propiedad corporativa en lugar del modo predeterminado. Si usas el modo predeterminado para los tipos de token `Dispositivo dedicado de propiedad corporativa`, no te afectará el problema. Intune seguirá colocando el ID de dispositivo de Intune en el certificado en lugar del ID de dispositivo de AAD, pero serán el mismo en el modo predeterminado, por lo que no importa. Para cambiar el modo de inscripción, ve a la [configuración de inscripción de Android del centro de administración de Microsoft Endpoint Manager](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) y elige `Dispositivo dedicado de propiedad corporativa (predeterminado)` en lugar de `Dispositivo dedicado de propiedad corporativa con modo compartido de Azure AD`. Consulta la [documentación de Microsoft](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) para conocer las implicaciones de esta selección. Actualmente estamos trabajando con Microsoft para resolver este problema en todas las configuraciones. Ponte en contacto con nuestro soporte si también te ves afectado. ### Mi Storage Account dice que no está conectado Si tu página de inicio de SCEPman muestra una etiqueta roja "Not Connected" para la conectividad de Storage Account, posiblemente la identidad administrada del App Service de SCEPman (y posiblemente la de SCEPman Certificate Master) carezca de permisos en el Storage Account. En este caso, SCEPman no puede comprobar si un certificado ha sido revocado manualmente y, por tanto, no puede responder a las solicitudes OCSP. Esto suele ocurrir si mueves el Storage Account a otra suscripción o grupo de recursos. También puede ocurrir después de actualizar una versión Community Edition a Enterprise Edition -- en este caso, el problema de permisos existía antes, pero Community Edition no lo comprobaba. Para solucionar esto, debes conceder a la identidad administrada del App Service de SCEPman y la de SCEPman Certificate Master el rol "Storage Table Data Contributor" en el Storage Account. Las asignaciones de roles se pueden realizar manualmente en Azure Portal en "Access Control (IAM)" en el Storage Account. Alternativamente, simplemente [vuelve a ejecutar una vez más el CMDlet de instalación de SCEPman desde el módulo PowerShell de SCEPman](/es/despliegue-de-scepman/permissions/post-installation-config.md#running-the-scepman-installation-cmdlet). ## SCEPman no emitirá certificados con EKUs distintos de Autenticación de cliente Comprueba las variables de entorno de SCEPman para ver qué está configurado para [AppConfig:UseRequestedKeyUsages](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-userequestedkeyusages). Si no está establecido, su valor predeterminado es "false". Las nuevas instalaciones lo establecerán automáticamente en "true"; sin embargo, las instalaciones antiguas de SCEPman lo tienen establecido en false. Las actualizaciones de SCEPman no cambian ningún comportamiento, excepto por correcciones o cambios que bajo ninguna circunstancia tengan una desventaja. Cuando se establece en false, se ignoran los EKUs y usos de clave solicitados.
--- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.scepman.com/es/otros/troubleshooting/general.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.