Erro intermitente ao enviar XML para a ADN – cURL error 56 / SSL_read

Geral
1

Olá a todos.

Estou enfrentando um problema intermitente ao enviar o XML da NFS-e para a base nacional (ADN).

Algumas notas são enviadas normalmente, porém em outras tentativas ocorre o erro:

cURL error 56: OpenSSL SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac, errno 0 for https://adn.nfse.gov.br/dfe

Quando ocorre o erro, não recebo nenhum resposta da ADN, apenas a exceção do cURL.

Alguém mais está enfrentando esse problema? Existe alguma instabilidade conhecida no endpoint ou alguma configuração específica que precisamos ajustar no servidor/aplicação?

Endpoint: https://adn.nfse.gov.br/dfe
Erro: cURL error 56 / OpenSSL SSL_read

Obrigado!

2

É instabilidade dentro da própria ADN, o que nos resta é aguardar mesmo, desde ontem a noite está ocorrendo esse problema, o negócio é esperar e ir tentando reenviar as notas que ficaram para trás, infelizmente. Até porque, existe nota que se integra 100% e outras que ocorre o problema do SSL.

3

Entendo, obrigado pela resposta.

4

No meu caso o erro é diferente.

403 Forbidden
Request forbidden by administrative rules.

Este erro começou a aparecer nas primeiras horas do dia e persiste até o presente momento.

5

Sim, é algo com questão do certificado que de forma direta, é quesito de permissão, já temos mais de 400 notas pendentes, incrível o pessoal da Receita…

6

Alguma novidade por aí?

7

Aqui continua na mesma, algumas envia e outras não.

8

Sim, mesma coisa por aqui, poucas integram, outras ficam para trás e só depois de um bom tempo para conseguir fazer a integração

9

No meu caso é zero aproveitamento. Todas as tentativas de sincronização com o ADN resultam em erro 403.

10

Ainda não tivemos nenhuma resolução, né? Geralmente, a usuária elisabetebach traz respostas bem interessantes. Não sei se ela trabalha na ADN, mas talvez possa nos ajudar com alguma informação.

11

Enviei um e-mail ontem para municipios.nfs-e@rfb.gov.br relatando o problema. Geralmente eles demoram 5 dias para responder (um absurdo) e até agora não recebi a resposta.

Estamos à deriva aqui na nossa prefeitura, um lista enorme de documentos para enviar para o ADN.

