Como funciona a emissão de certificados - Amplia Reg
Este artigo explica o caminho que um certificado percorre desde o pedido até a instalação no computador do titular: quem participa, por quais status o pedido passa e como o Amplia Reg e o Amplia trabalham juntos.
Em resumo, o Amplia Reg é a Autoridade de Registro (AR): confirma a identidade do titular e aprova o pedido. O Amplia é a Autoridade Certificadora (AC): emite e revoga o certificado. O Amplia só entra no final, quando o titular emite o certificado. Até lá, o pedido existe apenas no Amplia Reg.
Quem participa
| Participante | Papel no Amplia Reg | O que faz |
|---|---|---|
| Sua aplicação | Aplicação com o papel App de vendas | Cria pedidos pela API e recebe webhooks |
| Agente de validação | Agente de validação | Valida a identidade do titular e assina o dossiê e o termo de titularidade |
| Agente de conferência | Agente de conferência | Revisa o pedido validado e o aprova, devolve ou recusa |
| Titular | (nenhum; usa a página pública de emissão) | Apresenta documentos e biometria e, depois, emite o certificado |
| Amplia Reg | Conduz o fluxo, guarda as evidências e aciona o Amplia | |
| Amplia | Emite e revoga o certificado, usando a AC definida no tipo de certificado |
Coordenadores e supervisores gerenciam agentes, locais de atendimento e pedidos, e também podem cancelar pedidos e revogar certificados.
O fluxo, de ponta a ponta
O diagrama abaixo mostra um pedido típico, presencial ou por videoconferência, da criação até o certificado instalado. As etiquetas laranja mostram o status do pedido no Amplia Reg após cada passo.
1. Pedido
O pedido é criado com o tipo de certificado e os dados do titular, pela sua aplicação, por meio da API de criação de pedido, ou por um agente no painel de controle. O tipo de certificado define o formato do certificado, a mídia da chave, as opções de validade e quais etapas de validação se aplicam.
Um pedido novo começa em Aguardando validação. Se a chamada à API pedir para iniciar a validação imediatamente, o pedido começa em Em validação. Já os pedidos do tipo vídeo identificação começam em Aguardando vídeo identificação: primeiro o titular grava um vídeo de identificação por conta própria e, depois, o pedido passa para Aguardando validação.
2. Validação da identidade
Um agente de validação inicia a validação (Em validação) e cumpre as etapas que o tipo de certificado exige:
- os dados do titular e, quando habilitados, os documentos do titular
- a foto e a biometria do titular, com detecção de prova de vida (liveness), ou uma videoconferência com o titular
- consultas a fontes externas, quando habilitadas, como bases biométricas e bases de dados do governo (no Brasil, por exemplo, o Serpro)
- o termo de titularidade, que traz a chave de emissão 1 e é entregue ao titular
Para concluir, o agente assina o dossiê do pedido e o termo de titularidade com o próprio certificado. Se alguma verificação externa ainda estiver em andamento (um resultado biométrico, uma validação automática de documento ou o upload da gravação da videoconferência), o pedido fica em Aguardando recursos e segue sozinho quando os resultados chegam.
3. Conferência
O pedido vai para Aguardando conferência até que um agente de conferência o assuma (Em conferência). Normalmente, o agente de conferência é uma pessoa diferente do agente de validação. Ele revisa as evidências e então:
- aprova o pedido, assinando também o dossiê e o termo de titularidade. O pedido passa para Aguardando emissão.
- devolve o pedido para correção, por exemplo por divergência de dados, erro de digitação ou arquivos ilegíveis. O pedido passa para Pendente e o titular é avisado. Depois que o agente de validação corrige o pedido e o assina de novo, ele volta para a conferência.
- recusa o pedido (Recusado).
A exigência de conferência depende das configurações da instância e do pedido. Ela pode valer para todos os pedidos, que é o padrão, ou só quando algo pede uma segunda análise, por exemplo quando uma verificação falhou ou o titular é uma pessoa politicamente exposta. Quando a conferência não é exigida, o pedido vai direto da validação para Aguardando emissão.
Quando o pedido é aprovado, o Amplia Reg envia ao titular a chave de emissão 2 e o link de emissão, por e-mail e SMS.
Se a instância estiver configurada para usar uma única chave de emissão, o termo não traz chave e o titular recebe a única chave na aprovação.
4. Emissão
O titular abre o link de emissão e emite o certificado. Esta é a única etapa em que o Amplia participa:
- O titular informa as chaves de emissão. O Amplia Reg confere as chaves e verifica se o pedido está em Aguardando emissão. Tentativas erradas demais bloqueiam o pedido.
- O Web PKI gera o par de chaves no computador ou no dispositivo criptográfico do titular e envia a requisição de certificado (CSR) ao Amplia Reg.
- O Amplia Reg devolve o termo de titularidade, que o titular assina com a nova chave privada.
- O termo assinado é enviado de volta ao Amplia Reg.
- O Amplia Reg cria o pedido no Amplia, na AC definida no tipo de certificado, com a validade, as políticas e o número de série do pedido, e solicita ao Amplia a emissão do certificado a partir da CSR.
- O Amplia devolve o certificado. O Amplia Reg verifica com ele a assinatura do titular no termo, muda o pedido para Emitido e envia um e-mail ao titular.
- O navegador recebe o certificado e o Web PKI o instala junto da chave privada.
Com as mídias computador e dispositivo criptográfico, a chave privada nunca sai do lado do titular: o Amplia recebe apenas a CSR.
O local em que o par de chaves é gerado depende da mídia da chave definida no tipo de certificado:
| Mídia da chave | Onde o par de chaves é gerado |
|---|---|
| Computador | No computador do titular |
| Dispositivo criptográfico | No token ou smart card do titular |
| Nuvem | Em um HSM em nuvem; o titular recebe um link de emissão em nuvem em vez do link comum |
| Ascertia ADSS | No servidor Ascertia ADSS, e não no computador do titular |
Status do pedido
O diagrama abaixo mostra todos os status do pedido e as transições entre eles. Cada caixa mostra o status como aparece no painel de controle e o valor usado na API e nos webhooks.
| Status | Valor na API | Significado |
|---|---|---|
| Aguardando vídeo identificação | WaitingVideoIdentification | Aguardando o titular gravar o vídeo de identificação |
| Aguardando validação | WaitingValidation | Criado e aguardando um agente de validação |
| Em validação | InValidation | Um agente de validação está trabalhando no pedido |
| Aguardando recursos | WaitingResources | Validado, mas aguardando o resultado de verificações externas |
| Aguardando conferência | WaitingConfirmation | Aguardando um agente de conferência |
| Em conferência | InConfirmation | Um agente de conferência está revisando o pedido |
| Pendente | Pending | Devolvido para correção |
| Aguardando emissão | WaitingIssue | Aprovado; o titular já pode emitir o certificado |
| Emitido | Issued | O certificado foi emitido |
| Revogado | Revoked | O certificado foi revogado |
| Recusado | Declined | O pedido foi recusado |
| Cancelado | Canceled | O pedido foi cancelado |
Um pedido pode ser cancelado em qualquer status até a emissão do certificado, pelo painel de controle ou pela API de cancelamento. A partir de Aguardando emissão, os dados do pedido não podem mais ser alterados.
Outros caminhos
Pedidos pré-aprovados
Uma autoridade de registro eletrônica, que já validou o titular no próprio sistema, pode criar um pedido pré-aprovado. Pedidos pré-aprovados não passam pela validação nem pela conferência: começam em Aguardando emissão, e a resposta da API traz o link de emissão para o titular.
Emissão pelo agente antes da aprovação
Para certificados em dispositivos criptográficos, o tipo de certificado pode permitir que o agente emita o certificado durante o atendimento presencial, antes da aprovação do pedido. O Amplia emite o certificado pendente de aprovação. Quando o pedido é aprovado, o Amplia Reg solicita ao Amplia a aprovação do certificado e o pedido vai direto para Emitido. Se, em vez disso, o pedido for recusado, o certificado é revogado.
Revogação
Um certificado emitido pode ser revogado por um coordenador ou supervisor, que precisa apresentar uma carta de revogação assinada, ou pelo próprio titular, usando as chaves de emissão. O Amplia Reg muda o pedido para Revogado e solicita ao Amplia a revogação do certificado. O Amplia então publica a revogação nas LCRs e nas respostas OCSP.
Acompanhando o pedido pela sua aplicação
Cada mudança de status de um pedido criado pela sua aplicação pode ser enviada para uma URL de sua escolha. Veja Webhooks para os payloads.