Rejeição 856: assinatura RSA inválida na emissão por PAA

Quando o retorno 856 informa que a emissão por PAA tem assinatura RSA inválida, a investigação pertence ao fluxo de assinatura do provedor. A NT 2026.001 PAA v1.02b manda validar SignatureValue com a chave pública do emitente apresentada em RSAKeyValue, no grupo de informações de PAA. O código não significa, nesse contexto, que falta um valor de combustível ou que basta renovar o certificado digital.

Comece preservando a descrição completa do retorno e identificando se houve rejeição de autorização ou de evento. Existem materiais antigos que associam 856 ao campo vPart do GLP. A regra histórica desse campo foi excluída na NT 2023.001. Usar apenas o número para escolher a correção pode levar a alterar informações fiscais sem relação com a causa efetiva.

O que deve ser validado

Na autorização, a ZG04-10 é documentada com modelos 55/65, aplicação obrigatória e implementação somente na SVRS. Sua condição é a presença de infPAA; a verificação consiste em validar a assinatura RSA com a chave pública do emitente. Na versão inspecionada, o código anterior 1184 está riscado e 856 permanece como código da rejeição.

No serviço de eventos, a P83-10 apresenta a mesma verificação, para modelo 55, aplicação obrigatória e somente SVRS. Analise a mensagem de evento que foi enviada, e não apenas o XML de autorização da nota. Os arquivos têm identificadores e assinaturas próprios; uma autorização bem-sucedida não demonstra que a geração do evento esteja correta.

A referência a 55/65 na linha de autorização não libera qualquer emissão de NFC-e por PAA. O documento contém outras restrições, incluindo a regra sobre modelo 65 e séries reservadas ao fluxo. Tampouco a classificação obrigatória permite presumir que todos os autorizadores executem a regra: a observação de implementação somente na SVRS integra o seu alcance documental.

Há duas assinaturas com funções diferentes

A nota técnica descreve uma assinatura RSA vinculada ao emitente e uma assinatura do documento com certificado ICP-Brasil do PAA. Na assinatura interna, o identificador Id da NF-e ou do evento participa da geração de SignatureValue; a chave pública correspondente é informada em RSAKeyValue. Depois, o provedor executa a assinatura com seu certificado no fluxo estabelecido.

Por isso, conferir somente validade, senha ou instalação do certificado ICP-Brasil não comprova a integridade da assinatura RSA interna. A rejeição 776 aborda a identidade do certificado em relação ao provedor, enquanto a 895 possui uma conferência própria da chave pública cadastrada para a relação entre PAA e emitente. São verificações distintas, embora o atendimento possa precisar investigar a mesma configuração de integração.

Uma hipótese técnica a conferir é a reutilização de um bloco de assinatura gerado para outro identificador. Se a integração montar um novo documento e conservar o bloco anterior, a assinatura poderá deixar de corresponder ao conteúdo que a regra verifica. Outra hipótese é selecionar um par de chaves diferente do previsto para a relação legítima. Essas possibilidades orientam a coleta de evidências; não constituem diagnóstico confirmado sem examinar a mensagem rejeitada.

Como encaminhar a correção

1. Registre cStat, mensagem, serviço, ambiente, modelo, horário e versão do componente. Preserve o XML efetivamente transmitido e o retorno associado. Havendo dúvida sobre o resultado de um envio, consulte a situação antes de reenviar.

2. Peça ao responsável técnico pela integração que confira o Id usado na geração da assinatura e o identificador do documento enviado. A análise deve usar o arquivo real, sem tomar um exemplo de documentação como prova do que o sistema transmitiu.

3. Verifique a coerência entre a assinatura interna, a chave pública informada e o par de chaves obtido no procedimento legítimo de vínculo. Eventuais correções de cadastro ou vigência exigem evidência específica; não crie ou substitua chaves apenas por tentativa.

4. Se houver falha de geração, corrija o componente e regenere a mensagem pelo fluxo completo. Não edite a assinatura manualmente, copie blocos de outro documento ou exponha chave privada e senha em chamado de suporte.

5. Reavalie o retorno e confirme o protocolo de autorização ou de registro do evento. Passar por esta validação não garante aprovação das demais regras. O conteúdo fiscal deve continuar representando a operação verdadeira.

Por que algumas páginas falam em GLP

O MOC 7.0, página 97, registra a antiga LA03d-10: obrigatoriedade de vPart para o produto GLP com cProdANP=210203001, modelo 55, código 856. Já a NT 2023.001 v1.60, seção 2.6.6, explica a exclusão dessa regra. Na página 29, a linha histórica aparece integralmente riscada.

