Efd-Reinf - Retorno Inativo ou Inoperante com certificado A3

[Andergoncalves]

Boa tarde a todos,

Após uma análise aprofundada dos posts referentes ao tema, ainda não conseguimos chegar a uma conclusão definitiva sobre a questão em discussão.

 

 

Em nosso sistema, Iniciamos a configuração padrão com o SSLType definido como LT_TLSv1_2. Entretanto, temos registrado uma série de chamados em nosso suporte técnico que relatam o erro "Inativo/Inoperante" ao tentar transmitir eventos para o EFD-Reinf. Como solução temporária, realizamos a alteração desse parâmetro para LT-ALL, o que permitiu a transmissão dos eventos sem problemas. No entanto, é importante destacar que, conforme a informação disponibilizada em http://sped.rfb.gov.br/pagina/show/7280, a Receita Federal do Brasil passará a aceitar apenas conexões TLS na versão 1.2 ou superior a partir de 21/10/2023. Isso nos causa preocupação, uma vez que receamos enfrentar o mesmo erro no próximo mês. 
 

Para melhor compreender a situação, reproduzimos o erro que nossos clientes têm encontrado em nosso ambiente de desenvolvimento. Aqui, utilizamos o Windows 11, na versão mais atualizada, e, ao tentar enviar um evento para o EFD-Reinf, também nos deparamos com a mensagem "Inativo/Inoperante".

Fiz testes com :

LT_all             OK - funcionou
LT_TLSv1_0   OK - funcionou
LT_TLSv1_1    OK - funcionou
LT_TLSv1_2   ERRO - inativo ou inoperante

Fazendo teste em minha máquina que esta com o Windows atualizado ocorre o mesmo erro.

Além disso, em nossas avaliações nos ambientes dos clientes, a maioria dos quais são escritórios de contabilidade, notamos que em um mesmo escritório foi possível transmitir eventos para uma empresa que utiliza certificado A3, enquanto outra empresa, também com o mesmo tipo de certificado, apresentou o erro mencionado. Essa observação nos leva a concluir que o problema não parece estar ligado ao ambiente do cliente.

Agradecemos a todos pelo empenho e pelas sugestões até o momento. Contudo, vale ressaltar que continuamos investigando a origem desse problema. Caso algum colega possua informações adicionais ou contribuições que possam nos auxiliar a encontrar uma solução definitiva, seremos imensamente gratos.

[Alexandre de Paula]

boa tarde @Andergoncalves,

Parabéns pela análise e descrição.

Como você comentou parece que já explorou a maioria das possibilidades que poderíamos sugerir para avaliar.

4 minutos atrás, Andergoncalves disse:

a maioria dos quais são escritórios de contabilidade, notamos que em um mesmo escritório foi possível transmitir eventos para uma empresa que utiliza certificado A3, enquanto outra empresa, também com o mesmo tipo de certificado, apresentou o erro mencionado.

Talvez avaliar o emissor do certificado se os casos com sucesso ou com erro são de um mesmo emissor. Tivemos alguns casos de ocorrencias (não necessariamente Reinf) em que estava relacionado a um emissor e/ou sua cadeia de certificados...

Outro ponto (que não me parece ser o foco do problema), mas os testes realizados foram com sua aplicação ou com o programa exemplo? Caso tenha sido com sua aplicação, o mesmo erro ocorre com o prorgama exemplo? Assim eventualmente poderia avaliar/compartilhar algum detalhe ou log.

[Andergoncalves]

Boa tarde @Alexandre de Paula

Obrigado pela atenção. 

Fizemos testes com nossa aplicação e também com programa exemplo da ACBR, com o SSLType LT_TLSv1.2 e apresenta o erro:

 

Com SSLType LT_TLSv1.1 foi enviado:

 

 

[Alexandre de Paula]

Outro ponto que vc não comenta na sua descrição, mas deduzi pelos tópicos referenciados.

O problema acontece apenas com certificados A3? Com certificados A1 funciona normal no TLS 1.2?

[Andergoncalves]

O problema somente acontece com o certificado do Tipo A3. Testes realizados com A1 funciona perfeitamente no TLS 1.2.

[Alexandre de Paula]

Dê uma olhada nesse topico.

ele tem algumas sugestões para ocorrencias com A3 tbm. Talvez alguma delas poss ajudar.

 

[Andergoncalves]

@Alexandre de Paula fizemos outro teste aqui enviando pelo eSocial com a mesma empresa e certificado A3 e funcionou. TLS 1.2.

Editado 11 Outubro, 2023 por Andergoncalves

[Renato Rubinho]

Boa tarde,

Veja este tópico.

Use tls1.3 onde não funcionar com 1.2.

