> 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/general.md).

# Problemas comunes

## Problemas al iniciar SCEPman

### Implementé SCEPman desde GitHub y solía funcionar, pero ahora la Web App ya no inicia

Si el error es '503 Cannot download ZIP', entonces la web app 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 (véase [Configuración de la aplicación](/es/configuracion-de-scepman/application-artifacts.md#change-artifacts)).

La URL *<https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip>* 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 de SCEPman no está en ejecución

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 sea .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 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 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é 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 2024-12-16, después de haber estado funcionando 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 los artefactos a la nueva ubicación <https://github.com/scepman/install>. El miércoles 2024-11-27 deshabilitamos temporalmente la ubicación antigua para informar a los usuarios del cierre permanente el lunes 2024-12-16.

Si te ves afectado, revisa tu configuración 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 última versión, proporcionando [muchas mejoras](/es/changelog.md) con compatibilidad total 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 todavía está configurado en el repositorio antiguo, muestra 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&amp;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>SCEPman usando la ubicación antigua del paquete para WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## 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 dará como resultado un error si la implementación del certificado no tuvo éxito. Los errores pueden tener varias razones:

### El perfil de certificado SCEP está configurado con un error

Esto puede 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 Visor 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: Error en 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\)%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 de URL de OCSP correcta

{% 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 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** establecida en la URL de azurewebsite. Para corregirlo, 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 realiza la sincronización de MDM. Si lo has hecho, verás una URL correcta 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 Trusted Root. Asigna ambos perfiles al mismo grupo de usuarios o dispositivos de Azure Active Directory para asegurarte de que el usuario o dispositivo coincida y ambos perfiles estén dirigidos al dispositivo. No mezcles grupos de usuarios y de dispositivos. Si ves 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 comprobarlo tanto desde el lado de SCEPman como desde el 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 algún `[ERROR]` entrada en los registros de SCEPman. También puedes buscar posiblemente 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 concretas 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: Error en 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: Fallo LogError Message : (SCEPInstallCertificateWithScepHelper:Error al inicializar
               Inscripción 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 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 reloj. Esto causa un problema con los certificados emitidos recientemente, ya que *aún no* son válidos. Windows luego descarta estos certificados "no válidos" y muestra un error. De forma predeterminada, los certificados se emiten con 10 minutos de retraso para abordar 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 que termine, el dispositivo obtendrá un certificado correctamente, ya que entonces la hora será correcta. También puedes usar la nueva opción [**AppConfig:ValidityClockSkewMinutes**](/es/configuracion-de-scepman/application-settings/certificates.md#appconfig-validityclockskewminutes) para atrasar certificados más de 10 minutos. Usa 1440 minutos para atrasar los certificados un día completo. Este será el valor predeterminado para nuevas instalaciones de SCEPman para abordar este problema.

### Emití un certificado hoy, pero la fecha de emisión indica que fue ayer

Esto se debe a que SCEPman retrasa el certificado un día para contrarrestar problemas con dispositivos cuyo reloj está atrasado; consulta [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 comprobar la validez del certificado del dispositivo. Para ello, abre un símbolo del sistema como administrador y escribe el siguiente comando:

```
certutil -verifyStore MY
```

Mira el certificado con el ID de dispositivo emitido por el SCEPman-Device-Root-CA-V1 y verifica si el certificado es válido (consulta 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 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 de la CA raíz de SCEPman 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 información de autoridad** propiedad (AIA):

   <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&amp;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. Abre una **Terminal** sesión y `cd` al directorio que contiene los certificados exportados.
5. Ejecuta el siguiente comando:

```
openssl ocsp -issuer <filename-scepman-root-ca-certificate> -cert <filename-certificate-to-be-verified> -text -url <ocsp-responder-url>
```

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&amp;token=ee8e2761-e249-4bd1-ae82-0eac933363d2" alt=""><figcaption></figcaption></figure>

### Comprueba 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 usuario de certutil para la comprobación OCSP:

```
certutil -url <path-to-exported-device-certificate>
```

![](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 múltiples opciones según [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/): "Devices" - "All devices").
2. **Intune**: Elimina el dispositivo o activa 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**: Ejecuta acciones para Microsoft Entra ID (Azure AD) **y** en 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 mediante 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, vuelve a escribir el siguiente comando:

```
certutil -verifyStore MY
```

Como puedes ver en la última línea, el **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 en aparecer el mensaje 'Marked as valid'.
{% 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 no accesible. Aruba ClearPass también tiene este problema. El servidor, aparentemente SCEPman, responde con un paquete de restablecimiento TCP a la solicitud OCSP.

*Causa*: Tanto Cisco ISE como Aruba ClearPass no admiten HTTP 1.1 al buscar OCSP y no envían un encabezado de host en su solicitud OCSP. Por lo tanto, no pueden conectarse a una instancia general de SCEPman que se ejecuta 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í](/es/otro/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 coloca 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 revocado el certificado.

Esto ocurre solo cuando utilizas el modo compartido de Microsoft Entra ID (Azure AD) para el método de inscripción de dispositivos dedicados propiedad de la empresa en lugar del modo predeterminado. Si usas el modo predeterminado para tipos de token `Dispositivo dedicado de propiedad corporativa`, no te verá afectado por 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, así que no importa. Para cambiar el modo de inscripción, ve a la [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) sobre 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 indica que no está conectada

Si la página de inicio de SCEPman muestra una etiqueta roja "Not Connected" para la conectividad de Storage Account, posiblemente a la Identidad administrada del App Service de SCEPman (y posiblemente también a la de SCEPman Certificate Master) le falten permisos en el Storage Account. 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 el Storage Account a otra suscripción o grupo de recursos. También puede ocurrir después de actualizar una versión de 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 a la de SCEPman Certificate Master el rol "Storage Table Data Contributor" en el Storage Account. Las asignaciones de roles se pueden hacer manualmente en el Azure Portal en "Access Control (IAM)" dentro del Storage Account. Como alternativa, simplemente [vuelve a ejecutar el CMDlet de instalación de SCEPman desde el módulo de 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 Client Authentication

Comprueba tus 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á configurado, el valor predeterminado es "false".

Las nuevas instalaciones lo establecerá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 no tengan en ningún caso una desventaja. Cuando esto se establece en false, los EKUs y Key Usages solicitados se ignoran.<br>


---

# 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/general.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.
