Jump to content

Embarcadero Conference 2019

22/10 - Visite o Stand do ACBr
Saiba mais

Nova Loja Oficial
loja.projetoacbr.com.br
Ajude o projeto a crescer, com estilo

Comprar

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

RicardoVoigt

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Edited by datavale
Complemento

Share this post


Link to post
Share on other sites

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

 

Windows7.png

Share this post


Link to post
Share on other sites
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 !!!

 

Share this post


Link to post
Share on other sites
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é?

statusservico-v400-TLSv1_1.png

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 

 

  • Like 2

Consultor SAC ACBr

Daniel Simões de Almeida
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...