Problemas comunes
Problemas al iniciar SCEPman
Desplegué 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 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 incorrecta de .NET
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 puede 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 esta 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 completamente desde 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 de mover 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 sobre el cierre permanente el lunes 2024-12-16.
Si se ve 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 plena compatibilidad hacia atrás.
Si no está seguro de si está usando el repositorio más reciente, visite la página de inicio de su SCEPman. Si todavía está configurado 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 mediante perfil SCEP resulta en un error
El perfil SCEP dará lugar a un error si el despliegue del certificado no fue exitoso. 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:
Abra la aplicación Eventos de Windows
Haga clic en 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 de hash no es correcto.).
Si está utilizando una CA intermedia, tenga en cuenta que tiene que 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
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 sincronice con MDM. Si lo hizo verá una URL correcta para la entrada OCSP:
Mi perfil de configuración SCEP aparece como 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 coincida y ambos perfiles estén dirigidos al dispositivo. No mezcle grupos de usuarios y de dispositivos. Si ve estado pendiente para los perfiles de configuración en Intune durante mucho tiempo, probablemente la asignación es incorrecta.
Algunas máquinas Windows no se inscriben ni renuevan certificados
Puede comprobar ambos lados: desde SCEPman y desde el cliente. Dependiendo del problema, que a menudo no conoce de antemano, la causa raíz se muestra en solo uno de los dos lados.
Compruebe si hay algún [ERROR] entrada en los registros de SCEPman. Posiblemente también busque el término de búsqueda [WARN, pero esto puede producir 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 que le ayuda a localizar problemas de inscripción en el lado del cliente.
El cliente SCEP de Windows solo soporta TLS hasta la versión 1.2. Configurar la versión TLS entrante mínima a 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:
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. Los certificados se emiten 10 minutos en el pasado por defecto para abordar problemas menores de reloj, pero últimamente hemos visto dispositivos Windows 10 con hasta 9 horas de retraso.
Puede continuar con la inscripción y una vez finalizada, el dispositivo obtendrá un certificado con éxito, ya que entonces la hora será correcta. 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 solucionar 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 cuya hora está atrasada, 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 (vea la última línea).
Para verificar que el respondededor OCSP está funcionando, puede mirar 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 de 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 respondededor OCSP de la propiedad Authority Information Access (AIA) del certificado de autenticación de cliente:
Abra una sesión de Terminal 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 certificado de usuario tiene dos opciones:
Eliminar al usuario de Microsoft Entra ID (Azure AD) o
Bloquear el 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 desencadenar una acción remota (varios estados de administración como "WipePending" revocan automáticamente certificados como se indica en AppConfig:IntuneValidation:RevokeCertificatesOnWipe).
Ambos directorios: Ejecutar acciones para Microsoft Entra ID (Azure AD) y Intune como se describió.
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 en Deshabilitar
A continuación, escriba de nuevo el siguiente comando:
Como puede ver en la última línea, el Certificado está REVOCADO
Cuando vuelva a habilitar el dispositivo en Microsoft Entra ID (Azure AD) y vuelva a ejecutar el comando anterior, el certificado debería aparecer marcado como válido.
Punto de acceso no puede verificar un certificado de autenticación emitido por SCEPman
Síntomas: Cisco ISE muestra un error de OCSP inalcanzable. Aruba ClearPass también presenta este problema. El servidor, aparentemente SCEPman, responde con un paquete TCP reset a la petición OCSP.
Causa: Tanto Cisco ISE como Aruba ClearPass no soportan HTTP 1.1 al buscar OCSP y no envían una cabecera Host en su petición 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 accidentalmente pone 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. SCEPman entonces no puede encontrar un dispositivo con este ID en AAD y por lo tanto considera el certificado revocado.
Esto ocurre solo cuando usa el modo compartido de Microsoft Entra ID (Azure AD) para el método de inscripción para dispositivos dedicados de propiedad corporativa en lugar del modo predeterminado. Si usa el modo predeterminado para tipos de token Dispositivo dedicado de propiedad corporativa, no se verá afectado por el problema. Intune aún pondrá 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 la configuración de inscripción de Android del centro de administración de Microsoft Endpoint Manager y elija Dispositivo dedicado de propiedad corporativa (predeterminado) en lugar de Dispositivo dedicado de propiedad corporativa 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 se ve 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, posiblemente la identidad administrada del App Service de SCEPman (y posiblemente la de SCEPman Certificate Master) carece de permisos en la cuenta de almacenamiento. En este caso, SCEPman no puede comprobar si un certificado está revocado manualmente y por lo tanto no puede responder a peticiones OCSP. Esto generalmente 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 la edición Enterprise: en ese caso, el problema de permisos ya existía antes, pero la edición Community no lo comprobaba.
Para solucionarlo, debe 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 de nuevo el cmdlet de instalación de SCEPman desde el módulo PowerShell de SCEPman.
SCEPman no emitirá certificados con EKUs distintos de Autenticación de cliente
Compruebe sus variables de entorno de SCEPman para ver qué está configurado para AppConfig:UseRequestedKeyUsages. Si no está definido, por defecto es "false".
Las nuevas instalaciones configurarán esto automáticamente en "true", sin embargo las instalaciones antiguas de SCEPman lo tienen establecido como false. Las actualizaciones de SCEPman no cambian ningún comportamiento excepto por correcciones o cambios que bajo ninguna circunstancia sean una desventaja. Cuando esto está establecido en false, los EKU solicitados y los usos de clave se ignoran.
Última actualización
¿Te fue útil?