Muito obrigada.
Vou encaminhar
Boa tarde Senhores
Houve uma atualização de cadeias de Certificados.
Peço que testem novamente e, se persistir algum problema, reportem a cadeia de certificado que não está passando.
Pessoal, tive um retorno da equipe da NFS-e sobre o erro cURL error 56: OpenSSL SSL_read… decryption failed or bad record mac.
Segundo eles, o erro não está relacionado à rejeição fiscal ou às regras de validação do XML, mas sim a uma falha na camada de comunicação SSL/TLS durante o mTLS com o ADN.
Como possíveis causas e pontos de verificação, recomendaram:
- utilização de TLS 1.2 ou superior;
- desativação de conexões persistentes (Connection: close);
- configuração adequada dos timeouts do cURL;
- verificar se firewall/proxy está fazendo inspeção SSL/TLS e, se estiver, criar uma exceção para o adn.nfse.gov.br;
- verificar se o servidor possui acesso às LCRs das Autoridades Certificadoras;
- conferir a cadeia de certificação;
- e implementar retentativas automáticas para erros de rede, como o cURL error 56.
Eles também informaram que outros emissores próprios estão apresentando esse tipo de comportamento intermitente.
Aqui ainda não fiz alterações no ambiente, pois estamos investigando as possíveis causas. O fato de o problema ocorrer de forma intermitente continua chamando atenção, principalmente pela questão do balanceamento entre os dois IPs do ADN mencionada anteriormente neste tópico.
Inclusive, temos outro cliente utilizando OpenSSL 3.5.5 que também apresentou o mesmo erro, então, inicialmente, não acredito que seja possível atribuir o problema exclusivamente à versão do OpenSSL.
Vou continuar realizando os testes e, caso encontre alguma evidência mais concreta sobre a causa, compartilho aqui.
Eu notei que o problema que ocorre conosco em relação a comunicação SSL, ocorre com maior frequência no decorrer do dia, porém, beirando os horários de 23:00/00:00 funciona de forma mais tranquila. Eu tenho um cron que roda de tempo em tempo, verificando Notas as quais ainda estão pendentes de integração e que não tenham sido com Rejeição que consta em Manual. Todas as notas estão sendo completamente integradas agora sempre basicamente de madrugada, mas não posso sempre contar com isso.
Realizei testes também forçando a comunicação a ser TLS1.2, mas ainda sem sucesso, pois como eu citei acima, dependendo do IP em que pegar no Load Balancer, ainda me retorna sem sucesso. Os outros pontos mencionados por você, já fiz averiguação deles e estão todos em conformidade, até mesmo a “retentativa” automática, por que como citei, tenho processo que roda de tempo em tempo vasculhando isso.
Bom dia, favor informar a versão do Sistema Operacional pois pode estar ocorrendo falhas por não haver algoritmos criptográficos disponíveis na comunicação.
Caso a conexão se de com um servidor que tenha somente TLS1.3 configurado no SERPRO, se o computador cliente que tenta a conexão (servidor do cliente) não tiver suporte, ocorre falha.
No endereço do ADN mostra TLS1.2 e TLS1.3, mas dependendo do servidor que se conecta no lado do SERPRO tiver somente o TLS1.3, sistemas que não suportem este TLS vão falhar.
Os algoritmos criptográficos disponives nesta varregura, foram:
Se o computador que está tentando conexção não tiver algumas destas suites instaladas (depende da versão do Sistema Operacional, falhará a conexão.
Por isto é importante informar qual Sistema Operacional/versão foi utilizada e falhou.
At.te
Emir Toktar
Boa noite estou com esse erro no ADN do betha cloud desde ontem a noite alguma informação pertinente como devo proceder ?
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)
Boa noite, segue publicação do tópico das falhas ocorridas, com informações obtidas de testes, relatos de diversos grupos e colegas do forum, de alguns grupos Whats e do próprio GT GNFSe que participamos, para auxiliar quem está experimentando problemas. Grato também pela participação do Aured Rodrigues e Otávio que compartilharam experiências do problema que afetou a todos, muitos em aplicações JAVA e/ou Oracle, bem como outros clientes em outras plataformar após o ajuste WAF no ADN, que seria transparente e sem efeitos colaterais.
Problema reportado — Comunicação com adn.nfse.gov.br após alteração no WAF
1. Contexto
Após alterações na infraestrutura de comunicação, incluindo a utilização do WAF/balanceador para acesso ao servidor adn.nfse.gov.br, alguns clientes passaram a enfrentar falhas na comunicação utilizando certificados digitais e-CNPJ A1.
Os problemas foram observados principalmente em aplicações Java, inclusive em ambientes Oracle/OJVM.
Certificados que funcionavam normalmente antes da alteração passaram a apresentar falhas durante o estabelecimento da conexão TLS.
2. Problema principal — Apresentação do certificado A1
Causa identificada
O servidor, após o WAF/balanceador, passou a enviar no CertificateRequest uma lista de Autoridades Certificadoras (CAs) aceitas.
Em aplicações Java que utilizam o KeyManager padrão (SunX509), a seleção do certificado cliente pode depender da correspondência entre a cadeia existente no .pfx/.p12 e as CAs anunciadas pelo servidor.
Quando o PFX contém somente o certificado A1, sem a cadeia intermediária necessária, o Java pode não encontrar uma correspondência e não apresentar o certificado cliente durante o handshake.
O servidor, aguardando o certificado A1, encerra a conexão.
Sintomas
Dependendo do ambiente, o cliente pode receber erros como:
-
bad record mac— OpenSSL; -
AEADBadTagException: Tag mismatch— Java; -
handshake_failure; -
erros criptográficos genéricos;
-
encerramento abrupto da conexão TLS 1.3, sem um alerta TLS suficientemente claro.
Isso dificulta a identificação da causa, pois o erro apresentado ao cliente pode aparentar ser uma falha de criptografia, quando, na realidade, o certificado cliente não foi apresentado durante o handshake.
3. Contorno 1 — Reempacotamento do certificado A1
Uma alternativa (FÁCIL e RÁPIDA) identificada foi exportar/reempacotar o certificado A1 contendo a cadeia completa de certificação, incluindo as autoridades intermediárias até a raiz ICP-Brasil.
Como referência, foram observados PFXs com aproximadamente:
-
3 a 4 KB: certificado sem as demais cadeias;
-
10 a 14 KB: certificado acompanhado da cadeia completa.
Com a cadeia completa, o Java consegue encontrar uma CA compatível com aquelas anunciadas pelo servidor e apresentar o certificado.
Essa alternativa, porém, possui impacto operacional, pois exige a correção dos arquivos PFX individualmente.
4. Contorno 2 — KeyManager customizado
Alguns clientes resolveram o problema alterando o comportamento de seleção do certificado no Java.
Foi implementado um KeyManager customizado, denominado, em um dos casos, CertificadoForcadoKeyManager, que intercepta a decisão sobre qual certificado cliente deve ser apresentado, especialmente no método chooseClientAlias.
Em vez de deixar o Java decidir exclusivamente com base nas CAs informadas pelo servidor, a implementação força o retorno do alias correspondente ao certificado A1 carregado pela aplicação.
Com isso, o certificado configurado é apresentado mesmo quando a cadeia existente no PFX não corresponde à lista de CAs enviada pelo servidor.
Outra implementação equivalente pode utilizar um X509ExtendedKeyManager customizado, com o mesmo objetivo de controlar explicitamente a seleção do certificado.
Resultado
Essa abordagem resolveu, para os clientes que a implementaram, a rejeição do certificado durante a comunicação com a Sefaz/NFSe.
Entretanto, trata-se de uma adaptação realizada no lado do cliente e, portanto, exige alterações específicas em cada aplicação/ambiente Java.
5. Compatibilidade de SNI
Além do problema de seleção do certificado, um dos clientes identificou uma necessidade específica relacionada ao SNI (Server Name Indication) no ambiente Oracle/OJVM.
Foi implementada uma SSLSocketFactory customizada, denominada RastreandoSSLSocketFactory, responsável por capturar o hostname utilizado na URL e inseri-lo explicitamente no SSLParameters de cada socket.
Para o serviço em questão, o hostname utilizado é:
adn.nfse.gov.br
A implementação utiliza SNIHostName para garantir que o hostname seja enviado durante o handshake TLS.
Segundo o relato do cliente, essa implementação contornou uma limitação existente no ambiente Oracle utilizado.
Observação
Esse item deve ser tratado separadamente do problema de seleção do certificado A1.
A necessidade de forçar SNI parece estar relacionada à compatibilidade do ambiente Oracle/OJVM com a negociação TLS, enquanto o problema principal descrito anteriormente está relacionado à seleção/apresentação do certificado cliente.
6. Compatibilidade de Cipher Suites
Outro ajuste realizado foi a ampliação das suítes criptográficas oferecidas pelo cliente.
Foi criada uma lista de ciphers preferenciais, denominada CIPHERS_TLS12_PREFERIDAS, contendo suítes consideradas modernas e também aliases utilizados por versões/ambientes antigos do OJVM, incluindo nomes no formato:
SSL_RSA_WITH_...
Além disso, foi implementado um mecanismo de fallback no método escolherPerfilTls.
O objetivo é garantir que o cliente Java consiga oferecer um conjunto de suítes criptográficas compatível com aquelas aceitas pelo ambiente governamental.
Observação
Assim como o SNI, esse ajuste deve ser considerado uma questão de compatibilidade TLS do ambiente cliente, e não necessariamente parte da causa raiz do problema de apresentação do certificado.
Pessoalmente, esta opção restringe as ciphers que geralmente são negociadas pelo sistema operacional de forma automática, apesar de poder indicar, caso tenha mudanças, acaba limitado pela aplicação que sinaliza ao SO utilizar apenas algumas chaves. Podem testar, mas não entendo ser necessária.
7. Resiliência e retentativas
Outra abordagem para evitar falhas, foi a implementação de um mecanismo de retentativa para chamadas HTTP GET.
Quando ocorre uma falha considerada transitória, como:
-
timeout;
-
reset da conexão;
-
queda momentânea da comunicação;
a aplicação aguarda alguns milissegundos e realiza uma nova tentativa. O mecanismo permite até 3 tentativas antes de retornar o erro ao PL/SQL.
Essa implementação aumenta a resiliência da integração diante de falhas temporárias de rede ou de conexão.
Observação
A retentativa não corrige problemas determinísticos de handshake TLS ou seleção de certificado. Ela atua apenas sobre falhas consideradas potencialmente transitórias. Se o problema é corrigir a comunicação, não tente implementar neste momento.
8. Diagnóstico detalhado
Uma das sugestões foi a implementação de um mecanismo de diagnóstico denominado DIAGNOSTICO_COMPLETO.
O objetivo é aumentar a capacidade de identificar em qual etapa da comunicação ocorre a falha, permitindo diferenciar problemas relacionados a:
-
carregamento do certificado;
-
seleção do certificado cliente;
-
SNI;
-
versão TLS;
-
cipher suite;
-
estabelecimento do handshake;
-
conexão HTTP;
-
timeout/reset;
-
resposta do servidor;
-
retentativas.
Esse tipo de diagnóstico é especialmente importante porque alguns dos erros atualmente retornados pelo ambiente são genéricos e podem mascarar a verdadeira causa da falha.
9. Soluções identificadas nos diferentes clientes
A partir dos relatos recebidos, foram identificados diferentes níveis de tratamento:
| Item | Solução | Objetivo |
|---|---|---|
| Certificado A1 | PFX com cadeia completa | Permitir que o Java encontre uma CA compatível |
| undefined | ---- | ---- |
| Certificado A1 | CertificadoForcadoKeyManager / X509ExtendedKeyManager |
Forçar a apresentação do certificado A1 |
| undefined | ---- | ---- |
| SNI | RastreandoSSLSocketFactory |
Garantir o envio do hostname via SNI |
| undefined | ---- | ---- |
| Cipher Suites | CIPHERS_TLS12_PREFERIDAS + fallback |
Aumentar a compatibilidade TLS |
| undefined | ---- | ---- |
| Retentativas | Até 3 tentativas para GET | Tratar falhas transitórias |
| undefined | ---- | ---- |
| Diagnóstico | DIAGNOSTICO_COMPLETO |
Facilitar a identificação da etapa da falha |
| undefined | ---- | ---- |
10. Avaliação geral
Os relatos indicam que existem dois grupos de problemas que precisam ser diferenciados.
Grupo A — Problema de apresentação do certificado cliente
Esse é o problema mais diretamente relacionado à alteração no comportamento do servidor/WAF.
O envio de uma lista restritiva de CAs no CertificateRequest pode fazer com que o KeyManager padrão do Java não selecione o certificado A1, principalmente quando o PFX não contém a cadeia correspondente.
Os principais contornos identificados foram:
-
reempacotar o PFX com a cadeia completa; ou
-
substituir/customizar o
KeyManagerpara forçar a apresentação do certificado.
A correção preferencial deveria ocorrer no lado do servidor/balanceador, ajustando o CertificateRequest para não impor uma restrição incompatível com certificados válidos ou para anunciar corretamente as autoridades certificadoras intermediárias aceitas.
Grupo B — Compatibilidade do ambiente Java/Oracle
SNI, cipher suites, fallback e retentativas são ajustes adicionais realizados por determinados clientes para aumentar a compatibilidade e a resiliência da comunicação.
Esses mecanismos podem ser necessários em determinados ambientes, mas não devem ser confundidos automaticamente com a causa raiz do problema de certificado.
11. Recomendação
Considerando os relatos dos diferentes clientes, recomenda-se avaliar no WAF/balanceador, que depende somente do SERPRO:
-
Quais CAs estão sendo enviadas no
CertificateRequest; -
Se a lista de CAs está excessivamente restritiva;
-
Se as autoridades intermediárias utilizadas pelos certificados A1 estão sendo anunciadas corretamente;
-
Se é possível utilizar uma lista vazia de CAs quando não houver necessidade de restringir os certificados;
-
O comportamento quando o cliente não apresenta certificado;
-
Se o encerramento da conexão está retornando o alerta TLS apropriado;
-
A compatibilidade da negociação de TLS 1.2/TLS 1.3, SNI e cipher suites com ambientes Oracle/OJVM.
A correção no servidor/balanceador é preferível porque evita que cada integrador tenha que implementar soluções específicas, como KeyManager customizado, injeção manual de SNI, ampliação de cipher suites ou mecanismos próprios de diagnóstico.
Dessa forma, clientes Java, OpenSSL e outras tecnologias poderão utilizar certificados A1 válidos sem necessidade de adaptações específicas decorrentes do comportamento do WAF/balanceador.
Boa sorte.
At.te
Emir Toktar
Bom dia turma…
… aqui estamos com o mesmo erro do CONSTROI acima TENTANDO validar via WEBSERVICE:
E999
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)
O curioso é que trabalho com outras prefeituras que graças a Deus está validando normalmente.
Inclusive com o FLY E-NOTA também da BETHA está OK. Até onde sondei com outros lojistas que também usam o BETHA CLOUD é que estariam com esse problema!
Alguém teve previsão para normalização?
Voltou ao normal as emissões
Voltou mais está instável, então algumas emissões ainda estão dando erro 9999
Olá,
Acho que não entendeu o POST acima, o erro é no ADN e a causa está descrita. O Firewall está aplicando regras e respondendo com a cadeia completa do certificado, as aplicações cliente que utilizam somente o certificado sem as propriedades estendidas, não tem estes da cadeia intermediária e raiz, a aplicação cliente não encontra uma correspondência e não apresenta o certificado para conexão TLS abortando o processo.
Não se aplica a outros Municípios através de fornecedores, como citado Betha, pois não estão com uma regra de validação como aplicada no WAF (Web Application Firewall), logo não se aplica e nem se compara, a decrição é clara e no ADN.
Sugiro ler o tópico e entender o ocorrido.
At.te
Emir Toktar
Maravilha Emir…
De fato o seu conhecimento técnico da operação nas movimentações anteriores mostra que estava engajado na busca de uma solução.
Achei curioso a informação pelo site da BETHA ter existido de que o “SISTEMA NACIONAL estaria inoperante” e encaminhava esse link como referencia.
Como percebeu, o fato de trabalhar com validações em OUTROS MUNICÍPIOS e essas validarem normalmente foi o que me motivou a colocar a observação lançada.. Mesmo usando a aplicação do PRÓPRIO PROVEDOR (no caso o site da BETHA). O importante é que a BETHA (ou o ADN) resolveu a questão e voltamos a validar (mesmo que com lentidão) liberando os processos agarrados!
Olá Bruno,
A Betha para autorizar o documento, ela encaminha ao ADN para autorizar, significa que está correto, depois responde ao cliente (prestador) o resultado, autorizado ou rejeitado, como outros fornecedores municípais.
Se o ADN para, a emissão fica “em espera” até ter a resposta, prejudicando o prestador. A priori, o ADN falhando, gera efeitos colaterais em todos clientes.
At.te
Emir Toktar
Acredito que não haja diferenças no que se refere a autenticação, acho que é um balanceamento de carga (proxy) que talvez esteja utilizando uma infraestrutura inferior ou apresentando algum problema de transporte ocasionado pelo mal funcionamento de algum componente.
Quanto a questão da versão do SSL, o que aconteceu na verdade foi que o servidor (OS) atualizou do OpenSSL padrão enquanto que a nossa API, que estava online fazia mais de 60 dias ininterruptos, ainda estava utilizando uma versão anterior da biblioteca. Antes eu definia a versão mais antiga aceita pelo ADN como padrão na hora de carregar a API, como essa versão não era mais aceita então eu redefini para a versão 3.0.
Você está com a versão atualizada OpenSLL e não teve mais problemas, correto?
Quando é comentado a autenticação, é no processo de autenticação mutua no protocolo mTLS que ocorre nas trocas de certificados, se não autorizas, vem o erro informado.
[Public Key]
Algorithm: RSA
Length: 2048
Key Blob: 30 82 01 0…
SecureChannel- Deixado com 1 certificados de cliente dos quais escolher.
SecureChannel- Tentando encontrar um certificado correspondente no repositório de certificados.
SecureChannel- Localizando a chave privada para o certificado: [Version]
e se não localiza, o processo é interrompido e gera o erro.
Foi discutido no tópico.
Falha de conexão TLS com ADN ‘fatal alert: /t/falha-de-conexao-tls-com-adn-fatal-alert-handshake-failure-bad-record-mac-decrypt-error-ou-tag-mismatch/1992handshake_failure ‘, ‘bad record mac’, ‘decrypt error’ ou ‘tag mismatch’
At.te
Emir Toktar