Assim, uma ficha antiga não sustenta recomendar o preenchimento obrigatório desse campo na situação atual. Se o retorno literal ainda mencionar valor de partida, identifique autorizador, ambiente, versão e mensagem original para investigação de compatibilidade. Não preencha zero, altere o produto ou mude sua classificação para tentar resolver uma falha de assinatura RSA. Cada hipótese precisa ser confrontada com a regra efetivamente aplicável.

O que informar ao suporte

Relate se houve troca de provedor, atualização, alteração no vínculo ou mudança no componente de assinatura. Entregue os arquivos necessários por canal autorizado, preservando as credenciais, e indique em qual etapa a rejeição ocorreu. Esta orientação não demonstra a existência de configuração específica no ALRA nem substitui a análise do componente que gerou a mensagem.

O cronograma da página 3 do PAA registra homologação em 03/08/2026 e produção em 05/10/2026 para a versão 1.02; 1.02a e 1.02b não trazem novas datas. As datas não comprovam habilitação de emitente ou implantação individual. A correção só pode ser confirmada após o retorno conclusivo do serviço correspondente.

Fontes e limites

Pesquisa em 15/10/2026, horário de Brasília. As capturas oficiais desse dia foram reutilizadas por identidade; as páginas de apoio tiveram captura direta nesse mesmo dia. Não houve teste de emissão, evento, validação criptográfica ou demonstração de configuração do ALRA.

• NT 2026.001 PAA v1.02b: PDF 703310, HTTP 200 em 16/10 às 00:10 UTC, correspondente a 15/10 no Brasil. Páginas 3 a 7 e 10 a 18 efetivamente lidas para o conjunto; PNGs existentes 3, 10, 12, 13, 14, 17 e 18 pessoalmente vistos. ZG02-40/776 e ZG04-10/856 na página 14, P81-50/776 e P83-10/856 na 18. Códigos anteriores e exceção riscada não foram apresentados como vigentes. Cronograma da página 3 não comprova implantação individual.

• Índice da SVRS: entrada da v1.02b de 29/07/2026 na captura de 15/10. A data 31/07 apresentada pelo apoio ATVI não foi adotada em substituição. A busca nos seis caches de NTs de 2026 não encontrou os alvos deste conjunto; isso não certifica ausência de qualquer atualização externa.

• MOC 7.0 Anexo I: PDF 5eb4cf, captura HTTP 200 de 15/10 reutilizada. Páginas 73 e 97 lidas integralmente por extração, sem alegar inspeção visual dessas duas páginas. Uso histórico separado: GAP03a-2 facultativa/776 e LA03d-10 obrigatória/55/856. Não prova ativação atual de regra antiga.

• NT 2023.001 v1.60: PDF 2b18d9 HTTP 200 de 15/10 reutilizado. Página 16 inteira lida e PNG existente da 29 pessoalmente visto nesta redação: exclusão expressa da LA03d-10. Não transportar a regra antiga do GLP para a assinatura RSA.

• Schemas oficiais: pacote 010f e declaração integral de infPAA no leiaute, com CNPJPAA, SignatureValue e RSAKeyValue, lidos como apoio estrutural. Não houve compilação de XSD, validação do evento por XSD ou de XML real.

• Buscador NCM 856: ficha HTTP 200, corpo específico lido, conferência editorial de 12/10 e consolidação de 09/10. Mistura o significado histórico com a regra de PAA e rotula esta como todas as UFs, contrariando a observação SVRS que ela mesma transcreve. Para 856, a orientação genérica de conferir totais não é solução da assinatura; para 776, não generalizar a facultatividade histórica para a regra obrigatória de PAA. Generalizações sobre denegação, numeração e outros documentos não foram adotadas.

• TecnoSpeed PAA: panorama de 29/07/2026, HTTP 200 e trecho WEB pertinente efetivamente lidos. Grupo, fluxo e duas assinaturas contextualizados. Séries 970–979, B26-20 e códigos substituídos preservados como divergências do apoio, sem adoção contra o PDF. Garantias de produto e referências legais indiretas não demonstram suporte no ALRA.

• ATVI PAA: corpo técnico HTTP 200 inteiro lido; panorama da v1.02b, com descrição de chaves, grupo e assinaturas. Sua data editorial diverge da entrada SVRS; não substitui o cronograma oficial nem comprova habilitação individual.

Há três editores com material pertinente, uma ficha e dois panoramas gerais de PAA; não foram encontrados três tutoriais completos exclusivos da rejeição 856. As hipóteses técnicas são encaminhamentos para verificação, não diagnóstico de uma integração real. Não foram processadas credenciais, alterados dados fiscais ou geradas imagens, capas e publicação.