Como É Assinada A Nf E

O processo de assinatura na NFC-e não é tão simples quanto a SEFAZ deixa entender

A NFC-e precisa de assinatura digital para ter validade fiscal. Isso significa que cada nota transmitida carrega um certificado digital ICP-Brasil que garante autenticidade e integridade. Sem isso, a nota simplesmente não sai do seu sistema para a Secretaria da Fazenda. O mecanismo em si é padrão para toda a NF-e brasileira, mas existem detalhes práticos que causam problema todo dia. O processo funciona assim. Você prepara o XML da NFC-e com todos os campos obrigatórios, calcula o hash da nota (o que é basicamente um digest criptográfico dos dados), e então aplica a assinatura usando o certificado digital A1 ou A3. A assinatura fica embutida no próprio XML como um bloco Signature no padrão XML-Signature. Quando o sistema envia para a SEFAZ, ele transmete esse XML já assinado. A SEFAZ valida a assinatura, verifica se o certificado está vigente e se não foi revogado, e só então autoriza o uso. Em termos técnicos, a assinatura usa RSA com SHA-1 ou SHA-256 dependendo da versão do padrão e do estado. A maioria dos estados já migrou para SHA-256. O certificado precisa ser do tipo A1 (arquivo pfx com senha) ou A3 (smart card ou token). O A1 é mais barato e fácil de gerenciar, mas o A3 é considerado mais seguro porque a chave privada nunca sai do dispositivo físico.

Certa vez, uma empresa meligou o certificado A1 dela para renovar sem atualizar a cadeia de trust no sistema deles. O resultado foi que todas as NFC-e que eles emitiram durante duas semanas foram rejeitadas pela SEFAZ com erro de validação de assinatura. Eles não perceberam porque o sistema deles não fazia validação local antes do envio. A solução foi trocar o certificado novamente, atualizar os arquivos de certificado raiz no servidor, e reemitir as notas rejeitadas. Isso custou aproximadamente um dia de trabalho parado para o departamento fiscal deles.

Componentes necessários

Você precisa de pelo menos três coisas para assinar uma NFC-e corretamente. Primeiro, o certificado digital ICP-Brasil válido, emitido por uma Autoridade Certificadora credenciada. Segundo, um sistema emitidor que consiga calcular o hash e aplicar a assinatura digital no XML. Terceiro, os certificados de raiz e intermediários da AC que emitiu seu certificado, instalados no ambiente onde a assinatura é processada. A maioria dos desenvolvedores subestima o terceiro ponto. O Windows e o Linux trazem repositórios de certificados confiáveis atualizados, mas servidores de produção muitas vezes rodam com repositórios desatualizados. Quando a SEFAZ renova a cadeia de certificação, como aconteceu recentemente com a Certisign e a Serasa, notas que funcionavam perfeitamente começam a falhar sem aviso prévio. Verifique periodicamente se os certificados intermediários estão presentes no seu repositório. Existem bibliotecas padrão em praticamente todas as linguagens. Em Java, o Bouncy Castle resolve. Em C#, a classe X509Certificate2 com SignedXml faz o trabalho. Para quem usa Python, a biblioteca xmlsec ou lxml com suporte a assinantura XML são as opções mais comuns. A maioria dos sistemas emitidores comerciais já embute tudo isso, mas se você está construindo algo do zero ou integrando via API, conhece os detalhes ajuda muito quando alguma coisa quebra.

Pontos onde as pessoas erram

O erro mais comum é assinar o XML errado. O XML que você assina precisa ser exatamente o que vai ser enviado. Se algum campo for modificado depois da assinatura, mesmo que seja um espaço em branco removido ou uma data formatada de forma diferente, a assinatura perde a validade. Muitos desenvolvedores cometem isso ao fazer pretty print ou reformatar o XML após a assinatura para fins de log, sem perceber que a formatação altera o conteúdo assinado. Outro problema frequente é a validade do certificado. O certificado pode estar tecnicamente válido, mas se a OCSP ou o CRL da AC estiver indisponível no momento da validação pela SEFAZ, a nota pode ser rejeitada. Isso acontece principalmente com ACs menores que têm infraestrutura de revogação mais frágil. Eu recomendo usar certificados de ACs grandes como Certisign, Certsign, Valid, Serasa, ou Boa Vista. A diferença de preço é irrelevante perto do transtorno de nota rejeitada. Uma particularidade da NFC-e é que ela tem timeout de autorização muito curto em alguns estados. A SEFAZ de São Paulo, por exemplo, exige que a NFC-e seja transmitida e autorizada rapidamente, e se o tempo de processamento da assinatura for muito alto devido a problemas de configuração do certificado ou do hardware, você pode perder a janela de transmissão. Em sistemas com carga alta, isso já me causou problema real: o token A3 estava gerando latência porque o driver não estava atualizado, e as notas estavam expirando antes de serem autorizadas. Atualizei o driver e o tempo médio de transmissão caiu de cerca de 8 segundos para 2 segundos.

Validação pós-assinatura

Antes de enviar para a SEFAZ, valide a assinatura localmente. Usar ferramentas como o Assinador NFS-e da Receita, ou bibliotecas de validação XML-Signature, permite detectar problemas de assinatura antes que a nota seja rejeitada pela SEFAZ e gere trabalho adicional. Validação local leva poucos segundos e evita retrabalho. O log de eventos também é importante. Mantenha registro do XML assinado, do certificado usado, do horário de assinatura e do resultado da transmissão. Se houver qualquer problema futuro com uma nota, esse registro é a única coisa que vai permitir investigar se a assinatura era válida no momento do envio ou se houve alguma alteração posterior nos dados. A assinatura da NFC-e é um processo bem definido, mas os detalhes de implementação e manutenção é que causam dor de cabeça no dia a dia. O essencial é ter o certificado certo, a assinatura no XML certo, e validação local antes do envio. O resto é ajuste fino de infraestrutura.