Pular para o conteúdo
Fiscal ProBiblioteca
Rejeição 280 · Regra A01

Rejeição 280: certificado do transmissor inválido no TLS

Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.

A rejeição 280, regra A01, trata do certificado apresentado pelo aplicativo ao abrir a conexão TLS com os serviços da NF-e e da NFC-e. A primeira conferência é identificar qual certificado o processo de transmissão realmente selecionou. O certificado que aparece na assinatura do XML pode ser outro.

Nesta página:

O que torna o certificado inadequado para a transmissão?

A01 reúne ausência do certificado do transmissor, versão X.509 diferente de 3 e falta de finalidade de autenticação de cliente. A versão X.509 não é a versão 4.00 do leiaute da NF-e nem a versão TLS. O MOC Visão Geral exige autenticação mútua por TLS 1.2 ou superior e identifica a permissão de autenticação de cliente em Extended Key Usage.

O Anexo I usa a palavra KeyUsage nessa linha; a Visão Geral distingue a extensão de uso estendido. É preciso conferir o perfil completo com a autoridade certificadora, sem transformar uma tradução do erro em ordem para editar o certificado.

Fontes: MOC Anexo I, regra A01.

Como interpretar a contradição sobre Basic Constraints?

A tabela A01 escreve “true” ao lado de “não pode ser Certificado de AC”. Essas duas indicações não devem ser convertidas em uma instrução de configuração. O DOC-ICP-04 consolidado, Anexo I, apresenta cA=False nos perfis de usuário final. A Visão Geral do MOC também exige certificado de usuário final.

Assim, não substitua o certificado do titular pelo de uma AC e não modifique extensões para tentar passar na validação. Se o diagnóstico depender desse ponto, encaminhe à AC ou ao integrador a versão do manual, a finalidade do certificado e o erro técnico, preservando o arquivo e a chave privada.

Fontes: MOC Anexo I, regra A01; DOC-ICP-04 - Requisitos mínimos para políticas de certificado.

Exemplo: certificado instalado e certificado selecionado

Em um cenário hipotético, o painel administrativo mostra um certificado de usuário final válido, mas o serviço executado em outra conta seleciona uma entrada de repositório destinada a outra finalidade. Instalação bem-sucedida não comprova apresentação no TLS. Compare a identidade técnica do certificado selecionado pelo processo, a configuração do cliente HTTP e o registro da negociação em canal protegido. A evidência precisa relacionar o erro à conexão que falhou.

A correção pertence à seleção ou à instalação comprovadamente incorreta; não aos campos de produto, tributos ou emitente do documento. Depois, valide a configuração sem suprimir verificações de segurança.

Fontes: MOC Anexo I, regra A01.

O erro 280 comprova que a nota foi rejeitada?

O MOC informa que A01 a A05 são verificações realizadas pelo próprio TLS. Uma falha de negociação pode impedir o recebimento de um retorno fiscal estruturado. Guarde separadamente erro TLS, eventual cStat e resultado do documento. Se houve tentativa anterior com resposta perdida, consulte seu estado antes de decidir por novo envio. A 290 trata do certificado da assinatura XML; sua causa não deve ser deduzida da 280.

Fontes: MOC Anexo I, regra A01.

Limite do exemplo e preservação dos dados

Um exemplo de certificado ou conexão TLS exigiria credenciais operacionais. A comparação textual mostra o diagnóstico sem fabricar certificado, assinatura ou XML transmissível. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.

Fontes oficiais