# CA intermediária
{% hint style="warning" %}
Apenas SCEPman Enterprise Edition
{% endhint %}
Se você quiser usar outra Root CA como autoridade principal, pode criar um certificado de CA intermediária para operar o SCEPman como uma Autoridade de Certificação Subordinada. Você pode criar o certificado correto diretamente no Azure Key Vault e baixar o CSR para assinatura com a sua Root CA. A solicitação assinada pode ser carregada e mesclada no Azure Key Vault. Este artigo orienta você pelos passos necessários em detalhes.
## Permissões do Key Vault
Você precisa conceder acesso ao Azure Key Vault à sua conta de usuário para criar o CSR e mesclar o certificado da CA intermediária. A forma de atribuir as permissões depende da configuração de acesso do seu Key Vault:
{% tabs %}
{% tab title="Azure RBAC" %}
1. Navegue até o seu Azure Key Vault no Azure Portal
2. Clique em **Controle de acesso (IAM)** no painel de navegação à esquerda.
3. Clique em **Atribuições de função** e adicione uma nova atribuição de função
Adicione uma nova atribuição de função ao seu Key Vault
4. Selecione o **Key Vault Certificate Officer** função e clique **Seguinte**
5. Agora procure e adicione sua conta de administrador do AAD na seção **Membros** e continue para atribuir a função
Depois de adicionar a atribuição de função, sua conta do Azure AD tem permissão para criar um CSR e carregar o certificado.
{% endtab %}
{% tab title="Políticas de acesso do Vault" %}
1. Navegue até o seu Azure Key Vault no Azure Portal
2. Clique em **políticas de acesso** no painel de navegação à esquerda.
3. Clique em **Criar** e escolha o **Gestão de certificados** modelo, depois próximo
4. Agora procure e adicione sua conta de administrador do AAD na seção **Principal** seção, depois próximo, próximo e criar
Depois de adicionar as permissões, sua conta do Azure AD tem permissão para criar um CSR e carregar o certificado.
{% endtab %}
{% endtabs %}
## Abrir a rede do Key Vault para o sistema de administração
Se estiver a usar um [Private Endpoint](https://docs.scepman.com/pt/configuracao-do-azure/private-endpoints) para o Key Vault, você precisa adicionar uma exceção que permita ao cliente acessar o Key Vault em nível de rede. Se você não estiver usando um Endpoint Privado, pode pular esta parte.
* Vá para o Azure Key Vault no Azure Portal.
* Navegue até a seção Networking em Configurações.
* Mude para "Permitir acesso público de redes virtuais e endereços IP específicos" se você tiver selecionado atualmente "Desabilitar acesso público".
* Adicione o endereço IP do cliente no qual você deseja [executar o módulo SCEPman PowerShell mais tarde](#creating-intermediate-ca-certificate-with-the-scepman-powershell-module). Se você estiver usando o Azure Cloud Shell e [ele estiver conectado a uma VNET](https://learn.microsoft.com/en-us/azure/cloud-shell/vnet/overview), você pode adicionar essa VNET. Caso contrário, a maneira mais fácil é permitir temporariamente o endereço IP público do Cloud Shell, já que a autenticação forte protege o seu Key Vault. Você pode usar um comando como `(Invoke-WebRequest -UseBasicParsing -uri "http://ifconfig.me/ip").Content` para localizar o endereço IP público da sessão.
## Atualizar as configurações do Azure App Service
O próximo passo é atualizar a configuração do Azure App Service para corresponder ao nome de assunto da CA intermediária que você criará no próximo passo.
1. Navegue até o seu Azure App Service
2. Clique em **Environment variables** no painel de navegação à esquerda
3. Em **Configurações do aplicativo,** você deve editar as seguintes configurações:
1. `AppConfig:KeyVaultConfig:RootCertificateConfig:CertificateName`\
Altere isto para um common name (CN) preferencial para a sua CA intermediária.
2. `AppConfig:KeyVaultConfig:RootCertificateConfig:Subject`\
Altere apenas o valor CN do nome de assunto para corresponder ao common name usado acima.
4. Clique em **Aplicar e Confirmar.**
5. Reinicie o Azure **App Service** para aplicar as alterações e, em seguida, navegue até o URL do seu SCEPman.
{% hint style="warning" %}
Tenha em atenção que a variável CertificateName corresponderá diretamente ao objeto de certificado que será criado no Azure Key Vault. Portanto, você só pode usar nomes de certificado que contenham caracteres alfanuméricos e hífens
{% endhint %}
## Criando o certificado da CA intermediária com o módulo SCEPman PowerShell
{% hint style="warning" %}
Para garantir que este módulo funcione corretamente, você precisará de uma estação de trabalho com [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) (também conhecido como `az`) instalado. O Azure CLI vem pré-instalado no [Azure Cloud Shell](https://docs.microsoft.com/en-us/azure/cloud-shell/overview), que é o ambiente recomendado para executar este módulo.
{% endhint %}
Você pode usar o módulo SCEPman PowerShell versão 1.9 e posterior para criar um CSR para um certificado de CA intermediária. Você pode instalar a versão mais recente do módulo a partir da PowerShell Gallery com o seguinte comando:
```powershell
Install-Module -Name SCEPman -Scope CurrentUser -Force
```
Em seguida, você pode informar ao módulo o nome da sua organização para aparecer no certificado:
```powershell
Reset-IntermediateCaPolicy -Organization "My Organization"
```
Configure o assunto da sua CA intermediária para corresponder ao que você usou acima em `AppConfig:KeyVaultConfig:RootCertificateConfig:Subject` (opcionalmente, você pode modificar algumas configurações adicionais para controlar o conteúdo do CSR):
{% code lineNumbers="true" %}
```
$policy = Get-IntermediateCaPolicy
$policy.policy.x509_props.subject = "CN=YOUR_CN_FROM_ABOVE,OU=YOUR_TENANT_ID,O=YOUR_ORGANIZATION"
# altere algumas configurações adicionais de $policy
Set-IntermediateCaPolicy -Policy $policy
```
{% endcode %}
Por fim, você pode criar o CSR com o seguinte comando (ou um semelhante de acordo com o seu ambiente):
```powershell
New-IntermediateCA -SCEPmanAppServiceName "app-scepman-example" -SearchAllSubscriptions 6>&1
```
O comando exibirá o CSR que você deve submeter à sua Root CA para assinatura.
## Emitir o certificado da CA intermediária
Agora, envie o seu CSR para a sua Root CA e recupere o Certificado da CA Intermediária emitido. Salve o certificado em disco (.cer) para que, no próximo passo, você possa carregá-lo e mesclá-lo com a chave privada no Azure Key Vault.
### Passos especiais para uma Root CA corporativa do ADCS
Se você estiver usando o Active Directory Certificate Services como uma Root CA integrada ao AD e, portanto, tiver de escolher um Certificate Template, ele deve incluir os seguintes Key Usages: "CRLSign", "DigitalSignature", "KeyEncipherment" e "KeyCertSign". KeyEncipherment está ausente no modelo padrão "Subordinate Certificate Authority" e, além disso, não pode ser selecionado em novos modelos. Consulte abaixo uma solução caso encontre esse problema. **Isto não se aplica a Root CAs independentes**, também chamadas de Offline Root CAs, pois elas obtêm os Key Usages corretamente a partir do CSR.
#### Visão geral
Você pode duplicar o modelo SubCA ou usá-lo conforme necessário. Depois, você apenas emite um certificado com base no modelo a partir do CSR. Este certificado terá *o Key Usage incorreto* (0x86). Depois disso, você reassina o certificado com uma extensão Key Usage adaptada usando `certutil -sign`.
#### Passo a passo
1. Solicite e emita um certificado SubCA.
2. Exporte o novo certificado SubCA para um arquivo (por exemplo, c:\temp\SubCA.cer) na Root CA. Escolha **Base-64 encoded X.509** formato.
3. Crie um arquivo "extfile.txt" com o conteúdo mostrado abaixo na Root CA (por exemplo, c:\temp\extfile.txt).
4. Abra a linha de comando e execute: `certutil -sign "c:\temp\SubCA.cer" "c:\temp\SubCAwithKeyEncipher.cer" @c:\temp\extfile.txt`
5. O certificado SubCAwithKeyEncipher.cer agora contém o uso de chave solicitado (0xA6). A impressão digital (assinatura) foi alterada, mas o número de série não.
6. A lista de certificados emitidos no ADCS contém o certificado antigo. Como o número de série não foi alterado, você pode gerenciar o novo certificado usando o antigo identificador; por exemplo, revogar o certificado antigo revogará o novo certificado. Se você não quiser isso, pode excluir a entrada do certificado antigo usando `certutil -deleterow` e depois importar o novo certificado usando `certutil -importcert`.
#### extfile.txt
```
[Extensions]
2.5.29.15=AwIBpg==
Critical=2.5.29.15
```
## Carregar o certificado da CA intermediária
1. No Azure Key Vault, clique no seu certificado e pressione **Operação do certificado**
2. Agora você pode ver as opções **Baixar CSR** e **Mesclar solicitação assinada**
1. Clique em **Mesclar solicitação assinada** e carregue o seu Certificado da CA Intermediária. Depois de carregar a solicitação assinada, você pode ver o certificado válido no seu Azure Key Vault na área **Concluído**
{% hint style="warning" %}
O Certificado da CA Intermediária deve estar em formato PEM (codificado em Base64). Se você usar o formato binário DER, verá uma mensagem de erro que diz "Property x5c has invalid value X5C must have at least one valid item" nos detalhes.
{% endhint %}
## Verificar a adequação da CA
Na página de Status do SCEPman, você pode ver a nova configuração e baixar o novo certificado da CA intermediária para implantá-lo por meio do Endpoint Manager.
Verifique se o certificado da CA atende a todos os requisitos visitando a sua página inicial do SCEPman. Veja o que a página inicial diz ao lado de "CA Suitability". Se, por exemplo, ela disser *CA Certificate is missing Key Usage "Key Encipherment"*, você deve voltar para a etapa [Emitir o certificado da CA intermediária](#issue-the-intermediate-ca-certificate) e corrigir a emissão do certificado.
## CAs intermediárias e perfis SCEP do Intune
Na plataforma Android, os Perfis de Configuração SCEP no Intune devem referenciar a Root CA, e não a CA intermediária. Caso contrário, o perfil de configuração falha. No Windows, é o contrário: os Perfis de Configuração SCEP no Intune devem referenciar a CA intermediária, e não a Root CA. Para iOS e macOS, não temos informações conclusivas sobre se uma ou outra forma é melhor.
