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).
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.
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 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 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 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í:
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:
Abra la aplicación Eventos de Windows
Haga clic Registros de aplicaciones y servicios
A continuación, haga clic Microsoft
Luego, haga clic Windows
Desplácese hacia abajo y busque DeviceManagement-Enterprise-Diagnostics-Provider y haga clic en él.
En la ventana que aparecerá, haga clic Admin
Desplácese por la lista y busque el ID de evento 32
Contiene un breve informe de error
SCEP: Error en la inscripción del certificado. Resultado (El valor hash no es correcto.).
Si está usando una CA intermedia, tenga en cuenta que debe seleccionar el certificado de la CA intermedia 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
Esto es solo un problema antes de la versión 1.2
Si el certificado del dispositivo tiene una URL localhost para la entrada OCSP en el certificado como esta:
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:
Elimine este certificado del dispositivo y haga la sincronización MDM. Si lo hizo verá una URL adecuada para la entrada OCSP:
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 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:
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 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.
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:
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).
Para verificar que el respondedoor OCSP está funcionando, puede ver la caché de URL OCSP con el siguiente comando:
Máquina macOS
Para comprobar la validez de un certificado en una máquina macOS usando OCSP, siga estos pasos:
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).
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.
Extraiga la URL del respondedoor OCSP de la propiedad Authority Information Access (AIA) del certificado de autenticación del cliente:
Abra una Terminal sesión y
cda la carpeta que contiene los certificados exportados.Ejecute el siguiente comando:
Hacia el final de la respuesta, se muestra el estado de revocación:\
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:
Revocar un usuario
Si desea revocar un usuario certificado, tiene dos opciones:
Eliminar el usuario de Microsoft Entra ID (Azure AD) o
Bloquear inicio de sesión para el usuario
Si desea revocar un dispositivo certificado, tiene múltiples opciones dependiendo de AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD): Eliminar o deshabilitar el dispositivo (Portal de Microsoft Entra ID (Azure AD): "Dispositivos" - "Todos los dispositivos").
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).
Ambos directorios: Ejecutar acciones para Microsoft Entra ID (Azure AD) y Intune según lo descrito.
Para más detalles sobre directorios de dispositivos, por favor lea el artículo Directorios de dispositivos.
El siguiente ejemplo revoca un certificado de dispositivo vía Microsoft Entra ID (Azure AD):
Navegue a Dispositivos - Todos los dispositivos en su Microsoft Entra ID (Azure AD)
Elija un dispositivo
Haga clic Deshabilitar
A continuación, escriba de nuevo el siguiente comando:
Como puede ver en la última línea, el Certificado está REVOCADO
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.
Puede tardar hasta 5 minutos antes de que aparezca el mensaje 'Marcado como válido'.
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í:
Solución: Por favor vea aquí.
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 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 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.
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. Si no está establecido, por defecto es "false".
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.
Última actualización
¿Te fue útil?