Entretanto, ao realizar o envio ocorre o seguinte erro:
Status: 400
Resposta: {“tipoAmbiente”:2,“versaoAplicativo”:“SefinNac_Pre_1.4.0”,“dataHoraProcessamento”:“2025-11-18T15:34:47.51714-03:00”,“idDPS”:“DPS261160621121462400012800900000000000000005”,“erros”:[{“Codigo”:“E0714”,“Descricao”:“Arquivo enviado com erro na assinatura.”}]}
Quais os procedimentos que devemos realizar para assinatura do XML?
Quais as especificações para a assinatura do XML?
Qual a função criptográfica assimétrica? rsa-sha1?
Qual a função de “message digest”? rsa-sha1?
Qual o método “CanonicalizationMethod”? é o “REC-xml-c14n-20010315”?
Como posso garantir que o CanonicalizationMethod não tenha conflitos quando decodificado pelo serviço da Receita?
Estou passando por algo semelhante. Segui estritamente o xsd e suas validações. Meu principal ponto de dúvida é o CanonicalizationMethod, uso o Algoritmo Canonical XML, entretanto não tenho certeza se é a abordagem correta.
Também recebo como response http 400 Código E0714
Temos algum lugar para testar, avaliar o XML gerado? Meu sistema gera o XML do DPS automaticamente, assina sempre com a mesma assinatura, mesmas rotinas, mesmo assim, ontem à noite foram aceitas todas as notas menos uma, com E0714 (ambiente de produção). Estou tentando avaliar o que tem de diferente nessa para justificar esse problema.
https://validar.iti.gov.br : assinatura é válida, qualificada, no CNPJ da empresa emissora Verification of electronic signatures and seals – VerifySignature.eu : o xml está adequadamente assinado com o certificado proposto (o site diz que tem algumas questões com o emissor do certificado ICP Brasil, falha na lista de certificados revogados, mas a validade foi comprovada no site anterior e falta de data de assinatura, que não é um requisito)
Todos os XML gerados apresentam exatamente o mesmo diagnóstico, mas essa DPS específica é recusada com E0714.
Descobri o problema no meu caso, não tinha nada a ver com assinatura propriamente dita, que estava correta. Na verdade, havia um problema de mal formação de um campo. O campo de descrição do serviço “xDescServ” permite quebra de linha normal, mas meu sistema falhou em verificar algum dado e um caráter Carriage Return (13) foi inserido e registrado no XML como o que provocou erro no tratamento do XML do lado do Portal. Removendo e regerando o XML do DPS, passou sem problemas.
Como falei acima, esse erro pode ser gerado por problemas de caracteres inválidos no XML que, por algum motivo, não são detectados pela verificação do esquema, mas o verificador de assinatura da API gera algum erro.
Mesmo assim, com relação à correta assinatura do seu XML, é importante ressaltar o seguinte:
A porção a ser assinada é somente o elemento <infDPS> (se assinar todo o documento ou o elemento root <DPS>, o sistema vai rejeitar). Portanto, o Id=“DPSxxxxx…” do elemento <infDPS> vai estar na referência da assinatura:
Você pode testar se está usando o certificado correto da empresa emissora e-CNPJ autorizado verificando o arquivo .xml em https://validar.iti.gov.br. A assinatura precisar retornar como válida e qualificada (certificado e-CNPJ/CPF corretamente utilizado), além disso, precisa retornar a informação “Assinatura aprovada”.