Problemas comuns
Problemas ao iniciar o SCEPman
Implementei o SCEPman a partir do GitHub e ele costumava funcionar, mas agora a Web App já não inicia.
Se o erro for '503 Cannot download ZIP', então a web app não consegue descarregar o ZIP com os binários da aplicação a partir do URL configurado na definição da aplicação WEBSITE_RUN_FROM_PACKAGE (ver Configuração da aplicação).
O URL https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip que recomendámos para implementações no GitHub em versões anteriores desta documentação redireciona para outro URL. A Microsoft alterou o comportamento de algumas das suas Web Apps e agora algumas versões não suportam redirecionamentos em conjunto com WEBSITE_RUN_FROM_PACKAGE. Assim, é necessário alterar o URL para https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.
O SCEPman Azure Web App não está em execução
Verifique se o recurso Azure está em funcionamento.
O meu App Service usa a versão errada do .NET
No recurso App Service do SCEPman ou do Certificate Master, pode verificar qual Stack e versão estão configurados para esse App Service em Settings -> Configuration -> General settings -> Stack settings. Embora a Stack seja .NET, a versão do .NET pode não corresponder ao que espera para a sua versão do SCEPman, por exemplo, .NET 8 para SCEPman 2.8.
Isto acontece porque algumas versões comuns do .NET estão automaticamente disponíveis em todos os Windows App Services, independentemente da versão do .NET que selecionar nas definições. Só atualizamos o SCEPman para uma nova versão do .NET quando essa versão está incluída neste conjunto de versões do .NET instaladas automaticamente. Fazemos isso porque o nosso mecanismo de atualização via WEBSITE_RUN_FROM_PACKAGE não nos dá qualquer controlo sobre a definição da versão do .NET. Portanto, na realidade, não importa o que está configurado como versão do .NET.
O meu SCEPman App Service não funcionou em 2024-11-27 e deixou de funcionar completamente desde 2024-12-16, depois de ter funcionado sem problemas durante muitos anos
Estamos a encerrar o repositório de artefactos descontinuado do SCEPman https://github.com/glueckkanja/gk-scepman após mais de três anos a mover artefactos para o novo local https://github.com/scepman/install. Na quarta-feira, 2024-11-27, desativámos temporariamente o local antigo para alertar os utilizadores para o encerramento permanente na segunda-feira, 2024-12-16.
Se for afetado, verifique a sua definição WEBSITE_RUN_FROM_PACKAGE e atualize o valor para o novo local do pacote. Isto também atualizará a sua versão do SCEPman de 1.8 para a versão mais recente, proporcionando muitas melhorias com total compatibilidade retroativa.
Se não tiver a certeza de que está a usar o repositório mais recente, visite a página inicial do seu SCEPman. Se ainda estiver configurado no repositório antigo, está a apresentar um aviso (e já o faz há três anos) que se parece com isto:
Problemas ao emitir certificados
O Trusted Root Certificate está implementado, mas o meu Device Certificate via SCEP Profile resulta num erro
O perfil SCEP resultará num erro se a implementação do certificado não tiver sido bem-sucedida. Os erros podem ter várias razões:
O perfil de certificado SCEP está configurado com um erro
Isto pode acontecer quando foi selecionado o certificado raiz fidedigno errado no perfil de certificado SCEP. Isto também é mostrado no registo de eventos:
Abra a aplicação Eventos do Windows
Clique em Registos de Aplicações e Serviços
Em seguida, clique em Microsoft
Depois, clique em Windows
Desloque-se para baixo e procure DeviceManagement-Enterprise-Diagnostics-Provider e clique nele.
Na janela que aparecer, clique em Admin
Percorra a lista e procure o ID de evento 32
Contém um breve relatório de erro
SCEP: Falha no registo do certificado. Resultado (O valor hash não está correto.).
Se estiver a usar uma CA intermédia, note que tem de selecionar o certificado da CA intermédia e não o certificado Root CA no perfil de configuração SCEP! Note que isto é específico da plataforma Windows e, por exemplo, o Android exige selecionar o certificado Root CA no perfil de configuração SCEP.
O meu certificado não tem a entrada correta do URL OCSP
Se o certificado do dispositivo tiver um URL localhost para a entrada OCSP no certificado, como este:
O App Service não tem uma definição de aplicação importante com o nome AppConfig:BaseUrl definida para o URL azurewebsite. Para corrigir isto, adicione a variável e guarde a configuração do App Service:
Elimine este certificado do dispositivo e faça a sincronização MDM. Se o fizer, verá um URL correto para a entrada OCSP:
O meu perfil de configuração SCEP mostra pendente e não é aplicado
O perfil de configuração SCEP depende do perfil do certificado Trusted Root. Atribua ambos os perfis ao mesmo utilizador do Azure Active Directory ou grupo de dispositivos para garantir que o utilizador ou dispositivo se sobrepõe e que ambos os perfis têm como alvo o dispositivo. Não misture grupos de utilizadores e de dispositivos. Se vir o estado pending para os perfis de configuração no Intune durante muito tempo, a atribuição está provavelmente errada.
Algumas máquinas Windows não registam nem renovam certificados
Pode verificar ambos do lado do SCEPman e do lado do cliente. Dependendo do problema, que muitas vezes não conhece antecipadamente, a causa raiz é mostrada apenas num dos dois lados.
Verifique se existe algum [ERROR] entrada nos registos do SCEPman. Talvez também procure o termo [WARN, mas isto pode gerar alguns falsos positivos.
Oliver Kieselbach e Christoph Hannebauer escreveram um artigo de blogue sobre a análise de problemas de pedido ou renovação de certificados que o ajuda a identificar problemas de registo do lado do cliente.
O cliente SCEP do Windows suporta apenas TLS até à versão 1.2. Definir a versão mínima de TLS de entrada para 1.3 no SCEPman App Service causa entradas de erro específicas no DeviceManagement-Enterprise-Diagnostics-Provider registo de eventos. Aqui está um exemplo de uma máquina Windows 11:
Dispositivos Windows 10 não podem ser registados com AutoPilot
Atualmente, alguns dispositivos Windows 10 não têm a hora correta durante a experiência OOBE. Isto não é fácil de ver, uma vez que o ecrã não mostra relógio. Isto causa um problema com certificados recém-emitidos, uma vez que ainda não estão ainda não válidos. O Windows descarta então estes certificados "inválidos" e apresenta um erro. Os certificados são emitidos, por predefinição, com 10 minutos no passado para lidar com pequenos problemas de relógio, mas recentemente vimos dispositivos Windows 10 com um atraso de até 9 horas.
Pode prosseguir com o registo e, quando este terminar, o dispositivo obterá um certificado com sucesso, uma vez que o relógio estará então correto. Também pode usar a nova opção AppConfig:ValidityClockSkewMinutes para datar os certificados com mais de 10 minutos no passado. Use 1440 minutos para datar os certificados com um dia inteiro no passado. Este será o valor predefinido para novas instalações do SCEPman para resolver este problema.
Emiti um certificado hoje, mas a Data de Emissão diz que foi ontem
Isto acontece porque o SCEPman data o certificado um dia no passado para contrariar problemas com dispositivos cujo relógio está atrasado, ver Dispositivos Windows 10 não podem ser registados com AutoPilot.
Problemas com a validade dos certificados
Verificar certificado local
Máquina Windows
Primeiro, precisa de verificar a validade do certificado do dispositivo. Para isso, abra a linha de comandos como administrador e escreva o seguinte comando:
Observe o certificado com o ID do dispositivo emitido pela SCEPman-Device-Root-CA-V1 e verifique se o certificado é válido (ver última linha).
Para verificar se o respondedor OCSP está a funcionar, pode consultar a cache de URL OCSP com o seguinte comando:
Máquina macOS
Para verificar a validade de um certificado numa máquina macOS usando OCSP, siga estes passos:
Exporte o certificado SCEPman Root CA de Acesso às Chaves (Cadeias de Chaves do Sistema > Raízes do Sistema) como ficheiro *.cer e coloque-o numa pasta (em alternativa, pode transferi-lo a partir do site da sua instância SCEPman).
Exporte o certificado de autenticação do cliente que pretende verificar de Acesso às Chaves (Cadeias de Chaves do Sistema > Sistema > Os Meus Certificados) como ficheiro *.cer para a mesma pasta.
Extraia o URL do respondedor OCSP do Acesso à Informação de Autoridade (AIA) propriedade:
Abra uma Terminal sessão e
cdpara a pasta que contém os certificados exportados.Execute o seguinte comando:
Perto do fim da resposta, o estado de revogação é apresentado:\
Verifique certificados de outras máquinas
Como alternativa, pode exportar o certificado do dispositivo e usar certutil numa máquina Windows para apresentar uma pequena interface do certutil para a verificação OCSP:
Revogar um utilizador
Se quiser revogar um utilizador certificado, tem duas opções:
Eliminar o utilizador do Microsoft Entra ID (Azure AD) ou
Bloquear início de sessão para o utilizador
Se quiser revogar um dispositivo certificado, tem várias opções dependendo de AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD): eliminar ou desativar o dispositivo (Portal do Microsoft Entra ID (Azure AD): "Devices" - "All devices").
Intune: Elimine o dispositivo ou acione uma ação remota (vários estados de gestão, como "WipePending", revogam automaticamente certificados, conforme indicado em AppConfig:IntuneValidation:RevokeCertificatesOnWipe).
Ambos os diretórios: Executar ações para Microsoft Entra ID (Azure AD) e Intune, conforme descrito.
O exemplo seguinte revoga um certificado de dispositivo através do Microsoft Entra ID (Azure AD):
Navegue até Devices - All devices no seu Microsoft Entra ID (Azure AD)
Escolha um dispositivo
Clique em Desativar
Em seguida, escreva novamente o seguinte comando:
Como pode ver na última linha, o Certificado está REVOGADO
Quando voltar a ativar o dispositivo no Microsoft Entra ID (Azure AD) e escrever novamente o comando acima, o certificado deve ser marcado como válido.
O Access Point não consegue verificar um certificado de autenticação que o SCEPman emitiu
Sintomas: O Cisco ISE mostra um erro de OCSP inatingível. O Aruba ClearPass também tem este problema. O servidor, aparentemente SCEPman, responde ao pedido OCSP com um pacote TCP reset.
Causa: Tanto o Cisco ISE como o Aruba ClearPass não suportam HTTP 1.1 ao consultar o OCSP e não enviam um cabeçalho host no respetivo pedido OCSP. Portanto, não conseguem ligar-se a uma instância geral do SCEPman em execução em Azure App Services. A mensagem de erro pode parecer-se com isto:
Solução: Consulte aqui.
Os certificados de dispositivo nos meus sistemas Android (dedicados) não são válidos
Em sistemas Android (dedicados), o Intune ou o Android colocam acidentalmente o ID do dispositivo Intune no certificado em casos aleatórios, embora configure a variável no perfil de configuração SCEP. O SCEPman então não consegue encontrar um dispositivo com este ID no AAD e, por isso, considera o certificado revogado.
Isto acontece apenas quando usa o modo partilhado do Microsoft Entra ID (Azure AD) para o método de registo de dispositivos dedicados de propriedade da empresa, em vez do modo predefinido. Se usar o modo predefinido para tipos de token Dispositivo dedicado de propriedade da empresa, não será afetado por este problema. O Intune continuará a colocar o ID do dispositivo Intune no certificado em vez do ID do dispositivo AAD, mas serão iguais no modo predefinido, por isso não importa. Para alterar o modo de registo, vá para as definições de registo Android do centro de administração do Microsoft Endpoint Manager e escolha Dispositivo dedicado de propriedade da empresa (predefinição) em vez de Dispositivo dedicado de propriedade da empresa com modo partilhado do Azure AD. Consulte a documentação da Microsoft para conhecer as implicações desta seleção.
Estamos atualmente a trabalhar com a Microsoft para resolver este problema em todas as configurações. Contacte o nosso suporte se também for afetado.
A minha Storage Account indica que Não Está Ligada
Se a página inicial do seu SCEPman mostrar uma etiqueta vermelha "Not Connected" para a conectividade da Storage Account, é possível que a Managed Identity do SCEPman App Service (e possivelmente a do SCEPman Certificate Master) não tenha permissões na Storage Account. Neste caso, o SCEPman não consegue verificar se um certificado foi revogado manualmente e, por isso, não consegue responder a pedidos OCSP. Isto normalmente acontece se mover a Storage Account para outra subscrição ou grupo de recursos. Também pode ocorrer após atualizar uma versão Community Edition para Enterprise Edition -- neste caso, o problema de permissões já existia antes, mas a Community Edition não o verificava.
Para corrigir isto, tem de atribuir à Identidade Gerida do SCEPman App Service e à do SCEPman Certificate Master a função "Storage Table Data Contributor" na Storage Account. As atribuições de funções podem ser feitas manualmente no Azure Portal em "Access Control (IAM)" na Storage Account. Em alternativa, basta executar novamente o CMDlet de Instalação do SCEPman a partir do módulo PowerShell do SCEPman.
O SCEPman não emitirá certificados com EKUs diferentes de Client Authentication
Verifique as variáveis de ambiente do SCEPman para ver o que está configurado para AppConfig:UseRequestedKeyUsages. Se não estiver definido, o valor predefinido é "false".
As novas instalações definirão isto automaticamente como "true"; no entanto, instalações mais antigas do SCEPman têm isto definido como false. As atualizações do SCEPman não alteram qualquer comportamento, exceto correções ou alterações que em nenhuma circunstância tenham desvantagem. Quando isto está definido como false, os EKUs e Key Usages solicitados são ignorados.
Última atualização
Isto foi útil?