# Problemas comunes ## Problemas al iniciar SCEPman ### Implementé SCEPman desde GitHub y antes funcionaba, pero ahora la aplicación web 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 opción de la aplicación WEBSITE\_RUN\_FROM\_PACKAGE (ver [Configuración de la aplicación](https://docs.scepman.com/es/configuracion-de-scepman/application-artifacts#change-artifacts)). La URL ** que recomendábamos para implementaciones de GitHub en versiones anteriores de esta documentación redirige a otra URL. Microsoft cambió el comportamiento de algunas de sus aplicaciones web 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 aplicación web de SCEPman Azure 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\).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 Configuración -> Configuración -> Configuración general -> Configuración de Stack. Aunque el Stack sea .NET, es posible que la versión de .NET no coincida con la 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 la versión de .NET que 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 a través de [WEBSITE\_RUN\_FROM\_PACKAGE ](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/basics#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 funcionaba el 2024-11-27 y dejó de funcionar por completo desde el 2024-12-16 después de haber funcionado sin problemas durante muchos años Estamos desmantelando el repositorio obsoleto de artefactos de SCEPman después de más de tres años de mover los artefactos a la nueva ubicación . El miércoles 2024-11-27, deshabilitamos temporalmente la ubicación antigua para advertir a los usuarios sobre el cierre permanente el lunes 2024-12-16. Si te ves afectado, revisa tu configuración WEBSITE\_RUN\_FROM\_PACKAGE y [actualiza el valor](https://docs.scepman.com/es/configuracion-de-scepman/application-artifacts) 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](https://docs.scepman.com/es/changelog) con compatibilidad total con versiones anteriores. Si no estás seguro de si estás usando el repositorio más reciente, visita la página de inicio de SCEPman. Si sigue configurado en el repositorio antiguo, mostrará una advertencia (y lo ha hecho durante los últimos tres años) que se ve así:

SCEPman usa 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 error El perfil SCEP generará un error si la implementación del certificado no fue exitosa. 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. Luego, haz clic en **Microsoft** 4. Después, 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: Falló el registro del certificado. 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\).png?alt=media) Si estás usando una CA intermedia, ten en cuenta que debes [seleccionar el certificado de la CA intermedia](https://docs.scepman.com/es/implementacion-de-scepman/intermediate-certificate#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 OCSP {% hint style="info" %} Esto es solo un problema anterior a la versión 1.2 {% endhint %} Si el certificado del dispositivo tiene una URL localhost para la entrada 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) El App Service no tiene una configuración importante de la aplicación con el nombre **AppConfig:BaseUrl** establecido en la URL de azurewebsite. Para solucionar esto, añade la variable y guarda la configuración del App Service: ``` AppConfig:BaseUrl https://scepman-XXXXX.azurewebsites.net ``` Elimina este certificado del dispositivo y haz la sincronización MDM. Si lo haces, verás una URL correcta para la entrada 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 raíz de confianza. Asigna ambos perfiles al mismo grupo de usuario o dispositivo de Azure Active Directory para asegurarte de que el usuario o dispositivo se superponga y que ambos perfiles se dirijan al dispositivo. No mezcles grupos de usuario y de dispositivo. Si ves pendiente como estado de los perfiles de configuración en Intune durante mucho tiempo, probablemente la asignación sea incorrecta. ### Algunas máquinas Windows no registran ni renuevan certificados Puedes comprobarlo tanto del lado de SCEPman como del lado del cliente. Dependiendo del problema, que a menudo no conoces de antemano, la causa raíz solo se muestra 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 registro 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 con 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: Falló el registro del certificado. Resultado: (Código de error Win32 desconocido: 0x80072f8f). TimeCreated : 7/2/2025 12:51:06 PM ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider Id : 307 Message : SCEP: Falló LogError Message : (SCEPInstallCertificateWithScepHelper:No se pudo inicializar Registro SCEP con 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 con Windows 10 no pueden registrarse con AutoPilot Actualmente, algunos dispositivos con 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 *aún no* válidos. Windows entonces descarta estos certificados "no válidos" y muestra un error. Los certificados se emiten de forma predeterminada con 10 minutos de anticipación para abordar problemas menores de reloj, pero recientemente hemos visto dispositivos con Windows 10 que tienen hasta 9 horas de desfase. Puedes continuar con el registro y, una vez finalizado, el dispositivo obtendrá un certificado correctamente, ya que entonces el reloj será correcto. También puedes usar la nueva opción [**AppConfig:ValidityClockSkewMinutes**](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/certificates#appconfig-validityclockskewminutes) para retroceder la fecha de los certificados más de 10 minutos. Usa 1440 minutos para retroceder la fecha de los certificados durante un día completo. Este será el valor predeterminado para las 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 está atrasado; ver [Los dispositivos con Windows 10 no pueden registrarse con AutoPilot](#windows-10-devices-cannot-enroll-with-autopilot). ## Problemas con la validez de los certificados ### Comprobar certificado local #### Máquina Windows Primero, debes comprobar la validez del certificado del dispositivo. Para ello, abre una ventana de comandos como administrador y escribe el siguiente comando: ``` certutil -verifyStore MY ``` Mira 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 funciona, puedes ver la caché de 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\).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 deseas 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 certificado de autenticación de cliente en la propiedad **Acceso a la información de autoridad** (AIA):
4. Abre una sesión de **Terminal** 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\).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 múltiples opciones según [#appconfig-intunevalidation-devicedirectory](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory "mention"): 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 activar una acción remota (varios estados de administración como "WipePending" revocan automáticamente los certificados, como se indica en [#appconfig-intunevalidation-revokecertificatesonwipe](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-revokecertificatesonwipe "mention")). 3. **Ambos directorios**: Ejecutar acciones para Microsoft Entra ID (Azure AD) **y** Intune, como se describe. {% hint style="info" %} Para obtener más detalles sobre los directorios de dispositivos, lee el artículo [device-directories](https://docs.scepman.com/es/configuracion-de-scepman/device-directories "mention"). {% endhint %} El siguiente ejemplo revoca un certificado de dispositivo a través de Microsoft Entra ID (Azure AD): 1. Navega a **Dispositivos - Todos los dispositivos** en tu Microsoft Entra ID (Azure AD) 2. Elige un dispositivo 3. Haz clic en **Deshabilitar** A continuación, escribe de nuevo 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 vuelvas a habilitar el dispositivo en Microsoft Entra ID (Azure AD) y escribas de nuevo 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 %} ### Access Point no puede verificar un certificado de autenticación que SCEPman ha emitido *Síntomas*: Cisco ISE muestra un error de OCSP no accesible. Aruba ClearPass también tiene este problema. El servidor, aparentemente SCEPman, responde con un paquete TCP reset 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 puede 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í](https://docs.scepman.com/es/otros/troubleshooting/cisco-ise-host-header-limitation). ### 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 modo compartido de Microsoft Entra ID (Azure AD) para el método de registro de dispositivos dedicados propiedad de la empresa en lugar del modo predeterminado. Si usas el modo predeterminado para los tipos de token `dispositivo dedicado propiedad de la empresa`, no te afectará el problema. Intune seguirá poniendo el ID de dispositivo de Intune en el certificado en lugar del ID de dispositivo de AAD, pero serán el mismo para el modo predeterminado, así que no importa. Para cambiar el modo de registro, ve a la [configuración de registro 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 propiedad de la empresa (predeterminado)` en lugar de `dispositivo dedicado propiedad de la empresa 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 tú también te ves afectado. ### Mi cuenta de almacenamiento dice que no está conectada Si la página principal de SCEPman muestra una etiqueta roja "Not Connected" para la conectividad de la cuenta de almacenamiento, es posible que la identidad administrada del App Service de SCEPman (y posiblemente la de SCEPman Certificate Master) no tenga permisos en la cuenta de almacenamiento. En este caso, SCEPman no puede comprobar si un certificado ha sido revocado manualmente y, por lo tanto, no puede responder a solicitudes OCSP. Esto suele ocurrir si mueves la cuenta de almacenamiento 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 ya existía antes, pero la Community Edition no lo comprobaba. Para solucionarlo, debes conceder a la identidad administrada del App Service de SCEPman y a la de SCEPman Certificate Master el rol "Storage Table Data Contributor" en la cuenta de almacenamiento. Las asignaciones de roles se pueden hacer manualmente en el Portal de Azure, en "Control de acceso (IAM)" de la cuenta de almacenamiento. Como alternativa, simplemente [vuelve a ejecutar el cmdlet de instalación de SCEPman desde el módulo de PowerShell de SCEPman](https://docs.scepman.com/es/implementacion-de-scepman/permissions/post-installation-config#running-the-scepman-installation-cmdlet). ## SCEPman no emitirá certificados con EKU distintos de Autenticación de cliente Revisa las variables de entorno de SCEPman para ver qué está configurado para [AppConfig:UseRequestedKeyUsages](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/certificates#appconfig-userequestedkeyusages). Si no está configurado, el valor predeterminado es "false". Las nuevas instalaciones lo configurarán automáticamente en "true"; sin embargo, las instalaciones antiguas de SCEPman lo tienen configurado como false. Las actualizaciones de SCEPman no cambian ningún comportamiento, salvo correcciones o cambios que en ningún caso tienen una desventaja. Cuando esto está configurado como false, se ignoran los EKU y usos de clave solicitados.