Esse problema de certificado A3 com DFes é recorrente, já houveram relatos de problemas com NFe, NFCe, CTe, inclusive um dos casos no ano passado a Sefaz assumiu problema do lado deles, mas não deram solução.

Obs: casos anteriores também funcionavam com outros DFes no mesmo ambiente.

 

 

[Andergoncalves]

Bom dia @Renato Rubinho.

Obrigado a todos pela informação.

Renato fiz o teste aqui mudando para TLS1_3 e funcionou. 

Porém depurando o código do ACBR achei uma função que pode ser que funcione assim mesmo ou teria que implementar o TLS1_3.

Ele acessa justamente o mesmo valor da opção TL_all.

C:\ACBR\Fontes\ACBrTCP\ACBrWinHTTPReqResp.pas

Obrigado

Anderson

[Andergoncalves]

Boa tarde! 

Acredito que o ACBR ainda não implementou a criptografia utilizando o TLS 1.3.

Analisando o código fonte da ACBR, observei que ao usar a propriedade SSLType definida como LT_TLSV1_3, a função TACBrWinHTTPReqResp.SetConnectionSSL opera da mesma maneira que a configuração LT_ALL.

A configuração LT_ALL utiliza a criptografia do SSL2, SSL3 ou TLS1, conforme pode ser visto na imagem abaixo. Isso explica por que, ao transmitir eventos para a EFD-Reinf, funcionou, pois utilizou um protocolo mais antigo de criptografia, que ainda está operacional, mas tem data prevista para ser bloqueado pela Receita Federal do Brasil em 20/10/2023.

Ao testar o TLS 1.3 no eSocial, o ACBR direciona para o mesmo código que a EFD-Reinf está usando. Uma vez que o servidor do eSocial tem um tratamento específico para essa situação, ele retorna um erro informando que o protocolo SSL é incompatível, reforçando a nossa tese de que o protocolo TLS 1.3 ainda não está implementado no ACBR.

Surge uma dúvida: não tenho certeza se estou aplicando os critérios de avaliação corretamente ou se, de fato, o protocolo TLS 1.3 ainda não foi implementado no ACBR.

Editado 13 Outubro, 2023 por Andergoncalves

[Renato Rubinho]

Boa tarde Anderson,

Obrigado por reportar, sua análise está correta, o tls1.3 funcionou porque o componente tratou como lt_all.

O @Victor H. Gonzales - Panda já mandou uma correção para o svn.

Voltando ao problema...

3 horas atrás, Andergoncalves disse:

ou teria que implementar o TLS1_3.

O próprio Panda nos alertou que o Reinf não aceita o tls1.3.

Indiquei o uso, imaginando que funcionasse, devido ao outro tópico que foi testado com sucesso, mas como já sabemos funcionou como lt_all.

Como o Reinf só suportará o tls1.2 em 21/10/2023, precisa tentar verificar com quem distribui esse A3, que não está funcionando com tls1.2 ou com a própria sefaz, qual é o problema.

[Sófolha]

Bom dia,

Realizamos um levantamento entre nossos clientes que relataram esses erros e identificamos que eles estão usando diversas Autoridades Certificadoras diferentes. Alguns exemplos incluem Link RDB V2, Certisign RFB G5, Certifica Minas v5 e Soluti Multipla v5, Safeweb RFB v5. Além disso, é importante destacar que esses certificados são os mesmos usados para transmitir eventos no eSocial. Essas informações nos levam a descartar a hipótese de que o problema esteja relacionado aos certificados ou à sua instalação.

Para reforçar nossa posição, foi publicada ontem uma mensagem no portal Sped. Ela informa que a revisão do conjunto de protocolos TLS na EFD-Reinf, que originalmente estava programada para 21/10/2023 e implicava na desativação do uso de TLS 1.0 e TLS 1.1, foi adiada para janeiro de 2024. A data exata ainda será divulgada. Provavelmente, ainda estão ajustando os servidores para recepcionar as informações com esse nível de criptografia.

Adiamento da revisão do conjunto aceito de TLS na EFD-Reinf (rfb.gov.br)

At.te,

[Renato Rubinho]

Boa tarde @Sófolha

Obrigado pelas informações.

Em 11/10/2023 at 16:57, Renato Rubinho disse:

Obs: casos anteriores também funcionavam com outros DFes no mesmo ambiente.

Conforme informado anteriormente, em casos semelhantes já relatados, enquanto ocorreu este tipo de erro com algum DFe, outros no mesmo ambiente funcionaram corretamente.

A questão não deve ser a instalação do certificado tão pouco a utilização dele pela componentes, tendo em vista que alguns DFes funcionam.

O problema deve ser algo específico entre o certificado/leitora/driver/outros X Servidor que recepciona o documento.

Tente atualizar a cadeia de certificados onde está atendendo o problema para verificar se resolve em algum dos cenários.

Segue um tópico relacionado.