messiashenrique

Olá! Antes de mais nada, o objetivo desse tópico não é cobrar nenhuma solução célere para o caso. Antes porém, abrir espaço para que possamos, juntos, encontrar um modo de resolver o problema. Primeiramente é importante salientar que o ambiente para simular o problema deve ser estritamente o seguinte: 1) Lib: OpenSSL 2) webservice de Goiás 3) Ambiente de homologação. Bom, venho há algum tempo tentando encontrar alguma solução para contornar o erro obtido ao tentar a requisição de um simples status de serviço, por exemplo, usando a configuração mencionada acima. Na imagem, vemos a mensagem de erro retornada: Vou ressaltar novamente que o erro acontece no ambiente de homologação... Em produção, tudo ok, como pode ser observado abaixo: : Eu já li praticamente todos os tópicos do fórum sobre esse erro e outros parecidos... Não tenho como garantir (ainda), mas em alguns casos, citam como justificativa que isso ocorre porque o servidor (GO) redireciona para um site não seguro. Porém, eu acredito que isso não procede. O quê eu acredito que está acontecendo: 1) A mensagem de erro é bem clara: "alert unknow CA" (Isso não nos quer dizer que o servidor espera, na requisição, a definição de um CA???) 2) A nota abaixo é antiga, mas acho que está sendo aplicada, no entanto, na nota os ambientes estão trocados... (o ambiente de homologação é que exige a cadeia completa): No entanto, tentei fazer uma inspeção nos servidores e obtive o seguinte: Homologação: Produção: Não consigo definir ao certo, pelo resumo qual é a diferença que provoca esse erro... Contudo, sei que usando outras bibliotecas, como por exemplo, winCrypt, não se esbarra nesse erro. Ou seja, isso é resolvido aqui do lado cliente. Logo, penso que podemos atacar o bind da openssl (pascal) que o ACBr usa. Já li e reli todo o arquivo, mas o meu conhecimento em C é muito raso e eu ainda não consegui descobrir qual chamada deveria ser alterada... Ainda tenho a preocupação da incerteza de isso ser possível usando a OpenSSL 1.0.x. Talvez a solução fosse migrar para a OpenSSL 1.1.x logo, embora sei que a compatibilidade ficaria toda comprometida o que acarretaria um retrabalho hercúleo... Nesse caso, até deveria se pensar na possibilidade oferecer suporte a uma outra lib (quem sabe gnuTLS - que NMHO parece ser mais evoluída e estável...). Resumindo: Sei que temos problemas nesse sentido, mas estou muito motivado a encontrar alguma solução. Se alguém puder acrescentar alguma informação a respeito disso, tenho certeza de que iremos progredir. Ah! Por favor, desconsiderem sugestões de "usa winCrypt e etc...", pois o ambiente não se limita ao windows. Bem! Desculpe pelo tópico extenso e carregado de imagens, mas não consegui ser mais sucinto. Ps.: Senhores moderadores, confesso que fiquei muito em dúvida sobre onde postar esse tópico. Se esse não for o lugar adequado, sintam-se livres para movê-lo e desculpem-me por isso.

Exatamente! Independente do Layout 3.1 ou 4.0 o ambiente de homologação do webservice de Goiás sempre retorna erro 500 quando se usa OpenSSL. No meu caso, que estou usando Linux, não tenho outra alternativa além dessa... Também tentei contato com o pessoal do atendimento, mas eles dizem que está tudo certo!

Pessoal, boa noite! Ainda temos um problema com o ambiente de homologação de Goiás quando é usado a openssl. O interessante é que funciona em ambiente de produção, mas em homologação não. Vou enfatizar novamente que isso acontece apenas com a lib OpenSSL. Em Windows eu consigo contornar isso facilmente usando winCrypt, mas em Linux ainda não visualizei nenhuma solução. Entrei em contato com o suporte aqui de Goiás e eles ficaram de me responder... Mas não entendem nada quando eu digo OpenSSL e etc... Se alguém tiver qualquer ideia do que fazer, será de grande valia a ajuda. Mas, por favor, tem que ser com OpenSSL. Desde já, grato pela atenção de todos.

Muito estranho porque o a requisição específica a versão 4.0 e o servidor responde 3.1... Isso não é normal, né? Obs.: Desculpem-me, respondi ao mesmo tempo que o Ítalo... (ele postou a mesma observação)

Olá Daniel, boa tarde! Já conseguiu fazer funcionar o OpenSSL e TLS1.2 nos webservices de Goiás?

Excelente! É exatamente como o colega @almp1(André) citou no post. Mas se precisarem de mais informações, tem aqui , aqui para extrair as chaves do certificado... e também aqui (onde me ajudou bastante). Bem, por ora, muito obrigado @Daniel Simoes e todos que tem se esforçado nesse empreito. Att. Messias Henrique

