Conexão na versão 4.00 depois da revision 15289

[RicardoVoigt]

Bom dia,

Implantando a versão 4.00 (RS+WinCrypt), passei por uma dificuldade na segunda-feira dia 11/06,com meu aplicativo emissor compilado (Lazarus 1.8.2) usando a revision 15289, e decidi abrir este tópico ao ver a quantidade de relatos postados essa semana com problemas de conexão.

O meu aplicativo (com a revision 15260) já está funcionando em produção em um usuário (Windows 7+SSLType=ALL), emitindo NF-e na versão 4.00.

Já o mesmo projeto agora compilado com a revision 15289, ao implantar no segundo usuário (também Windows 7), eu apenas testei o "status do serviço" na versão 4.00 e em diferentes momentos (testando/alterando a propriedade SSLType) apresentou sempre uma das mensagens de erro abaixo:

12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor
ou
12030 - A conexão com o servidor foi redefinida ou encerrada, ou um protocolo SSL incompatível foi encontrado

O que me deixou intrigado foi que copiei a versão anterior do meu aplicativo emissor (revision 15260) neste mesmo computador, e o "status do serviço" funcionou normal na versão 4.00 (SSLType=ALL).
 

Att

Ricardo

[Edcarlos_rog]

Boa tarde, 

Estou com o mesmo problema:

12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor

O Windows é o 7 e está acontecendo somente no estado de GO. Já tentei utilizar o TSSLType.LT_TLSv1_2 e o TSSLType.LT_all e o erro persiste.

Alguém tem alguma ideia do que pode estar provocando este problema?

Obrigado.

 

[fabriciosouza]

Boa tarde,

Estou com o mesmo problema com a versao ACBrMonitorPLUS-1.2.0.5, voltei a usar a versao ACBrMonitorPLUS-1.1.0.63 e funciona normalmente. Estou no estado de "SC".

Abraços

 

[everson.turossi]

Tentem utilizar WinCrypt  com LT_TLSv1_2

[tallesbr]

também estou com o mesmo problema.

ja mudei para trabalhar com  WinCrypt  e LT_TLSv1_2  porém o problema persiste

pelo que vi acho que só no win7 que ta acontecendo. no meu win10 vai normal

to no estado do RJ

[datavale]

sai.txtLOG.TXTLOG_COMP.TXTBoa tarde,

Estou com o mesmo problema. O Certificado foi emitido ontem. O anterior, que queimou, estava funcionando Ok.

Quando mudei a versão do ACBRMonitor Plus para a versão 1.2.05, passou a dar as seguintes mensagens:

Falha no Envio da Requisição.
Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor
Inicio TNFeStatusServico
ERRO: WebService Consulta Status serviço:
- Inativo ou Inoperante tente novamente.
Erro Interno: 12175
Erro HTTP: 0
Falha no Envio da Requisição.
Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor
 

Se alguém puder responder.....

 

Werner

Editado 13 Junho, 2018 por datavale
Complemento

[RicardoVoigt]

Boa tarde,

o usuário onde constatei o problema que descrevi no tópico utiliza "Windows 7 Ultimate" (não faço ideia quanto a atualizações, ou se é legítimo ou não, não foi instalado por mim). Fiz o mesmo testei hoje e o problema continua, tanto marcando ALL como TLS1.2.

RESSALVA:

O computador que estou usando no momento para desenvolvimento é "Windows 7 Professional" (licenciado e com SP1+IE11) está 100% funcionando: WinCrypt+TLS1.2. Tanto 3.10 como 4.00. PORÉM neste pc eu desativei (por minha conta e risco) o serviço "Windows Update" lá na época em que ele começou a oferecer o Windows 10. Desde então, nunca mais baixou nenhuma atualização. Consultando aqui no fórum, pessoal tem sugerido alguns updates KBxxx... que precisaria ter instalado no Windows 7 para funcionar o TLS1.2, porém no meu painel de controle consultei e NÃO TEM nenhum deles instalado.  (Por exemplo: KB2992611 , KB976932, KB3140245)

Att

Ricardo

 

[André Ferreira de Moraes]

Substitua o arquivo ACBr\trunk2\Fontes\Terceiros\CodeGear\ACBr_WinHttp.pas por esse ACBr_WinHttp.pas e veja se o problema ainda ocorre.

[RicardoVoigt]

Outro detalhe: lá no usuário é um certificado A3  e meus testes foram com um certificado A1... 

Att

Ricardo

[RicardoVoigt]

