Erro no servidor do Ambiente Nacional (RFB) ao processar o lote de notas fiscais

Erro no servidor do Ambiente Nacional (RFB) ao processar o lote de notas fiscais. (I/O error on POST request for “https://adn.nfse.gov.br/dfe”: Received fatal alert: handshake_failure; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure).

Alguém mais passando pela rejeição informada acima, ocorrendo em notas emitidas no município de Lages

Também estamos com esse erro em Lages.

Também estamos com esse Erro no servidor do Ambiente Nacional (RFB) ao processar o lote de notas fiscais. (I/O error on POST request for “https://adn.nfse.gov.br/dfe”: Received fatal alert: handshake_failure; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure)

Em Varginha

Boa tarde, pessoal! Tanto Lages-SC como Varginha utilizam a Betha como provedor.

O Emir realizou uma postagem na sexta-feira sobre as falhas ocorridas e possíveis correções, segue o link:

Falha de conexão TLS com ADN 'fatal alert: handshake_failure ', ‘bad record mac’, ‘decrypt error’ ou ‘tag mismatch’ - Geral - Nota Nacional de Serviço

Se puderem registrar acionamentos para os município de Lages e Varginha reformando a urgência da correção e questionando se os procedimentos listados pelo Emir já foram executados.

A Prefeitura respondeu dizendo que fizeram e ainda não tinham conseguido solucionar.

Uma outra alternativa citada no grupo foi de executar este comando:

curl.exe --resolve adn.nfse.gov.br:443:189.9.169.76 -v --cert “CurrentUser\My<>” https://adn.nfse.gov.br/echo

Esse comando faz um teste direto de conexão HTTPS com o ADN, forçando o domínio adn.nfse.gov.br a apontar para o IP 189.9.169.76 e usando um certificado digital instalado no Windows para autenticação mTLS.

Em partes:

  • curl.exe executa uma requisição HTTP/HTTPS pela linha de comando.
  • --resolve adn.nfse.gov.br:443:189.9.169.76 força o curl a ignorar a resolução DNS normal e conectar o domínio adn.nfse.gov.br, na porta 443, diretamente no IP 189.9.169.76.
  • -v ativa o modo verbose, exibindo detalhes da conexão, incluindo negociação TLS, certificado apresentado pelo servidor, tentativa de autenticação e erros de handshake.
  • --cert "CurrentUser\My\<<thumbprint>>" informa qual certificado do repositório de certificados do Windows deve ser usado como certificado cliente. O <<thumbprint>> deve ser substituído pela impressão digital do certificado A1/A3 correspondente.
  • https://adn.nfse.gov.br/echo chama o endpoint /echo, normalmente usado justamente para validar comunicação/conectividade.

Na prática, esse comando permite verificar se a máquina consegue estabelecer a conexão TLS/mTLS diretamente com aquele IP específico do ADN.

Por exemplo, ele ajuda a diferenciar dois cenários:

Se funcionar com --resolve, mas falhar sem ele: há um forte indício de que o problema esteja relacionado ao IP/servidor selecionado pelo DNS ou à infraestrutura de balanceamento/WAF.

Se falhar também com --resolve: o problema pode estar na negociação TLS, cadeia do certificado cliente, seleção do certificado, protocolo/cipher suportado ou configuração daquele endpoint.

Um detalhe importante: mesmo forçando o IP para 189.9.169.76, o curl continua usando adn.nfse.gov.br como hostname TLS/SNI. Isso é importante porque não é equivalente a chamar simplesmente:

https://189.9.169.76/echo

O --resolve preserva o hostname correto para validação do certificado e para o SNI, alterando somente para qual IP a conexão será enviada.

Para o caso de handshake_failure, o trecho mais importante da saída do -v será o que aparece durante o handshake TLS, antes de qualquer retorno HTTP. Se você me mandar a saída desse comando, consigo interpretar exatamente em qual etapa a conexão está falhando.

Boa noite,

As dicas passadas pelo Elcio (curl), enviadas pelo Serpro, eram para tentar identificar a falha, mas não detalha o suficiente para os casos observados. Após várias tentativas e análises, conseguiram com sucesso com as dicas apontadas no artigo acima citado pelo Elcio.

O fato é que a maioria das falhas ocorreram com quem utiliza Java ou Oracle/OJVM. Foram observados que no IP 189.9.177.202 estava passando, com erro no 189.9.169.76 e 189.9.169.76, mas na reunião do grupo hoje, todos funcionaram.

Se aplicarem para um IP somente (não deixar o DNS resolver), podem experimentar latência, pois muitos passaram a usar o final 202. Quem tinha problema, confirmou que está funcionando com todos IPs no momento.

Como descrito no artigo, a falha ocorre porque o WAF (Web Application Firewall - servidor Serpro para o ADN) encaminha toda cadeia de certificados e no lado cliente, não há resposta e o servidor encerra conexão com o erro TLS.

Quem corrigiu em java, mudaram o JAVA KeyManage.Quando o PFX contém somente o certificado A1 (certificado pfx com tamanho 3 a 4KB), sem a cadeia completa (certificado pfx 10 a 14KB), o Java pode não encontrar uma correspondência enviada pelo servidor e o cliente não apresenta o certificado cliente durante o handshake. O servidor, aguardando o certificado A1, encerra a conexão e gera o erro.

Novamente, quando um servidor solicita autenticação mútua (mTLS), ele envia um CertificateRequest contendo uma lista de Autoridades de Certificação (ACs) aceitas, se usar JAVA com o KeyManager padrão do Java, este analisa essa lista e, se o seu certificado foi assinado por uma AC que não está explicitamente na lista enviada pelo Sepror, o Java simplesmente não envia o certificado, resultando em falha de conexão (geralmente um erro de Bad Certificate ou Handshake Failure). Substituir o KeyManager padrão por um customizado resolve isso na raiz.

Hoje apontaram que existem problemas ainda, com aplicações em PHP, por exemplo, mas quem alterou em JAVA ou usou a cadeia comple, funcionou. Não temos detalhes de quem está com problema, que linguagem ou SO está usando…

Algumas abordagens, como salvar o PFX completo (10 a 14KB de tamanho PFX) e tentar a comunicação, resolveu para muitos, mas novamente depende do ambiente do cliente.

Os servidores no Serpro estão com TLS1.2 e TLS1.3 (experimental) habilitados, mas tendo suporte para o TLS1.2, deveria funcionar no quesito protocolo, não a comunicação em si com o WAP. Inspecione se o certificado foi exportado com todas propriedade estendidas para gerar o PFX com tamanho 10 a 14KB e tentar a comunicação.

Não ficou claro quais ajustes fizeram e qual Sistema Operacional (Windows versão e/ou Linux) e se estão usando JAVA.

Informem por gentileza o ambiente e sistema para ficar claro.

At.te

Emir Toktar