Requisição não enviada 12157 12007 (Homologação)

[robinhovrb]

Boa tarde, neste momento estou recebendo esta mensagem no ambiente de homologação; Alguém tem uma solução?

[Igor Bastos]

2 minutos atrás, robinhovrb disse:

Boa tarde, neste momento estou recebendo esta mensagem no ambiente de homologação; Alguém tem uma solução?

De qual estado você é?

Vc utiliza qual Lib de comunicação? (OpenSS, CAPICON ou o WeinCryp que o @Daniel Simoes comentou)

[robinhovrb]

Estou testando no Estado de MG.

Tentei utilizar todos os lib;

Editado 16 Maio, 2017 por robinhovrb

[Daniel Simoes]

Se você usar httpWinHTTP (que é o padrão para quem usa libWinCrypt), essas configurações de internet não são necessárias... Você informa o tipo de SSL diretamente ao componente:

ACBrNFe1.SSL.SSLType := LT_TLSv1_2

 

[robinhovrb]

Boa tarde, substituir as DLL(...ACBr\DLLs\OpenSSL\0.9.8.14) ssleay32 e libeay32 para a pasta C:\Windows\SysWOW64 

Funcionou em ambiente homologação...

[Daniel Simoes]

MG parece estar OK

Agora, robinhovrb disse:

Boa tarde, substituir as DLL(...ACBr\DLLs\OpenSSL\0.9.8.14) ssleay32 e libeay32 para a pasta C:\Windows\SysWOW64 

Funcionou em ambiente homologação...

Essa versão do OpenSSL, não suporta TLS 1.2... ou seja, ela NÃO funcionará na NFe 4.0

Leia esse tópico:

 

[robinhovrb]

Problema resolvido

Faltou muita atenção da minha parte:

{$DEFINE USE_MINGW}
{$IfNDef MSWINDOWS}
  {$DEFINE USE_MINGW}
{$EndIf}

 

[Igor Bastos]

47 minutos atrás, Daniel Simoes disse:

Se você usar httpWinHTTP (que é o padrão para quem usa libWinCrypt), essas configurações de internet não são necessárias... Você informa o tipo de SSL diretamente ao componente:

ACBrNFe1.SSL.SSLType := LT_TLSv1_2

 

Se eu colocar httpWinHTTP, aí não vai nem no ambiente de Produção.

Já fiz tantas alterações que nem sei mais quais DLLs utilizar 

@Daniel Simoes tem possibilidade de vc testar com um cliente de GO?

[Daniel Simoes]

1 minuto atrás, Igor Bastos disse:

Já fiz tantas alterações que nem sei mais quais DLLs utilizar 

Leia o tópico indicado que você saberá...

[Igor Bastos]

@Daniel Simoes, tem possibilidade de vc testar com um cliente de GO em ambiente de homologação?

[Daniel Simoes]

Funcionando... mas parece instável...

[Igor Bastos]

Acabei de gerar uma Máquina Virtual com Windows 7 64bits, novinha;

instalei o ACBrMonitor Free;

peguei a libeay32.dll de "ACBr\DLLs\OpenSSL\0.9.8.14";

peguei as DLLs: iconv, libxml2, libxmlsec, libxslt, zlib1 da pasta "ACBr\DLLs\XMLSec";

Peguei a crypt32.dll da pasta SysWOW64;

Escolhi SSLLib = libWinCrypt;

O erro continua para Homologação.

Editado 16 Maio, 2017 por Igor Bastos

[Igor Bastos]

Essa foi a resposta do SEFAZ:

"Boa tarde Igor,

Verifique se não há um firewall ou antivírus impedindo a conexão e se a porta 443 está liberada. Configure o firewall para liberar conexão pela porta 443 para *TODAS* as seguintes redes:

187.5.111.0/25          201.48.19.0/26 

Solicite também ao seu provedor de internet que configure o DNS reverso. Outro fator em que pode ocorrer problema na conexão é se a hora do computador ou do provedor de internet estiver desatualizada.

Em homologação aplicamos uma política de manter apenas as cadeias raiz das autoridades certificadoras, conforme nota técnica abaixo:

http://www.nfe.sefaz.go.gov.br/post/ver/182650/obrigatoriedade-de-apresentacao-de-cadeia-de-certificacao-completa

Em homologação é necessário que o sistema emissor envie toda a cadeia completa do certificado. Essa mudança ainda não foi ainda feita em produção por muitos sistemas ainda não estarem adaptados, mas será feita no futuro. Por isso o ambiente de homologação já está dessa forma, para que os desenvolvedores possam ir se adequando.

Att."

Aparentemente eles já estão com o ambiente de homologação pronto p 4.0, seria isso?

[Daniel Simoes]

7 horas atrás, Igor Bastos disse:

peguei a libeay32.dll de "ACBr\DLLs\OpenSSL\0.9.8.14";

peguei as DLLs: iconv, libxml2, libxmlsec, libxslt, zlib1 da pasta "ACBr\DLLs\XMLSec";

Essa DLLs são as antigas.. e não suportam TLS 1.2... por favor leia com atenção o tópico indicado... em todo caso, essas DLLs apenas são usadas em "libOpenSSL"

 

7 horas atrás, Igor Bastos disse:

Peguei a crypt32.dll da pasta SysWOW64;

Não faça isso... deixe o próprio Windows gerenciar as DLLs de sua API

 

[Igor Bastos]

@Daniel Simoes, no tópico indicado, vc diz assim:

Citar

Copie TODAS as DLLs (e não somente algumas)  da pasta "\ACBr\DLLs\XMLSec\MinGW\32" ou "\ACBr\trunk2\DLLs\XMLSec\MinGW\64" (conforme o seu compilador), para o seu diretório de DLLs... (se não tem certeza para onde você deve copiar as DLLS, leia com atenção o Post indicado anteriormente)

 

