Problemas Comuns
Problemas ao iniciar o SCEPman
Implantei o SCEPman a partir do GitHub e ele costumava funcionar, mas agora o aplicativo web não inicia mais
Se o erro for '503 Cannot download ZIP', então o aplicativo web não consegue baixar o ZIP com os binários do aplicativo a partir da URL configurada na configuração do aplicativo WEBSITE_RUN_FROM_PACKAGE (veja Configuração do Aplicativo).
A URL https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip que recomendamos para implantações no GitHub em versões anteriores desta documentação redireciona para outra URL. A Microsoft alterou o comportamento de algumas de suas Web Apps e agora algumas versões não suportam redirecionamentos juntamente com WEBSITE_RUN_FROM_PACKAGE. Portanto, você precisa alterar a 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 do Azure está ativo e executando.
Meu App Service usa a versão .NET incorreta
No recurso App Service do SCEPman ou do Certificate Master, você pode verificar qual Stack e versão estão configuradas para esse App Service em Configurações -> Configuração -> Configurações gerais -> Configurações de Stack. Enquanto o Stack é .NET, a versão do .NET pode não corresponder ao que você espera para sua versão do SCEPman, por exemplo .NET 8 para o SCEPman 2.8.
Isto ocorre 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 você seleciona nas configurações. Só atualizamos o SCEPman para uma nova versão do .NET quando essa versão está incluída nesse conjunto de versões do .NET instaladas automaticamente. Fazemos isso porque nosso mecanismo de atualização via WEBSITE_RUN_FROM_PACKAGE não nos dá qualquer controle sobre a configuração da versão do .NET. Portanto, na prática, não importa o que esteja configurado como versão do .NET.
Meu App Service SCEPman não funcionou em 27-11-2024 e parou de funcionar completamente desde 16-12-2024 depois de ter funcionado sem problemas por muitos anos
Estamos encerrando o repositório obsoleto de artefatos do SCEPman https://github.com/glueckkanja/gk-scepman após mais de três anos movendo artefatos para o novo local https://github.com/scepman/install. Na quarta-feira, 27-11-2024, nós desativamos temporariamente o local antigo para alertar os usuários sobre o encerramento permanente na segunda-feira, 16-12-2024.
Se você foi afetado, verifique sua configuração WEBSITE_RUN_FROM_PACKAGE e atualize o valor para o novo local do pacote. Isso também atualizará sua versão do SCEPman de 1.8 para a versão mais recente, concedendo muitas melhorias com compatibilidade retroativa total.
Se você não tem certeza se está usando o repositório mais recente, visite a página inicial do seu SCEPman. Se ainda estiver configurado no repositório antigo, ele exibirá um aviso (e já o faz nos últimos três anos) que se parece com isto:
Problemas ao emitir certificados
Certificado de Root confiável está implantado, mas meu Certificado de Dispositivo via Perfil SCEP resulta em Erro
O perfil SCEP resultará em erro se a implantação do certificado não foi bem-sucedida. Erros podem ter várias causas:
O perfil de certificado SCEP está configurado com um erro
Isso pode acontecer quando um certificado raiz confiável incorreto foi selecionado no perfil de certificado SCEP. Isso também é mostrado no log de eventos:
Abra o aplicativo Eventos do Windows
Clique Logs de Aplicativos e Serviços
Em seguida, clique Microsoft
Depois, clique Windows
Role para baixo e procure por DeviceManagement-Enterprise-Diagnostics-Provider e clique nele.
Na janela que aparecer, clique Admin
Percorra a lista e procure pelo ID do evento 32
Ele contém um breve relatório de erro
SCEP: Falha na inscrição do certificado. Resultado (O valor hash não está correto.).
Se você estiver usando uma CA Intermediária, note que você deve selecionar o certificado da CA Intermediária e não o certificado da CA Raiz no perfil de configuração SCEP! Observe que isso é específico para a plataforma Windows e, por exemplo, o Android requer selecionar o certificado da CA Raiz no perfil de configuração SCEP.
Meu Certificado não possui a Entrada OCSP correta
Isto é apenas um problema antes da versão 1.2
Se o certificado do dispositivo tiver uma URL localhost para a entrada OCSP no certificado como esta:
O App Service está sem uma configuração de aplicativo importante com o nome AppConfig:BaseUrl definida para a URL azurewebsite. Para corrigir isso, adicione a variável e salve a configuração do App Service:
Exclua este certificado do dispositivo e faça a sincronização MDM. Se você fizer isso, verá uma URL adequada para a entrada OCSP:
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 grupo de usuários ou dispositivos do Azure Active Directory para garantir que o usuário ou dispositivo coincida e ambos os perfis sejam direcionados ao dispositivo. Não misture grupos de usuários e dispositivos. Se você vir pendente como status para os perfis de configuração no Intune por muito tempo, provavelmente a atribuição está errada.
Algumas máquinas Windows não registram ou renovam certificados
Você pode verificar tanto do lado do SCEPman quanto do lado do cliente. Dependendo do problema, que muitas vezes você não sabe antecipadamente, a causa raiz é mostrada em apenas um dos dois lados.
Verifique se há algum [ERROR] registro nos logs do SCEPman. Possivelmente também pesquise pelo termo de busca [WARN, mas isso pode gerar alguns falsos positivos.
Oliver Kieselbach e Christoph Hannebauer escreveram um artigo de blog sobre análise de problemas de solicitação ou renovação de certificado que ajuda a localizar problemas de inscrição no lado do cliente.
O cliente SCEP do Windows suporta apenas TLS até a versão 1.2. Definir a versão TLS mínima de entrada para 1.3 no App Service do SCEPman causa entradas de erro particulares no DeviceManagement-Enterprise-Diagnostics-Provider log de eventos. Aqui está um exemplo de uma máquina Windows 11:
Dispositivos Windows 10 não conseguem se inscrever com AutoPilot
Atualmente, alguns dispositivos Windows 10 não têm a hora correta durante a experiência OOBE. Isso não é fácil de ver, já que a tela não mostra relógio. Isso causa um problema com certificados recém-emitidos, pois eles são ainda não válidos. O Windows então descarta esses certificados "inválidos" e mostra um erro. Os certificados são emitidos com 10 minutos no passado por padrão para lidar com pequenas diferenças de relógio, mas recentemente vimos dispositivos Windows 10 que estavam até 9 horas defasados.
Você pode prosseguir com a inscrição e, uma vez concluída, o dispositivo receberá um certificado com sucesso, pois o relógio estará correto então. Você também pode usar a nova opção AppConfig:ValidityClockSkewMinutes para retroceder a data dos certificados por mais de 10 minutos. Use 1440 minutos para retroceder os certificados por um dia inteiro. Isso será o padrão para novas instalações do SCEPman para tratar esse problema.
Emiti um certificado hoje, mas a Data de Emissão diz que foi ontem
Isto ocorre porque o SCEPman retrocede a data do certificado por um dia para contornar problemas com dispositivos cujo relógio está atrasado, veja Dispositivos Windows 10 não conseguem se inscrever com AutoPilot.
Problemas com a Validade dos Certificados
Verificar Certificado local
Máquina Windows
Primeiro, você precisa verificar a validade do certificado do dispositivo. Para isso, abra um prompt de comando como administrador e digite o seguinte comando:
Veja o certificado com o ID do dispositivo emitido pela SCEPman-Device-Root-CA-V1 e verifique se o certificado é válido (veja a última linha).
Para verificar se o respondedor OCSP está funcionando, você pode olhar o cache de URL OCSP com o seguinte comando:
Máquina macOS
Para verificar a validade de um certificado em uma máquina macOS usando OCSP, por favor siga estes passos:
Exporte o certificado Root CA do SCEPman de Acesso às Chaves (Keychain Access) (Chaves do Sistema > Raízes do Sistema) como arquivo *.cer e coloque-o em uma pasta (alternativamente, você pode baixá-lo do site da sua instância SCEPman).
Exporte o certificado de autenticação do cliente que você deseja verificar de Acesso às Chaves (Keychain Access) (Chaves do Sistema > Sistema > Meus Certificados) como arquivo *.cer para a mesma pasta.
Extraia a URL do respondedor OCSP da propriedade Authority Information Access (AIA) do certificado de autenticação do cliente:
Abra um Terminal sessão e
cdpara a pasta que contém os certificados exportados.Execute o seguinte comando:
Perto do final da resposta, o status de revogação é exibido:\
Verificar certificados de outras máquinas
Como alternativa, você pode exportar o certificado do dispositivo e usar certutil em uma máquina Windows para exibir uma pequena interface certutil para a verificação OSCP:
Revogar um usuário
Se você quiser revogar um certificado de usuário você tem duas opções:
Excluir o usuário do Microsoft Entra ID (Azure AD) ou
Bloquear o login do usuário
Se você quiser revogar um certificado do dispositivo você tem várias opções dependendo de AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD): Excluir ou desativar o dispositivo (Portal do Microsoft Entra ID (Azure AD): "Dispositivos" - "Todos os dispositivos").
Intune: Excluir o dispositivo ou acionar uma ação remota (vários estados de gerenciamento como "WipePending" revogam certificados automaticamente como 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, por favor leia o artigo Diretórios de Dispositivo.
O exemplo a seguir revoga um certificado de dispositivo via Microsoft Entra ID (Azure AD):
Navegue até Dispositivos - Todos os dispositivos no seu Microsoft Entra ID (Azure AD)
Escolha um dispositivo
Clique Desativar
Em seguida, digite o seguinte comando novamente:
Como você pode ver na última linha, o Certificado está REVOGADO
Quando você ativar o dispositivo novamente no Microsoft Entra ID (Azure AD) e digitar o comando acima novamente, o certificado deverá ser marcado como válido.
Pode levar até 5 minutos antes que o prompt 'Marcado como válido' apareça.
Ponto de Acesso não consegue verificar um certificado de autenticação que o SCEPman emitiu
Sintomas: O Cisco ISE mostra um erro OCSP inacessível. O Aruba ClearPass também tem esse problema. O servidor, aparentemente SCEPman, responde com um pacote TCP reset para a solicitação OCSP.
Causa: Tanto o Cisco ISE quanto o Aruba ClearPass não suportam HTTP 1.1 ao consultar OCSP e não enviam um cabeçalho host na sua solicitação OCSP. Portanto, eles não conseguem se conectar a uma instância SCEPman genérica executando em Azure App Services. A mensagem de erro pode ter esta aparência:
Solução: Por favor veja 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 acidentalmente coloca o ID do dispositivo Intune no certificado em vez do ID do dispositivo AAD em casos aleatórios, embora você configure a variável no perfil de configuração SCEP. O SCEPman então não consegue encontrar um dispositivo com esse ID no AAD e, portanto, considera o certificado revogado.
Isso ocorre apenas quando você usa o modo compartilhado do Microsoft Entra ID (Azure AD) para o método de inscrição de dispositivos dedicados de propriedade corporativa em vez do modo padrão. Se você usar o modo padrão para tipos de Token Dispositivo dedicado de propriedade corporativa, você não será afetado pelo problema. O Intune ainda colocará o ID do dispositivo Intune no certificado em vez do ID do dispositivo AAD, mas eles serão os mesmos no modo padrão, então não faz diferença. Para alterar o modo de inscrição, vá para as Configurações de inscrição do Android no centro de administração do Microsoft Endpoint Manager e escolha Dispositivo dedicado de propriedade corporativa (padrão) em vez de Dispositivo dedicado de propriedade corporativa com modo compartilhado do Azure AD. Por favor consulte a documentação da Microsoft para as implicações desta seleção.
Atualmente estamos trabalhando com a Microsoft para resolver este problema em todas as configurações. Por favor contate nosso suporte se você também for afetado.
Minha Conta de Armazenamento diz que não está conectada
Se a página inicial do seu SCEPman mostrar uma etiqueta vermelha "Not Connected" para conectividade da Conta de Armazenamento, possivelmente a Identidade Gerenciada do App Service do SCEPman (e possivelmente a do SCEPman Certificate Master) está sem permissões na Conta de Armazenamento. Nesse caso, o SCEPman não pode verificar se um certificado foi revogado manualmente e, portanto, não pode responder a solicitações OCSP. Isso geralmente acontece se você mover a Conta de Armazenamento para outra assinatura ou grupo de recursos. Também pode ocorrer após atualizar uma versão Community Edition para Enterprise Edition -- nesse caso, o problema de permissão já existia antes, mas a Community Edition não verificava isso.
Para corrigir isso, você precisa conceder à Identidade Gerenciada do App Service do SCEPman e à do SCEPman Certificate Master a função "Storage Table Data Contributor" na Conta de Armazenamento. As atribuições de função podem ser feitas manualmente no Portal do Azure em "Controle de Acesso (IAM)" na Conta de Armazenamento. Alternativamente, apenas execute novamente o CMDlet de Instalação do SCEPman do módulo PowerShell do SCEPman.
O SCEPman não emitirá certificados com EKUs diferentes de Autenticação de Cliente
Verifique suas Variáveis de Ambiente do SCEPman para ver o que está configurado para AppConfig:UseRequestedKeyUsages. Se não estiver definido, ele padrão é "false".
Novas instalações definirão automaticamente isso como "true", porém instalações mais antigas do SCEPman têm isso definido como false. As atualizações do SCEPman não mudam qualquer comportamento exceto para correções ou alterações que sob nenhuma circunstância tragam uma desvantagem. Quando isto está definido como false, os EKUs e Key Usages solicitados nas requisições são ignorados.
Last updated
Was this helpful?