# Modelo de Posse do Certificado

## Decisao recomendada

A prefeitura nao deve entregar livremente o certificado digital e senha para terceiros como se fosse um arquivo comum do projeto. O certificado representa identidade digital do orgao/municipio e permite autenticacao perante sistemas fiscais.

Modelo recomendado:

1. O motor roda em infraestrutura controlada pela prefeitura ou pelo cliente autorizado.
2. O certificado A1 fica criptografado no banco novo do motor.
3. A senha do `.pfx` fica criptografada no banco.
4. A chave mestra para descriptografar certificado e senha fica fora do banco, em variavel de ambiente, arquivo protegido ou cofre controlado pelo cliente.
5. O fornecedor do software pode instalar, configurar e dar suporte, mas nao precisa manter copia permanente do certificado.

## Alternativas de arquitetura

### Opcao A: Motor na VPS do cliente

Mais simples para o MVP.

```text
VPS do cliente/prefeitura
  motor Python
  certificado A1 criptografado no banco
  senha criptografada no banco
  chave mestra fora do banco
  conexao mTLS com ADN
  MySQL 5.6 do motor
```

Vantagens:

- Implementacao direta.
- Compatibilidade com mTLS via arquivo `.pfx`.
- Nao exige Docker em producao.

Cuidados:

- Controle rigoroso da chave mestra.
- Usuario de sistema exclusivo.
- Backup do banco passa a conter certificados criptografados.
- Registro formal de quem tem acesso ao servidor.

### Opcao B: Agente local/proxy de certificado

Boa quando o software principal roda fora da prefeitura, mas o certificado nao deve sair do ambiente dela.

```text
Servidor do fornecedor
  solicita sincronizacao

Ambiente da prefeitura
  agente/proxy com certificado
  chama ADN com mTLS
  devolve resposta ao sistema autorizado
```

Vantagens:

- O certificado fica no ambiente da prefeitura.
- Reduz exposicao do certificado ao fornecedor.

Custos:

- Mais infraestrutura.
- Mais pontos de falha.
- Precisa autenticar e auditar a comunicacao entre sistema e proxy.

### Opcao C: Certificado em nuvem/HSM/servico remoto

Possivel apenas se o provedor permitir uso da chave privada em autenticacao TLS de cliente ou disponibilizar integracao compativel com a biblioteca usada pelo motor.

Ponto critico:

- A API do ADN exige certificado cliente na conexao TLS. Nao basta assinar um payload separado; a chave precisa participar do handshake mTLS.

## Sobre "certificado v1"

No contexto brasileiro, o termo comum provavelmente e `A1`, nao `v1`.

- `A1`: certificado em arquivo, normalmente `.pfx` ou `.p12`, adequado para servidor/worker.
- `A3`: certificado em token/cartao/dispositivo, mais dificil para rotinas automaticas em VPS.

Para este motor, a premissa tecnica inicial e certificado `A1` em formato `.pfx`.

## O que pedir para a prefeitura

Para homologacao real:

- certificado digital A1 do municipio/prefeitura autorizado no ambiente de producao restrita;
- arquivo `.pfx` e senha cadastrados no sistema para armazenamento criptografado;
- chave mestra configurada fora do banco pelo responsavel pelo ambiente;
- confirmacao do perfil de uso: municipio, contribuinte ou outro;
- codigo IBGE do municipio;
- ambiente alvo: producao restrita primeiro, producao depois;
- autorizacao formal para uso do certificado no motor.

## O que nao pedir como padrao

- Envio de certificado por email comum.
- Senha no mesmo canal do arquivo.
- Copia permanente do certificado no computador do fornecedor.
- Certificado A3 se a execucao esperada for um worker automatico em VPS sem operador.