ICP-Brasil A1 ou A3: qual usar para emitir NF-e no Odoo

Toda nota fiscal eletrônica brasileira é assinada com um certificado digital ICP-Brasil. Sem ele, o XML não é aceito pelo SEFAZ — não emite NF-e, não emite NFS-e, não fecha eSocial, não envia Reinf. A escolha entre A1 e A3 parece pequena, mas afeta operação, segurança, automação e custo.

A KMEE participa da manutenção da OCA Brasil há mais de 14 anos e já configurou certificados digitais em centenas de implementações Odoo. Este post resume o que importa na hora de escolher e como o Odoo lida com cada modelo.

A diferença fundamental

Os certificados ICP-Brasil para pessoa jurídica vêm em duas categorias técnicas (definidas pelo ITI — Instituto Nacional de Tecnologia da Informação):

A1 — certificado em arquivo

• Mídia: arquivo .pfx (ou .p12), protegido por senha.
• Validade: 1 ano.
• Custo: mais barato (R$ 150 a R$ 300 por ano em média).
• Operação: pode ser instalado em servidor, replicado, usado por múltiplos sistemas simultaneamente.
• Risco: o arquivo é o certificado — se vazar, o atacante pode assinar documentos em nome da empresa até a revogação.

A3 — certificado em token/cartão físico

• Mídia: token USB, smartcard ou HSM (hardware security module).
• Validade: 3 anos (alguns modelos chegam a 5).
• Custo: mais caro (R$ 250 a R$ 500 + valor da mídia, R$ 80 a R$ 200).
• Operação: a chave privada nunca sai do hardware. As assinaturas são feitas dentro do dispositivo, que apenas devolve o resultado.
• Risco: se o token é roubado, ainda é necessário o PIN. Mas o sistema que usa o A3 precisa de acesso físico ao token — o que complica automação.

Para emitir NF-e em servidor Odoo: A1 quase sempre

Para um ERP que emite NF-e em servidor (especialmente em nuvem — Vercel, AWS, GCP, Odoo SH, Doodba), o A1 é praticamente obrigatório. Razões práticas:

• Servidor não tem porta USB (ou tem, mas você não vai colocar um token físico em um datacenter).
• Múltiplas filiais podem precisar emitir simultaneamente — A1 replicado funciona; A3 exigiria um token por servidor.
• Backups e DR dependem de poder copiar o certificado — A3 não pode ser copiado por design.
• Alta volumetria (milhares de NF-e por dia) é incompatível com a latência de comunicação serial com tokens físicos.

A3 faz sentido para profissionais autônomos (contadores, advogados) que assinam documentos pontualmente em sua máquina pessoal. Para emissão de NF-e em ERP, A1.

Como o Odoo armazena o certificado

A frente de certificado digital na OCA Brasil é coberta pelo módulo l10n_br_fiscal_certificate (https://github.com/OCA/l10n-brazil/tree/16.0/l10n_br_fiscal_certificate). O modelo principal é l10n_br_fiscal.certificate, com:

• Subtype — A1 ou A3 (no Odoo, A3 só é suportado em cenários muito específicos).
• File — campo binário Binary armazenando o .pfx criptografado no banco.
• Password — senha do PFX, criptografada com a master_password do Odoo.
• Date start / Date end — extraídas do certificado via cryptography lib.
• Issuer / Subject / CNPJ — extraídos da chain do certificado.

Quando uma NF-e é emitida, o módulo l10n_br_nfe carrega o certificado em memória, assina o XML com signxml ou pyOpenSSL, e descarta a chave da memória. Tudo passa pelo l10n_br_fiscal.certificate, então um único cadastro alimenta NF-e, NFS-e, CT-e, MDF-e, eSocial, Reinf — desde que o CNPJ bata.

Vault externo: a opção avançada

Para empresas que querem o melhor dos dois mundos — segurança alta + automação possível —, existe a opção de vault externo:

• HSM em nuvem (AWS CloudHSM, Azure Key Vault, GCP Cloud HSM): a chave fica em hardware criptográfico gerenciado, e o Odoo chama uma API de assinatura.
• Certificadora com API (algumas certificadoras oferecem assinatura remota como serviço, com OAuth e callback).
• Token A3 em servidor dedicado (PKCS#11 + middleware): possível, mas frágil — qualquer reboot requer reinserção do PIN.

Esses cenários exigem desenvolvimento sob medida — o l10n_br_fiscal_certificate padrão assume A1 em arquivo. Para clientes em setores muito regulados (financeiro, governo), a KMEE já implementou integrações de assinatura via vault externo, mas é exceção, não regra.

Renovação: o ponto fraco do A1

O A1 vence em 1 ano. Se vencer e não for renovado, a emissão para imediatamente — SEFAZ rejeita o XML. Cuidados práticos:

• Cron job no Odoo que checa todo dia a date_end dos certificados ativos e dispara alerta 30/15/7 dias antes do vencimento.
• Renovação contratada com 30 dias de antecedência — algumas certificadoras demoram dias para emitir.
• Janela de troca — substituir o certificado em produção exige um pequeno downtime fiscal (basicamente, o tempo de fazer upload do novo .pfx, conferir CNPJ e ativar).

Cuidados de segurança

• A senha do PFX nunca em texto plano em variável de ambiente — usar a master_password do Odoo ou um secret manager.
• Backups do banco contêm o certificado — proteger com criptografia em repouso.
• Acesso ao formulário l10n_br_fiscal.certificate restrito a usuários do grupo Manager Fiscal.
• Logs — toda assinatura de XML deveria logar (sem o conteúdo do certificado) qual certificate_id foi usado, para auditoria.

Conclusão

Para emissão de NF-e em servidor Odoo, A1 é o caminho padrão. A3 só faz sentido em cenários muito específicos. O importante é tratar o certificado como o que ele é — uma identidade digital corporativa, com mesmo peso jurídico que uma assinatura em papel.

Para o panorama da localização fiscal Odoo, veja Localização Fiscal Brasileira no Odoo e o Glossário Fiscal. Para o que vem aí em 2026, veja Reforma Tributária Odoo 2026.