Curioso que testei o endpoit de recuperação de documentos por NSU (https://adn.nfse.gov.br/municipios/DFe/{NsuRecepcao}?tipoNSU=RECEPCAO&lote=true) e está funcionando, com alguma instabilidade é bem verdade, mas funciona.

De fato, a companheira @elisabetebach está fazendo falta nessa conversa, ela tem um trânsito muito bom com o pessoal da RFB e certeza de que ela nos daria uma luz muito mais rápido.

12

Verdade. Tentei contato pelo atendimento.nfs-e@rfb.gov.br, mas recebi o retorno de que o e-mail foi desativado.

Também estamos com vários documentos pendentes de envio. Alguns são processados normalmente, enquanto outros apresentam o mesmo erro relatado ontem.

Vou enviar um e-mail para municipios.nfs-e@rfb.gov.br relatando o problema. Por favor se tiverem algum retorno, nos avisem para acompanharmos juntos.

13

Bom dia

Verei se consigo um contato para agilizar.

At ye

14

Obrigado ficamos no aguardo :slight_smile:

15

Bom dia Elisabete, prazer em revê-la.

De início, desculpe-me por trazê-la para essa discussão.

Enviei um e-mail para a Equipe da Nota Fiscal de Serviços Eletrônica e eles já me responderam. Pediram para que eu realizasse vários testes isolados, os quais estou fazendo nesse momento, e os resultados preliminares mostram que mudaram alguma coisa nos cabeçalhos. Geralmente essas mudanças não surtem efeitos na maioria das implementações, no entanto esse não foi o meu caso.

As requisições em linha de comando (curl) estão passando normalmente, isso significa que preciso fazer adequações no meu pipeline de envio de documentos. Estou revisando o código e espero resolver esse problema ainda hoje.

Muito obrigado mais um vez por não se furtar em nos ajudar. Assim que concluir a minha parte do trabalho eu volto aqui para reportar as minhas conclusões.

16

Ótimo

Que bom que já estão dando andamento.
vamos alinhando.

Sempre que for algo de grande impacto e houverem entraves na linha de comunicação natural, me acionem.

Nem sempre consigo auxiliar na hora, pois a carga minha e da nossa empresa, também é grande.

já aviso que de 20/09 a 10/10 estarei off e não conseguirei auxiliar. Vou ver se acho mais duas pessoas do GT para ficar de olho por aqui.

17

Já resolvi o problema com a nossa aplicação.

Acontece que o algoritmo produzido pela biblioteca OpenSSL que estávamos utilizando para enviar os lotes para o ADN não é mais aceito. Antes estávamos utilizando a OpenSSL 1.1 e aparentemente a plataforma ADN agora exige o algoritmo produzido pela OpenSSL 3.0 ou posterior.

No entanto, durante o processo de checagem eu detectei um problema que pode estar afetando o @brunosts, acontece que existe um balanceamento de carga no host do ADN onde a recepção dos lotes se revezam entre dois IPs (189.9.177.202 e 189.9.169.76). Pelos meus testes o IP 189.9.169.76 recepciona cerca de 80% das requisições e está apresentando um índice de falhas da ordem de 30%. Talvez fosse interessante testar “forçar” a recepção dos lotes pelo IP 189.9.177.202 ao invés de enviar direto para DNS. No entanto isso pode ser um tiro no pé, uma vez que do dia pra noite a plataforma pode mudar de IP e o serviço de envio quebrar totalmente.

Enfim, minha jornada terminou (por enquanto), agora vou dormir para tentar recuperar (embora seja impossível) os neurônios mortos pelo estresse.

Um ótimo resto de semana a todos e a todas.

18

Ainda não fiz nenhuma alteração no ambiente, pois também fiquei com dúvidas em relação ao OpenSSL. No nosso servidor de produção utilizamos OpenSSL 1.1.1k, mas em outro cliente, com servidor próprio e OpenSSL 3.5.5, também tivemos o mesmo comportamento intermitente com cURL error 56. Atualmente, inclusive, esse ambiente está funcionando normalmente sem nenhuma alteração.

Por isso, não acredito que o problema esteja necessariamente relacionado apenas à versão do OpenSSL, embora ainda seja uma possibilidade.

A questão do balanceamento entre os dois IPs também faz bastante sentido e pode explicar o comportamento intermitente. Fiquei pensando se pode existir alguma diferença entre as estruturas por trás desses IPs, inclusive em relação à compatibilidade com TLS/OpenSSL. Talvez uma das conexões esteja sendo direcionada para uma estrutura compatível e outra não, o que poderia explicar por que em alguns momentos o envio funciona e em outros ocorre o cURL error 56.

19

Prezados, o Serpro solicitou para quem ainda está com problema no compartilhamento, por favor executar o comando abaixo e nos enviar o resultado:

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

essa sintaxe desse comando é pra rodar em windows

Retornem e me marquem para que possa retornar.

20

Minha cara @elisabetebach, tudo bem?

Conforme solicitado, segue o que ocorre quando eu executo o código citado:

* Added adn.nfse.gov.br:443:189.9.169.76 to DNS cache
* Hostname adn.nfse.gov.br was found in DNS cache
*   Trying 189.9.169.76:443...
* Connected to adn.nfse.gov.br (189.9.169.76) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256 / X25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=adn.nfse.gov.br
*  start date: Aug 24 21:25:29 2026 GMT
*  expire date: Nov 22 21:25:28 2026 GMT
*  subjectAltName: host "adn.nfse.gov.br" matched cert's "adn.nfse.gov.br"
*  issuer: C=US; O=Let's Encrypt; CN=YR1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 3: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET /echo HTTP/1.1
> Host: adn.nfse.gov.br
> User-Agent: curl/8.5.0
> Accept: */*
>
* TLSv1.3 (OUT), TLS alert, bad record mac (532):
* OpenSSL SSL_read: OpenSSL/3.0.13: error:0A000119:SSL routines::decryption failed or bad record mac, errno 0
* Closing connection
curl: (56) OpenSSL SSL_read: OpenSSL/3.0.13: error:0A000119:SSL routines::decryption failed or bad record mac, errno 0

Pude reparar na apuração do CURL também Elisabete, que aparentemente está envolto de um “Load Balancer” (O que é racional), porém, quando ele aponta para esse IP 189.9.169.76 o mesmo retorna erro, mas fiz novamente o mesmo comando um tempo depois, retornou com sucesso o /echo porém para o IP 189.9.177.202, sendo esse com resultado do REQUEST 200. Mesmo eu tentando forçar TLS1.2, o mesmo permanece retornando erro caso o mesmo esbarre no primeiro servidor citado.