Excelente ideia. Assim, fica bem mais simples. Normalmente, era necessário fazer intervenções no código ACBr. Então, toda vez que atualizava via svn, quebrava o código... Se tiver como dar um ok aqui nesse tópico assim que esse evento estiver comitado , seria de grande auxílio. 1) Sim, no Linux 32bits é possível sem, praticamente nenhuma modificação nos fontes. Basta que as libs (open, xml2, xmlsec) sejam instaladas do jeito que o ACBr espera. Normalmente tem instalar a xmlsec no braço (make, make install) e também criar links simbólicos adequados dependendo da distribuição. 2) Até amanhã, eu ṕosto aqui uma maneira de chamar o executável (xmlsec1) para assinar o xml. (a título de sugestão, é claro) Att. Messias Henrique

Bem Adriano. No Linux, enquanto não temos a solução para a versão 64bits, eu resolvi ficar com a versão 32bits mesmo. Já no MacOS, eu tive que improvisar e consegui chamar, por linha de comando, o executável do xmlsec que assina o arquivo. Isso também pode ser feito em Linux. Basta chamar através de um TProcess, por exemplo. Veja bem, eu disse o executável e não a biblioteca dinâmica (dll ou so ou dynlib etc...) Claro que é uma gambiarra, mas... é uma ideia... apenas. Att. Messias Henrique

Olá Adriano, boa tarde! Então, na verdade, hoje é possível instalar o ACBrNFe e etc... no Linux 64bits sem, praticamente, nenhuma modificação do código baixado via svn. No entanto, como pode ser visto no tópico, que você mesmo citou, ainda estamos buscando uma solução para o pleno funcionamento. Eu também tenho acompanhado isso tudo há anos... e, agora acho que estamos bem perto de chegar nela! O erro ocorre exatamente na hora de assinar o documento. No finalzinho do tópico (linkado acima), percebe-se que que os esforços tem dado resultado. Mas, ainda não conseguimos fazer o Lazarus (ACBr) gerar a bendita assinatura. (Lembrando que possível assinar manualmente via terminal e etc...) Neste último sábado, fiquei horas pelejando também, mas não tive nenhum avanço. Sugiro que leia o tópico e faça testes no código das bibliotecas xmlsec e etc... Talvez você consiga ver algo que não vimos ainda. O fato é que, somos nós mesmos quem temos que resolver. Bem vindo ao fórum. Att. Messias Henrique

Olá @almp1, tudo bem sim e você? Então, desculpe-me pela demora... Estes dias estive ausente desse universo... (rsrsr). Só agora vi suas mensagens. Vou voltar a mexer nesse projeto a partir da semana que vem. Quem sabe a gente consegue descobrir o que se passa... Em um passado não muito distante, eu tive que improvisar nesse projeto e fiz uma gambiarra (argh!) onde eu gerava o xml pelo ACBr e depois validava e assinava pela através dos executáveis xmlsec1 e openssl (usando o TProcess) . Mas isso é horrível e acredito que é possível fazer tudo pela lib mesmo. No entanto, não cheguei a tentar dessa última vez... Embora, provavelmente, irei esbarrar no mesmo problema que você. Dessa vez estou mais otimista... Assim que tiver iniciado os testes volto aqui para dar um parecer, ok? Att. Messias Henrique Olá @EMBarbosa, tudo bem, né? Desculpe-me pela demora ao responder... Estive ausente alguns dias... Então, acho que ainda temos que ajustar algumas coisinhas.... Assim que conseguirmos corrigir alguns detalhes, vou sim tentar entrar em contato com o pessoal do libxml2-pas para sugerir as mudanças... (embora tenho a impressão - só a impressão mesmo - que o projeto está meio parado). Enfim, não custa nada tentar! Att. Messias Henrique

Olá Daniel, bom dia e obrigado. Então, Daniel, antes cheguei a pensar isso também... Mas fiz um pequeno teste e vi que o problema não é ao carregar a Lib e sim ao criar a parte gráfica com lib carregada. Da forma que está, a lib é carregada em um handle no início da execução do método e logo depois é liberada. Fiz esse teste em um form mesmo e vi que dava certo. Então acreditei que ia funcionar também com o componente. Veja as imagens em anexo Att. Messias Henrique Agora precisamos testar em outros ambientes (principalmente Windows com Delphi - que não tenho aqui). Acredito que funcione, mas é bom testar! Att. Messias Henrique

