> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/pt/outros/troubleshooting/general.md).

# 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](/pt/configuracao-do-scepman/application-artifacts.md#change-artifacts)).

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.

![](/files/ce9f16be971feb5afa2c28c50f971fb94f0c3c5a)

### 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 ](/pt/configuracao-do-scepman/application-settings/basics.md#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](/pt/configuracao-do-scepman/application-artifacts.md) 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](/pt/changelog.md) 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:

<figure><img src="/files/89dfb04b135dc36963bddfa428f6c8128d0c6771" alt=""><figcaption><p>SCEPman a usar o local antigo do pacote para WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## 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:

1. Abra a aplicação Eventos do Windows
2. Clique em **Registos de Aplicações e Serviços**
3. Em seguida, clique em **Microsoft**
4. Depois, clique em **Windows**
5. Desloque-se para baixo e procure **DeviceManagement-Enterprise-Diagnostics-Provider** e clique nele.
6. Na janela que aparecer, clique em **Admin**
7. Percorra a lista e procure o ID de evento **32**
8. Contém um breve relatório de erro
   * SCEP: Falha no registo do certificado. Resultado (O valor hash não está correto.).

![](/files/87e76c97c723c75d6c81b486b743acfb73c1d128)

Se estiver a usar uma CA intermédia, note que tem de [selecionar o certificado da CA intermédia](/pt/implementacao-do-scepman/intermediate-certificate.md#intermediate-cas-and-intune-scep-profiles) 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

{% hint style="info" %}
Isto é apenas um problema anterior à versão 1.2
{% endhint %}

Se o certificado do dispositivo tiver um URL localhost para a entrada OCSP no certificado, como este:

![](/files/e2bc8e0f636912adbc0ab4027c427837574279f9)

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:

```
AppConfig:BaseUrl
https://scepman-XXXXX.azurewebsites.net
```

Elimine este certificado do dispositivo e faça a sincronização MDM. Se o fizer, verá um URL correto para a entrada OCSP:

![](/files/c76a0bd42f8857be34c0373791dcc8dc1e2e3c02)

### 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](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) 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:

{% code overflow="wrap" fullWidth="false" %}

```
TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 32
Message      : SCEP: Falha no registo do certificado. Resultado: (Código de erro Win32 desconhecido: 0x80072f8f).

TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 307
Message      : SCEP: Falha na mensagem LogError : (SCEPInstallCertificateWithScepHelper:Falha ao inicializar
               Registo SCEP com o servidor NDES
               'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', CA cert thumbprint
               '24C45EF4284A5093A9C3886A6466C1D6D84EE058' and server certs ''. LogError 0x80)
```

{% endcode %}

### 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**](/pt/configuracao-do-scepman/application-settings/certificates.md#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](#windows-10-devices-cannot-enroll-with-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:

```
certutil -verifyStore MY
```

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).

![](/files/d9699c1a48cca38cfe171a68889c943c48f99166)

Para verificar se o respondedor OCSP está a funcionar, pode consultar a cache de URL OCSP com o seguinte comando:

```
certutil -urlcache OCSP
```

![](/files/64095bec891e8fe17b6ac540e1584489aeb7fd01)

#### Máquina macOS

Para verificar a validade de um certificado numa máquina macOS usando OCSP, siga estes passos:

1. 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).
2. 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.
3. Extraia o URL do respondedor OCSP do **Acesso à Informação de Autoridade** (AIA) propriedade:

   <figure><img src="/files/241e17070ceae3b5288a2a5f68823c4714549bc1" alt=""><figcaption></figcaption></figure>
4. Abra uma **Terminal** sessão e `cd` para a pasta que contém os certificados exportados.
5. Execute o seguinte comando:

```
openssl ocsp -issuer <filename-scepman-root-ca-certificate> -cert <filename-certificate-to-be-verified> -text -url <ocsp-responder-url>
```

6. Perto do fim da resposta, o estado de revogação é apresentado:\\

   <figure><img src="/files/cc4670b8ad4041d80cc03be1f008af60239e1059" alt=""><figcaption></figcaption></figure>

### 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:

```
certutil -url <path-to-exported-device-certificate>
```

![](/files/47cdf5b839d98bc147753008b459785140c30f50)

### Revogar um utilizador

Se quiser revogar um **utilizador** certificado, tem duas opções:�

1. Eliminar o utilizador do Microsoft Entra ID (Azure AD) ou
2. Bloquear início de sessão para o utilizador

Se quiser revogar um **dispositivo** certificado, tem várias opções dependendo de [Validação do Intune](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory):

1. Microsoft Entra ID (Azure AD): eliminar ou desativar o dispositivo ([Portal do Microsoft Entra ID (Azure AD)](https://aad.portal.azure.com/): "Devices" - "All devices").
2. **Intune**: Elimine o dispositivo ou acione uma ação remota (vários estados de gestão, como "WipePending", revogam automaticamente certificados, conforme indicado em [Validação do Intune](/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-revokecertificatesonwipe)).
3. **Ambos os diretórios**: Executar ações para Microsoft Entra ID (Azure AD) **e** Intune, conforme descrito.

{% hint style="info" %}
Para mais detalhes sobre diretórios de dispositivos, leia o artigo [Diretórios de dispositivos](/pt/configuracao-do-scepman/device-directories.md).
{% endhint %}

O exemplo seguinte revoga um certificado de dispositivo através do Microsoft Entra ID (Azure AD):

1. Navegue até **Devices - All devices** no seu Microsoft Entra ID (Azure AD)
2. Escolha um dispositivo
3. Clique em **Desativar**

Em seguida, escreva novamente o seguinte comando:

```
certutil -verifyStore MY
```

Como pode ver na última linha, o **Certificado está REVOGADO**

![](/files/1cc1bc62f332114eaa780610f9eece8f46036617)

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.

{% hint style="info" %}
Pode demorar até 5 minutos até aparecer o aviso 'Marked as valid'.
{% endhint %}

### 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:

![](/files/832c3848e89cb2d83a0b6a2ed347842b17d310f7)

*Solução*: Consulte [aqui](/pt/outros/troubleshooting/cisco-ise-host-header-limitation.md).

### 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](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) 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](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) 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](/pt/implementacao-do-scepman/permissions/post-installation-config.md#running-the-scepman-installation-cmdlet).

## 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](/pt/configuracao-do-scepman/application-settings/certificates.md#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.<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.scepman.com/pt/outros/troubleshooting/general.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