21 minutos atrás, André Ferreira de Moraes disse:

Substitua o arquivo ACBr\trunk2\Fontes\Terceiros\CodeGear\ACBr_WinHttp.pas por esse ACBr_WinHttp.pas e veja se o problema ainda ocorre.

[André Ferreira de Moraes]

Teste com a versão do SVN informando LT_TLSv1  ou LT_TLSv1 _1

[tallesbr]

11 minutos atrás, André Ferreira de Moraes disse:

Teste com a versão do SVN informando LT_TLSv1  ou LT_TLSv1 _1

Comigo funcionou colocando AcbrNFe1.SSL.SSLType := LT_TLSv1_1 !!!

 

[RicardoVoigt]

9 minutos atrás, André Ferreira de Moraes disse:

Teste com a versão do SVN informando LT_TLSv1  ou LT_TLSv1 _1

Infelizmente hoje não consigo mais falar com o usuário do "Windows 7 Ultimate", mas no "Windows 7 Professional" descrito acima, "com a versão do SVN" testando com o projeto compilado na revision 15289, também retornou OK... 

não deveria funcionar, isso né?

 

[Cristiano Caritá]

Resultado dos meus testes aqui (todos usando WinCrypt,WinHttp e LibXml2) com certificado A3:
Windows 2008 R2: Funciona somente se usar LT_TLSv1  ou LT_TLSv1_1. Não funciona se usar LT_all ou LT_TLSv1_2
Windows 10: Funciona se usar LT_TLSv1, LT_TLSv1_1, LT_TLSv1_2 ou LT_all.
OBS: Todos os testes foram com os Webservices 4.0 de SP (Ambiente de Produção).
OBS2: verifiquei que os resultados podem variar de UF para UF. Por exemplo, no Windows 10 para a UF de Goiás só funciona TLSv1_2. As outras configurações não funcionam. Para o Windows 2008 R2 e UF de Goiás, nenhuma configuração funciona.

[André Ferreira de Moraes]

Reverti alterações do commit 15264. Não será possível usar LT_ALL na versão 4.00 com HttpWinApi sendo necessário configurar para LT_TLSv1_2

[gleikocarmelo]

Depois das últimas atualizações o WinCrypt parou de funcionar com Lt_all. Conforme o pessoal já citou, caso com a aplicação rodando se defina para libCapicom e depois volte para libWinCrypt, volta a funcionar com Lt_all.

Mas pelos meus testes, aparentemente quando se define para Capicom, o componente não esta retornando para WinCrypt o que da uma falsa informação que houve a comunicação com Lt_all + WinCrypt, quando na verdade a comunicação continuou sendo feita pela Capicom + Lt_all.

Realizei os testes pelo Demo + A1 em mais de um computador.

[gss200610]

Com certificado A3 é possivel usar outra config sem ser libCrypt? , uma vez que todas outras necessitam do pfx.

[Daniel Simoes]

OpenSSL apenas funciona com A1 através do caminho ou dados do PFX

Wincrypt funciona com A3 e A1 imstalado no Windows e também permite a carga do A1 por PFX  (O que dispensa a instalação do certificado no Windows)

Capicom nada mais é do que um wrapper  para Wincrypt.. mesmo as chamadas de .NET para criptografia acabam usando a Wincrypt 

Nesse vídeo (exclusivo aos usuarios do SAC) é explicado em detalhes a ACBrDFeSSL 

 

[wendelswl]

Bom dia a todos, André, de acordo este post que estou acompanhando 

 

só consegui êxito com certificado A1 e Windows Server 2008 R2/2012 R2 fazendo o seguinte procedimento:

  ACBrNFe1.Configuracoes.Geral.SSLLib   := libCapicom;
  ACBrNFe1.Configuracoes.Geral.SSLLib   := libWinCrypt;

 

O colega acima mencionou que dessa forma esta utilizando Capicom e vez de WinCrypt, com essa reversão da revisão 15264 este cenário foi modificado? Nos comentários do Cristiano neste post também vejo uma alternância de TLS para funcionamento em determinados sistemas operacionais, para NF-e 4.0 não seria única e exclusivamente TLS 1.2?

 

Agradeço antecipadamente o empenho de todos envolvidos, está sendo bastante produtivo para nós os dois posts.

[RicardoVoigt]

Bom dia,

já que o @André Ferreira de Moraes desfez a alteração lá no SVN (revision 15315), recomendo que atualizem seus fontes e testem novamente, vou fechar este tópico.

Espero ter ajudado...

Att

Ricardo