# Problemas comunes

## Problemas al iniciar SCEPman

### Desplegué SCEPman desde GitHub y solía funcionar, 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 configuració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 *<https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip>* que habíamos recomendado para despliegues desde 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 soportan redirecciones junto con WEBSITE\_RUN\_FROM\_PACKAGE. Por lo tanto, necesita cambiar la URL a `https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip`.

### La Web App de SCEPman en Azure no se está ejecutando

Compruebe si el recurso de Azure está activo y en ejecución.

![](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 de .NET incorrecta

En el recurso App Service de SCEPman o Certificate Master, puede comprobar qué Stack y versión están configurados para ese App Service en Configuración -> Configuración -> Configuración general -> Configuración del stack. Aunque el Stack sea .NET, la versión de .NET podría no coincidir con la que espera para su versión de SCEPman, p. ej. .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 seleccione en la configuración. Solo actualizamos SCEPman a una nueva versión de .NET cuando esa versión está incluida en este conjunto de versiones de .NET instaladas automáticamente. Hacemos esto porque nuestro mecanismo de actualización vía [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é esté configurado como versión de .NET.

### Mi App Service de SCEPman no funcionó 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 cerrando el repositorio de artefactos obsoleto de SCEPman <https://github.com/glueckkanja/gk-scepman> después de más de tres años trasladando artefactos a la nueva ubicación <https://github.com/scepman/install>. El miércoles 2024-11-27, deshabilitamos temporalmente la ubicación antigua para hacer a los usuarios conscientes del cierre permanente el lunes 2024-12-16.

Si está afectado, compruebe su configuración WEBSITE\_RUN\_FROM\_PACKAGE y [actualice el valor](https://docs.scepman.com/es/configuracion-de-scepman/application-artifacts) a la nueva ubicación del paquete. Esto también actualizará su versión de SCEPman de 1.8 a la versión más reciente, otorgando [muchas mejoras](https://docs.scepman.com/es/changelog) con compatibilidad completa hacia atrás.

Si no está seguro de si está usando el repositorio más reciente, visite la página de inicio de SCEPman. Si todavía está configurada en el repositorio antiguo, mostrará una advertencia (y lo ha hecho durante los últimos tres años) que se ve así:

<figure><img src="https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FbX4ATqv8O0f3cXCdqwLy%2Fimage.png?alt=media&#x26;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>SCEPman usando la ubicación de paquete antigua para WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## Problemas al emitir certificados

### El certificado raíz de confianza está desplegado pero mi certificado de dispositivo vía perfil SCEP resulta en un error

El perfil SCEP producirá un error si el despliegue del certificado no fue exitoso. Los errores pueden tener varias causas:

### 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. Abra la aplicación Eventos de Windows
2. Haga clic **Registros de aplicaciones y servicios**
3. A continuación, haga clic **Microsoft**
4. Luego, haga clic **Windows**
5. Desplácese hacia abajo y busque **DeviceManagement-Enterprise-Diagnostics-Provider** y haga clic en él.
6. En la ventana que aparecerá, haga clic **Admin**
7. Desplácese por la lista y busque el ID de evento **32**
8. Contiene un breve informe de error
   * SCEP: Error en la inscripción 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á usando una CA intermedia, tenga en cuenta que debe [seleccionar el certificado de la CA intermedia](https://docs.scepman.com/es/despliegue-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. Tenga 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 OCSP URL correcta

{% hint style="info" %}
Esto es solo un problema antes de 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)

Al App Service le falta una configuración de aplicación importante con el nombre **AppConfig:BaseUrl** establecida en la URL azurewebsite. Para solucionar esto, agregue la variable y guarde la configuración del App Service:

```
AppConfig:BaseUrl
https://scepman-XXXXX.azurewebsites.net
```

Elimine este certificado del dispositivo y haga la sincronización MDM. Si lo hizo verá una URL adecuada 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 raíz de confianza. Asigne ambos perfiles al mismo grupo de usuarios o dispositivos de Azure Active Directory para asegurarse de que el usuario o dispositivo se solapen y ambos perfiles se dirijan al dispositivo. No mezcle grupos de usuario y de dispositivo. Si ve 'pendiente' como estado 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

Puede comprobar ambos lados, el de SCEPman y el del cliente. Dependiendo del problema, que a menudo no conoce de antemano, la causa raíz se mostrará solo en uno de los dos lados.

Compruebe si hay algún `[ERROR]` registro en los logs de SCEPman. Posiblemente también busque el término de búsqueda `[WARN`, pero esto puede producir 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 le 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 TLS entrante mínima en 1.3 en el App Service de SCEPman causa 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ó la inscripción 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:Failed to Initialize
               Inscripción SCEP con servidor NDES
               'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', huella del certificado de la CA
               '24C45EF4284A5093A9C3886A6466C1D6D84EE058' y certificados del servidor ''. LogError 0x80)
```

{% endcode %}

### Los dispositivos con Windows 10 no pueden inscribirse 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 reloj. Esto causa un problema con los certificados recién emitidos, ya que están *aún no* válidos. Windows entonces descarta estos certificados "inválidos" y muestra un error. Por defecto, los certificados se emiten con 10 minutos de antelación para abordar pequeños desajustes de reloj, pero recientemente hemos visto dispositivos con Windows 10 que tienen hasta 9 horas de retraso.

Puede continuar con la inscripción y una vez finalizada, el dispositivo obtendrá un certificado con éxito, ya que la hora será correcta entonces. También puede 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. Use 1440 minutos para retroceder los certificados por un día completo. Esto será el valor predeterminado 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 está atrasado, vea [Los dispositivos con 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, necesita comprobar la validez del certificado del dispositivo. Para ello, abra un símbolo del sistema como administrador y escriba el siguiente comando:

```
certutil -verifyStore MY
```

Busque el certificado con el ID del dispositivo emitido por SCEPman-Device-Root-CA-V1 y verifique si el certificado es válido (ver ú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 respondedoor OCSP está funcionando, puede 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, siga estos pasos:

1. Exporte el certificado Root CA de SCEPman desde **Acceso a Llaveros** (**Llaveros del sistema > Raíces del sistema**) como archivo \*.cer y colóquelo en una carpeta (alternativamente, puede descargarlo desde el sitio web de su instancia SCEPman).
2. Exporte el certificado de autenticación del cliente que desea verificar desde **Acceso a Llaveros** (**Llaveros del sistema > Sistema > Mis certificados**) como archivo \*.cer en la misma carpeta.
3. Extraiga la URL del respondedoor OCSP de la propiedad **Authority Information Access** (AIA) del certificado de autenticación del cliente:

   <figure><img src="https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FaJqT97xxEUx1py2f0xbT%2Fimage.png?alt=media&#x26;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. Abra una **Terminal** sesión y `cd` a la carpeta que contiene los certificados exportados.
5. Ejecute el siguiente comando:

```
openssl ocsp -issuer <archivo-certificado-root-ca-scepman> -cert <archivo-certificado-a-verificar> -text -url <url-respondedor-ocsp>
```

6. Hacia el final de la respuesta, se muestra el estado de revocación:\\

   <figure><img src="https://4115997120-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FRXQI4xRp0NRt5vBwDY89%2Fimage.png?alt=media&#x26;token=ee8e2761-e249-4bd1-ae82-0eac933363d2" alt=""><figcaption></figcaption></figure>

### Comprobar certificados desde otras máquinas

Como alternativa puede exportar el certificado del dispositivo y usar `certutil` en una máquina Windows para mostrar una pequeña interfaz certutil para la comprobación OCSP:

```
certutil -url <ruta-al-certificado-del-dispositivo-exportado>
```

![](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 desea revocar un **usuario** certificado, tiene dos opciones:

1. Eliminar el usuario de Microsoft Entra ID (Azure AD) o
2. Bloquear inicio de sesión para el usuario

Si desea revocar un **dispositivo** certificado, tiene múltiples opciones dependiendo de [#appconfig-intunevalidation-devicedirectory](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/endpoints-scep/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 gestión como "WipePending" revocan certificados automáticamente como se indica en [#appconfig-intunevalidation-revokecertificatesonwipe](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/endpoints-scep/intune-validation#appconfig-intunevalidation-revokecertificatesonwipe "mention")).
3. **Ambos directorios**: Ejecutar acciones para Microsoft Entra ID (Azure AD) **y** Intune según lo descrito.

{% hint style="info" %}
Para más detalles sobre directorios de dispositivos, por favor lea 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 vía Microsoft Entra ID (Azure AD):

1. Navegue a **Dispositivos - Todos los dispositivos** en su Microsoft Entra ID (Azure AD)
2. Elija un dispositivo
3. Haga clic **Deshabilitar**

A continuación, escriba de nuevo el siguiente comando:

```
certutil -verifyStore MY
```

Como puede 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 habilite el dispositivo de nuevo en Microsoft Entra ID (Azure AD) y escriba de nuevo el comando anterior, el certificado debería aparecer marcado como válido.

{% hint style="info" %}
Puede tardar hasta 5 minutos antes de que aparezca el mensaje 'Marcado como válido'.
{% endhint %}

### El punto de acceso no puede verificar un certificado de autenticación que SCEPman ha emitido

*Síntomas*: Cisco ISE muestra un error de OCSP inalcanzable. 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 soportan 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*: Por favor vea [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 pone accidentalmente el ID de dispositivo de Intune en el certificado en lugar del ID de dispositivo de AAD en casos aleatorios, aunque configure la variable en el perfil de configuración SCEP. Entonces SCEPman no puede encontrar un dispositivo con ese ID en AAD y por lo tanto considera el certificado revocado.

Esto ocurre solo cuando utiliza el modo compartido de Microsoft Entra ID (Azure AD) para el método de inscripción para dispositivos dedicados corporativos en lugar del modo predeterminado. Si usa el modo predeterminado para tipos de token `Dispositivo corporativo dedicado`, no se verá afectado por 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 iguales en el modo predeterminado, por lo que no importa. Para cambiar el modo de inscripción, vaya a [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 elija `Dispositivo corporativo dedicado (predeterminado)` en lugar de `Dispositivo corporativo dedicado con modo compartido de Azure AD`. Por favor consulte la [documentación de Microsoft](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) para las implicaciones de esta selección.

Actualmente estamos trabajando con Microsoft para resolver este problema en todas las configuraciones. Por favor contacte con nuestro soporte si también está afectado.

### Mi cuenta de almacenamiento dice que no está conectada

Si la página de inicio de SCEPman muestra una etiqueta roja "Not Connected" para la conectividad de la cuenta de almacenamiento, posiblemente la identidad administrada del App Service de SCEPman (y posiblemente la de SCEPman Certificate Master) no tiene 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 normalmente ocurre si mueve la cuenta de almacenamiento a otra suscripción o grupo de recursos. También puede ocurrir después de actualizar una edición Community a Enterprise: en ese caso, el problema de permisos existía antes, pero la edición Community no lo comprobaba.

Para solucionar esto, necesita otorgar 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 rol se pueden hacer manualmente en el Portal de Azure bajo "Control de acceso (IAM)" en la cuenta de almacenamiento. Alternativamente, simplemente [ejecute el CMDlet de instalación de SCEPman del módulo de PowerShell de SCEPman una vez más](https://docs.scepman.com/es/despliegue-de-scepman/permissions/post-installation-config#running-the-scepman-installation-cmdlet).

## SCEPman no emitirá certificados con EKU distintos a Autenticación de Cliente

Compruebe sus variables de entorno de SCEPman para ver qué está configurado en [AppConfig:UseRequestedKeyUsages](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/certificates#appconfig-userequestedkeyusages). Si no está establecido, por defecto es "false".&#x20;

Las nuevas instalaciones establecerán esto 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 excepto por correcciones o cambios que en ningún caso supongan una desventaja. Cuando esto está en false, los EKU y usos de clave solicitados en las peticiones son ignorados.<br>