Na linha 399 da unidade Unit1.pas do exemplo ACBrNFe_Demo temos o seguinte: edtPathSchemas.Text := Ini.ReadString( 'Geral','PathSchemas' ,PathWithDelim(ExtractFilePath(Application.ExeName))+'Schemas\'+GetEnumName(TypeInfo(TpcnVersaoDF), integer(cbVersaoDF.ItemIndex) )) ; Sugiro que alterem para edtPathSchemas.Text := Ini.ReadString( 'Geral','PathSchemas' ,PathWithDelim(ExtractFilePath(Application.ExeName))+'Schemas'+PathDelim+GetEnumName(TypeInfo(TpcnVersaoDF), integer(cbVersaoDF.ItemIndex) )) ; Isto é, troquem a "\" (barra invertida - delimitador de paths do windows) por "PathDelim", por exemplo. Assim, funcionará no Windows e Linux com a mesma eficiência. Att. Messias Henrique

Olá comunidade! É com imenso prazer que venho comunicar-lhes a compatibilidade dos componentes ACBrNFe, ACBrCTe e etc... em ambientes Linux 64btis. Sim. Agora é possível! Depois de um longo tempo de tentativas, resolvi, neste fim de semana, remover dotas as chamadas estáticas que haviam nas unidades: libxmlsec.pas, libxml2.pas, libxslt.pas e libexslt.pas e reconstruir apenas as necessárias com implementações que realizam chamadas dinâmicas às bibliotecas. Nenhuma modificação foi realizadas em unidades "específicas do projeto ACBr" e sim apenas nos quatro arquivos citados acima. A princípio, percebi que era possível recriar a LCL (Lazarus) se não fosse realizado nenhum vínculo estático com libs 64bits (ou universais - caso MacOS). Logo resolvi reimplementar todos os métodos existentes nessas bibliotecas com chamadas dinâmicas. No entanto, qual foi minha surpresa, existem milhares (sem exagero) de métodos com vinculação estáticas nesses arquivos. Só no libxml2, para se ter uma ideia, depois de criar um pequeno automatizador para me auxiliar na conversão, o arquivo ficou com mais de 35 000 linhas e alguns erros em funções desnecessárias ao funcionamento dos componentes do ACBr. Logo, eu resolvi recriar apenas aquelas que eram necessárias (algumas dezenas). Feito isso, consegui compilar, recriar a IDE e fazer funcionar o componente ACBrNFe (acredito que outros também funcionarão, já que não houve nenhuma modificação ao nível deles). Reforçando: Todas as modificações se deram nos quatro arquivos já citados acima que fazem parte do pacote ACBrOpenSSL. As unidades modificadas podem ser encontradas em https://github.com/messiashenrique/xmlsec4pascal e em anexo nesse post. Gostaria de salientar que estou fazendo testes em ambiente Linux 32 e 64bits (usando Ubuntu 15.10). Portanto, ficaria muito grato se alguém pudesse testar no Windows tanto com Delphi como com o próprio Lazarus. Obs.: Tentei postar aqui os prints de tudo funcionando e as próprias unidades modificadas, mas aparece um janelinha dizendo que só posso fazer upload de 1024kb, sendo que as unidades zipadas medem 83kb e os prints também são pequenos. Qualquer dúvida quanto a instalação,, ou outra qm que eu puder ajudar, coloco-me a disposição. Att. Messias Henrique

Olá vca_rj! Eu estou migrando os meus relatórios para o LazReport que é nativo, (vem junto com os pacotes de instalação, mas precisa ser instalado). Usava o Fortes, no entanto, acredito que o LazReport já amadureceu bastante. Ele é baseado no FreeReport que é um componente free criado e mantido pela mesma empresa que desenvolve o famoso FastReport. Porém alguns componentes do ACBr (ACBrDANFe, por exemplo,) por enquanto, possuem apenas versão baseada no FortesReport. É possível implementar um DANFe em cima do LazReport, mas isso demanda um certo trabalho... Assim que eu tiver tempo, vou tentar... Att. Messias Henrique

Olá, Krahe! Que bom que você consegui instalar o ACBrCTe! Eu não precisei dele até o momento então nunca havia tentado instalá-lo. Sobre o ACBrNFe eu passei pelas mesmas dificuldades que você... Sofri demais mesmo... exatamente por conta da arquitetura das bibliotecas. Também uso o Mavericks e naturalmente ele já tem algumas libs em 64bits e quando se compila sem algumas instrução extra elas são geradas em 64bits e, enquanto isso, o Lazarus fica buscando as libs em 32bits. No entanto eu descobri que é possível, no Mac OS X ,fazer uma mesclagem de um biblioteca 32bits com a mesma biblioteca em 64bits (usando o LIPO) aí você tem um lib mista. Isso foi ótimo... Só assim consegui instalar o ACBrNFe, porém esse não foi o fim dos problemas. Quando fui fazer testes de utilização, esbarrei no problema da assinatura... a função que realizava a assinatura não era encontrada na lib... Fiz de tudo, mas não consegui resolver da maneira "politicamente correta"... Então apelei para uma chamada ao executável do "xmlsec1" e fiz a assinatura por debaixo dos panos... No final eu vi que tinha feito tantas modificações no componente que estava inviável compatibilizar com outras plataformas (S.O.'s). Logo, nem tive coragem de mencionar aqui no fórum rsrsrs. Não sei se você chegou ater esses problemas de assinatura do xml. Se tiver e encontrar uma solução melhor, adoraria saber... Ah! Não sei como você resolveu a questão das libs (32bits)... Se fez igual eu fiz... Talvez podeŕiamos alinhar as nossa soluções e conseguir tratar dentro de diretivas específicas para o DARWIN, assim seria possível manter o mesmo código do componente oficial... Vou voltar a mexer na bagunça que fiz em breve... Talvez olhando novamente vejo uma solução mais razoável... Vou torcer para que os componentes que você instalou funcionem perfeitamente. E se assim ocorrer, gostaria de saber como compilou as libs (principalmente a libxmlsec), ok? []'s Messias Henrique