Assinatura Digital: assinar com certificado digital — o do signatário (A1/WebPKI) e o do sistema

POR QUE ESTA FONTE EXISTE

A palavra "certificado" aparece em três lugares diferentes e o atendimento erra quando não separa qual é qual. Um é o certificado da NOTA FISCAL, que assina a nota e conversa com a SEFAZ: é assunto das fontes fiscais e não tem relação com o que está aqui. Os outros dois são da Assinatura Digital e são estes.

O CERTIFICADO DO SISTEMA

É o certificado que o próprio sistema aplica por cima do PDF depois de juntar o documento, a página de assinaturas e a página de logs. É ele que faz o leitor de PDF mostrar o arquivo como assinado digitalmente. Você não configura nada, não envia arquivo nenhum e não precisa ter certificado para isso. Ele entra no fluxo comum de assinatura, aquele em que o signatário se identifica por e-mail, token, selfie ou foto do documento.

O CERTIFICADO DO SIGNATÁRIO

É outra coisa. É uma FORMA DE AUTENTICAÇÃO escolhida por signatário, no cadastro do documento, ao lado dos outros canais. A autenticação de cada signatário é uma lista e aceita mais de um item, então certificado digital pode conviver com e-mail, WhatsApp ou SMS. Quando o signatário está marcado com certificado digital, a assinatura dele segue um caminho próprio: quem assina o PDF é o certificado DELE.

A consequência prática contraria material antigo: nesse fluxo o certificado do sistema NÃO é aplicado. O arquivo sai assinado pelo certificado do próprio signatário.

CAMINHO A — ENVIAR O ARQUIVO .PFX OU .P12

O signatário envia o arquivo do certificado e a senha, e o sistema confere na hora. Só duas extensões são aceitas, e a lista é fechada: .pfx e .p12. As recusas são "O certificado digital (.pfx ou .p12) é obrigatório.", "O certificado deve ser um arquivo .pfx ou .p12.", "A senha do certificado é obrigatória." e "Senha incorreta ou certificado inválido. Verifique e tente novamente.".

A validade é conferida nas duas pontas. Vencido: "Este certificado expirou em {data} (Horário de Brasília).". Ainda não válido, caso de certificado recém-emitido com início no futuro: "Operação bloqueada: Este certificado só é válido a partir de {data}.". Passando, o sistema mostra o nome do titular e a data de validade lidos de dentro do próprio certificado. Se o cliente achar que a data está errada, quem diz aquilo é o certificado, não o sistema.

Na hora de assinar o certificado é conferido de novo. As falhas dessa etapa são "Certificado inválido ou senha incorreta. Não foi possível assinar o documento.", "Certificado digital não fornecido. Recarregue a página e tente novamente." e "Erro ao aplicar o certificado digital no documento.".

CAMINHO B — CERTIFICADO INSTALADO NA MÁQUINA OU EM TOKEN (WEBPKI)

Aqui o arquivo do certificado nunca sai da máquina do signatário, e por isso a assinatura acontece em duas fases. Primeiro o servidor monta o PDF completo e devolve um resumo (hash) para o navegador. Depois o navegador assina esse resumo com o certificado instalado e devolve a assinatura, e o servidor a embute no PDF.

O detalhe que gera chamado: a preparação da primeira fase fica guardada por 5 minutos. Passou disso, vem "Sessão de assinatura expirada. Recarregue a página e tente novamente.". Procurar o certificado na lista, digitar o PIN do token com calma ou atender o telefone no meio do caminho estoura esse tempo. Se o signatário não estiver marcado com certificado, a preparação recusa com "Este documento não utiliza certificado digital.". Falhas gerais das duas fases aparecem como "Erro ao preparar assinatura com certificado digital." e "Erro ao finalizar assinatura com certificado digital.".

A ARMADILHA DA SEGUNDA TENTATIVA

Nos dois caminhos a assinatura do signatário é gravada ANTES de o arquivo assinado ficar pronto. Se algo falhar depois desse ponto — a sessão de 5 minutos estourar, o navegador fechar, o PIN não ser digitado, o certificado ser recusado na aplicação —, aquele signatário já consta como assinado e a nova tentativa responde "O documento já está assinado.", mesmo que o arquivo assinado não tenha sido gerado.

Não prometa que basta recomeçar. Colete o documento, o signatário, o caminho usado e a mensagem exata das duas tentativas e escale.

NUNCA PEÇA A SENHA DO CERTIFICADO

Não peça, não repita e não aceite a senha do certificado no atendimento, em nenhuma hipótese. O mesmo vale para o arquivo .pfx. Se o cliente colar a senha na conversa, avise que ela passa a ser considerada comprometida e oriente trocá-la ou reemitir o certificado junto a quem emitiu.

O QUE COSTUMA DAR ERRADO

"A senha está certa e o sistema diz incorreta": quase sempre é espaço no começo ou no fim do que foi colado, senha de outro certificado, ou arquivo exportado sem a chave privada. As três caem na mesma mensagem.
"Meu certificado é .cer, .crt ou .pem": não serve. A lista é fechada em .pfx e .p12.
"Deu sessão expirada no meio do processo": é o caminho WebPKI e os 5 minutos. Antes de mandar tentar de novo, confira se o signatário não ficou marcado como assinado — se a nova tentativa responder "O documento já está assinado.", escale.
"Não aparece a opção de certificado": aquele signatário não está marcado com certificado digital naquele documento.
"O PDF não mostra o certificado do sistema": em documento assinado com certificado do signatário é o dele que vale, e é assim mesmo.

O QUE NÃO DÁ PARA AFIRMAR

Onde exatamente se liga a exigência de certificado no cadastro do documento não está comprovado no backend: o formulário é do aplicativo. Diga que a escolha é por signatário, ofereça verificar e não invente nome de campo, aba ou botão. Emissão, renovação, troca de senha e desbloqueio do certificado são com a certificadora que emitiu.