Problemas comuns
Problemas ao iniciar o SCEPman
Implementei o SCEPman a partir do GitHub e antes funcionava, mas agora a Web App já não inicia
Se o erro for '503 Cannot download ZIP', então a aplicação web 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 do 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. Por isso, é necessário alterar o URL para https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.
A Web App Azure do SCEPman não está em execução
Verifique se o recurso do Azure está ativo e em execução.
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 configuradas para esse App Service em Definições -> Configuração -> Definições gerais -> Definições da Stack. 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 o SCEPman 2.8.
Isto acontece porque algumas versões comuns do .NET estão automaticamente disponíveis em todos os App Services do Windows, independentemente da versão do .NET que selecionar nas definições. Só fazemos a atualização do 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 isto 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. Por isso, na verdade, não importa o que está configurado como versão do .NET.
O meu App Service do SCEPman 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 SCEPman descontinuado https://github.com/glueckkanja/gk-scepman após mais de três anos a mover artefactos para a nova localização https://github.com/scepman/install. Na quarta-feira, 2024-11-27, desativámos temporariamente a localização antiga para alertar os utilizadores para o encerramento permanente na segunda-feira, 2024-12-16.
Se foi afetado, verifique a sua definição WEBSITE_RUN_FROM_PACKAGE e atualize o valor para a nova localização 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 tem a certeza de estar 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 Certificado Raiz Confiável está implementado, mas o meu Certificado de Dispositivo via Perfil SCEP 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 confiável 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 irá aparecer, clique em Admin
Percorra a lista e procure o ID de evento 32
Contém um breve relatório de erro
SCEP: A inscrição do certificado falhou. Resultado (O valor hash não está correto.).
Se estiver a usar uma CA Intermédia, tenha em atenção que tem de selecionar o certificado da CA Intermédia e não o certificado da CA Raiz na configuração do perfil SCEP! Tenha em atenção que isto é específico da plataforma Windows e, por exemplo, o Android requer a seleção do certificado da CA Raiz na configuração do perfil SCEP.
O meu certificado não tem a entrada correta de URL OCSP
Isto é apenas um problema anterior à versão 1.2
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 importante da aplicação com o nome AppConfig:BaseUrl definido 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 de certificado Raiz Confiável. Atribua ambos os perfis ao mesmo utilizador ou grupo de dispositivos do Azure Active Directory para garantir que o utilizador ou dispositivo se sobrepõe e que ambos os perfis são destinados ao dispositivo. Não misture grupos de utilizadores e de dispositivos. Se vir o estado pendente para os perfis de configuração no Intune durante muito tempo, a atribuição provavelmente está incorreta.
Algumas máquinas Windows não inscrevem nem renovam certificados
Pode verificar tanto do lado do SCEPman como do lado do cliente. Dependendo do problema, que muitas vezes não conhece antecipadamente, a causa raiz é apresentada apenas num dos dois lados.
Verifique se existe alguma [ERROR] entrada nos registos do SCEPman. Possivelmente procure também pelo termo de pesquisa [WARN, mas isso pode produzir 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 ajuda a localizar problemas de inscrição 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 App Service do SCEPman 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 conseguem inscrever-se com o 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 emitidos recentemente, pois estes ainda não estão válidos. O Windows então descarta estes certificados "inválidos" e mostra um erro. Por predefinição, os certificados são emitidos com 10 minutos de retroatividade para resolver pequenos problemas de relógio, mas recentemente vimos dispositivos Windows 10 com um atraso de até 9 horas.
Pode prosseguir com a inscrição e, assim que esta terminar, o dispositivo obterá um certificado com sucesso, porque o relógio já estará correto. Também pode usar a nova opção AppConfig:ValidityClockSkewMinutes para datar certificados com mais de 10 minutos de retroatividade. Use 1440 minutos para datar os certificados com um dia inteiro de retroatividade. 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 os certificados com um dia de retroatividade para contrariar problemas com dispositivos cujo relógio está atrasado, ver Dispositivos Windows 10 não conseguem inscrever-se com o AutoPilot.
Problemas com a validade dos certificados
Verificar certificado local
Máquina Windows
Primeiro, tem de verificar a validade do certificado do dispositivo. Para isso, abra uma 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 do 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 (Chaves do Sistema > Raízes do Sistema) como ficheiro *.cer e coloque-o numa pasta (em alternativa, pode descarregá-lo a partir do site da sua instância SCEPman).
Exporte o certificado de autenticação de cliente que pretende verificar de Acesso às Chaves (Chaves do Sistema > Sistema > Os Meus Certificados) como ficheiro *.cer para a mesma pasta.
Extraia o URL do respondedor OCSP do Acesso a Informação da Autoridade (AIA) do certificado de autenticação do cliente:
Abra uma sessão de Terminal e
cdpara a pasta que contém os certificados exportados.Execute o seguinte comando:
Perto do final da resposta, o estado da revogação é apresentado:\
Verificar certificados de outras máquinas
Em alternativa, pode exportar o certificado do dispositivo e usar certutil numa máquina Windows para apresentar uma pequena interface 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 o início de sessão do 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): "Dispositivos" - "Todos os dispositivos").
Intune: Eliminar o dispositivo ou acionar 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 o Microsoft Entra ID (Azure AD) e Intune, conforme descrito.
Para mais detalhes sobre diretórios de dispositivos, leia o artigo Diretórios de dispositivos.
O seguinte exemplo revoga um certificado de dispositivo através do Microsoft Entra ID (Azure AD):
Navegue até Dispositivos - Todos os dispositivos 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 deverá ser marcado como válido.
Pode demorar até 5 minutos até aparecer o pedido 'Marcado como válido'.
O Access Point não consegue verificar um certificado de autenticação emitido pelo SCEPman
Sintomas: O Cisco ISE mostra um erro OCSP inacessível. O Aruba ClearPass também tem este problema. O servidor, aparentemente o SCEPman, responde ao pedido OCSP com um pacote de reinicialização TCP.
Causa: Tanto o Cisco ISE como o Aruba ClearPass não suportam HTTP 1.1 ao procurar OCSP e não enviam um cabeçalho host no seu pedido OCSP. Por isso, não conseguem ligar-se a uma instância geral do SCEPman em execução em Azure App Services. A mensagem de erro pode ser parecida com esta:
Solução: Consulte aqui.
Os Certificados de Dispositivo nos meus sistemas Android (dedicados) não são válidos
Nos sistemas Android (dedicados), o Intune ou o Android colocam acidentalmente o ID do Dispositivo Intune no certificado em vez do ID do Dispositivo AAD em casos aleatórios, apesar de configurar 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 Microsoft Entra ID (Azure AD) para o método de inscrição de dispositivos dedicados propriedade da empresa, em vez do modo predefinido. Se usar o modo predefinido para tipos de token dispositivo dedicado propriedade da empresa, não será afetado pelo problema. O Intune continuará a colocar o ID do Dispositivo Intune no certificado em vez do ID do Dispositivo AAD, mas estes serão iguais no modo predefinido, por isso não importa. Para alterar o modo de inscrição, vá às definições de inscrição Android do centro de administração do Microsoft Endpoint Manager e escolha dispositivo dedicado propriedade da empresa (predefinição) em vez de dispositivo dedicado propriedade da empresa com o modo partilhado do Azure AD. Consulte a documentação da Microsoft para 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 Conta de Armazenamento diz que Não Está Ligada
Se a página inicial do seu SCEPman mostrar uma etiqueta vermelha "Not Connected" para conectividade da Conta de Armazenamento, é possível que a Identidade Gerida do App Service do SCEPman (e possivelmente a do SCEPman Certificate Master) não tenha permissões na Conta de Armazenamento. 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 acontece normalmente se mover a Conta de Armazenamento 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 conceder à Identidade Gerida do App Service do SCEPman e à do SCEPman Certificate Master a função "Contribuidor de Dados da Tabela de Armazenamento" na Conta de Armazenamento. As atribuições de função podem ser feitas manualmente no Portal do Azure em "Controlo de Acesso (IAM)" na Conta de Armazenamento. Em alternativa, basta executar novamente o cmdlet de instalação do SCEPman do módulo PowerShell do SCEPman.
O SCEPman não emitirá certificados com EKUs além de Autenticação de Cliente
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 automaticamente isto para "true"; no entanto, instalações SCEPman mais antigas têm isto definido como false. As atualizações do SCEPman não alteram qualquer comportamento, exceto correções ou alterações que não tenham, em nenhuma circunstância, uma desvantagem. Quando isto está definido como false, os EKUs e os Key Usages pedidos são ignorados.
Última atualização
Isto foi útil?