Outro problema, é que a MinGW, gera as DLLs com uma nomenclatura ligeiramente diferente do VisualC, exemplo: libxmlsec1.dll com MinGW, e "libxmlsec.dll" com VisualC. Portanto, o ACBr teria dificuldades em encontrar essas DLLs e carrega-las de forma dinâmica.

Precisamos portanto, informar ao ACBr, que usaremos o conjunto de DLLs no formato da MinGW... Isso é feito, editando o arquivo: ACBr.inc.

Repare que lá no final do ACBr.inc, temos a seguinte linha:

{.$DEFINE USE_MINGW}

Apenas remova o ".", alterando para:

{$DEFINE USE_MINGW}   

 

Pronto...  com isso você estará pronto para usar o ACBr com OpenSSL e TLS 1.2, seja em 32 ou 64 bits...

Eu já havia retirado o "." e aparentemente o sistema ainda solicita a libxml2.dll, pois ao copiar tds DLLs de  "\ACBr\DLLs\XMLSec\MinGW\64" ele ainda informa a falta da libxml2.dll.

[Igor Bastos]

 

 

Tentando de qualquer coisa, peguei as DLLs de "\ACBr\DLLs\XMLSec\" e joguei dentro da pasta também, ou seja, junto com as "\ACBr\DLLs\XMLSec\MinGW\64". O sistema abriu mas continua o mesmo problema com a Homologação.

OBS: estou testando só com libWinCrypt e libCapicon (pois terei que usar A3). No libWinCrypt eu mudo o SSLXmlSignLib = xsXmlSec, pois o SO é 64 e como vc falou no tópico "Bye Bye Capicom", a xsMsXML não possui suporte para 32bits.

[Daniel Simoes]

Me parece que você não leu os posts indicados, com atenção...

[Igor Bastos]

10 minutos atrás, Igor Bastos disse:

Tentando de qualquer coisa, peguei as DLLs de "\ACBr\DLLs\XMLSec\" e joguei dentro da pasta também, ou seja, junto com as "\ACBr\DLLs\XMLSec\MinGW\64". O sistema abriu mas continua o mesmo problema com a Homologação.

OBS: estou testando só com libWinCrypt e libCapicon (pois terei que usar A3). No libWinCrypt eu mudo o SSLXmlSignLib = xsXmlSec, pois o SO é 64 e como vc falou no tópico "Bye Bye Capicom", a xsMsXML não possui suporte para 32bits.

 

6 minutos atrás, Daniel Simoes disse:

Me parece que você não leu os posts indicados, com atenção...

Errei no final do texto, é 64bits que o xsMsXML não possui compatibilidade. (apenas falta de atenção ao digitar)

[Igor Bastos]

Citar

Em resumo, use 32 se o seu Compilador é 32 bits, e 64 apenas se você estiver usando um Compilador que gere .EXE em 64 bits...

Uma observação para esta questão do Compilador (que tem nos dois tópicos indicados), eu compilo em 32bits, mas de qualquer forma estou testando com tds as DLLs (primeiro 32, elimino tds da pasta e depois testo com 64).

[Daniel Simoes]

Você compila suas aplicações em 64 bits ?  Se não, compila, então definitivamente você não leu com atenção os posts..

[Igor Bastos]

Então @Daniel Simoes, sei que vc já passou por isso... Eu estou sofrendo com esse problema desde o dia 12/05 com o cliente solicitando uma resolução, mas sem Homologar eu não consigo testar. Então eu estou meio desesperado, não que eu não tenha lido o post com atenção, sei que um sistema compilado em 32bits precisará das DLLs em 32bits e o sistema compilado em 64bits precisará das DLLs em 64bits.

A questão é que compilo em 32bits mas roda em SO 64bits (tanto Win7 quanto Win10), então eu testei com os dois grupos de DLLs (separadamente). O sistema nem abre quando testo com as DLLs 64bits "\ACBr\DLLs\XMLSec\MinGW\64", mas eu testei com elas só para desencargo de Consciência. Testando com as 32bits "\ACBr\DLLs\XMLSec\MinGW\32", o sistema abre mas não funciona em Homologação.

Tirei o "." da linha como  indicado no Post.

{.$DEFINE USE_MINGW}

Se não for esta questão que não estou dando atenção ao tópico, por favor, deixe mais claro onde estou falhando.

OBS: estou testando as config default deSSLLib com CAPICOM e WinCrypt. Ambas situações funcionam Produção e não Homologação.

[Daniel Simoes]

Se você usa CAPICOM ou WinCrypt... então as DLLs do OpenSSL e XMLSec (Pasta MinGW)... não são usadas em nenhum momento...

[Igor Bastos]

21 horas atrás, Daniel Simoes disse:

Se você usa CAPICOM ou WinCrypt... então as DLLs do OpenSSL e XMLSec (Pasta MinGW)... não são usadas em nenhum momento...

Segue anexo o ACBr.inc, a imagem das DLLs que o sistema obriga ter na pasta e o Propriedades da internet (as duas imagens são da Máquina Virtual nova que criei ontem).

Continuo deixando as config default do SSLLib CAPICOM ou WinCrypt, mas o erro em homologação continuar.

ACBr.inc

Editado 18 Maio, 2017 por Igor Bastos

[Igor Bastos]

@Daniel Simoes, tem algum erro no que eu fiz para desvincular o OpenSSL e XMLSec?

[fabiofranzini]

Igor Bastos, bom dia. Você encontrou algo que pude-se ajudar ?

Tenho este problema a alguns dias, ja revisei todos os tópicos indicados, mas continuo tento sucesso na Produção, mas em homologação não consigo nem resposta do serviço.