Ir para conteúdo
  • Cadastre-se

dev botao

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


RicardoVoigt
  • Este tópico foi criado há 2114 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

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

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

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.

 

Link para o comentário
Compartilhar em outros 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

Editado por datavale
Complemento
Link para o comentário
Compartilhar em outros 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

Link para o comentário
Compartilhar em outros sites

  • Moderadores

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

  • Curtir 1
djsystem-logo.png
 youtube.png facebook.png instagram.png linkedin.png
André Ferreira de Moraes | Analista de Sistemas
www.djsystem.com.br | www.djpdv.com.br
www.tefhouse.com.br | www.lambretinha.com.br
Link para o comentário
Compartilhar em outros 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

 

Link para o comentário
Compartilhar em outros 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.

Link para o comentário
Compartilhar em outros sites

  • Moderadores

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

  • Curtir 2
djsystem-logo.png
 youtube.png facebook.png instagram.png linkedin.png
André Ferreira de Moraes | Analista de Sistemas
www.djsystem.com.br | www.djpdv.com.br
www.tefhouse.com.br | www.lambretinha.com.br
Link para o comentário
Compartilhar em outros 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.

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

  • Fundadores

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 

 

  • Curtir 2
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

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

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

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.

Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 2114 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.