Ir para conteúdo
  • Cadastre-se

Fabrício G. Araújo

Membros
  • Total de ítens

    427
  • Registro em

  • Última visita

  • Days Won

    2

Tudo que Fabrício G. Araújo postou

  1. Pessoal, ainda estou fazendo pesquisas e testes para ver se é possível fazer algo para que volte a funcionar em GO com OpenSSL os novos certificados. Dando um recapitulada, caso pegue um certificado A1 de um cliente em que está assim: Funciona normalmente o status serviço em Produção em GO, como o Demo, inclusive o cliente está emitindo normalmente com OpenSSL MinGW em nosso sistema. Já com outro certificado A1 mais novo, que está assim: NÃO funciona o status serviço em Produção em GO, como o Demo, esse cliente não funciona de jeito nenhum com OpenSSL MinGW, somente com Wincrypt (com httpWinHttp). Vale lembrar que todas as cadeias de certificados estão instaladas em minha máquina, tanto é que com Wincrypt funciona normalmente. Ah, só lembrando também do erro antigo em GO, que em Homologação nenhum dos certificados funciona em GO o status serviço com o Demo. ... Agora vem alguns questionamentos que talvez a comunidade e principalmente os moderadores possam ajudar nas pesquisas. 1 - Não entendo como funciona internamente a questão do funcionamento dos certificados, mas a suspeita é que com OpenSSL a cadeia de certificados não é enviada. Isso procede? 2 - O Wincrypt funciona pois envia junto as cadeias de certificados associadas? 3 - Se a suspeita 1 acima procede, suspeitamos que os servidores de GO em Homologação não possuem as cadeias instaladas, e em Produção só não possui as últimas cadeias instaladas, pois o certificado mais antigo funciona (Raiz Bras. v2 e Secr. RF v3) e o mais novo não (Raiz Bras. v5 e Secr. RF v4). Esse entendimento está correto? 4 - Agora vem a grande questão: É possível fazer alguma adaptação para que o OpenSSL MinGW envie a cadeia de certificados? Quem participou do desenvolvimento do projeto teria como dar algum direcionamento para que possamos tentar efetuar esse procedimento e se obter sucesso compartilhar com a comunidade? Desculpem pelo grande texto, mas ainda estou empenhado a achar uma solução para GO com OpenSSL MinGW, agradeço a todos que puderem contribuir.
  2. Ainda bem que não tenho mais clientes com WinXP, fiz até um teste na época por curiosidade e até funcionou, mas mesmo assim fiz com que os clientes migrassem. Pois é... infelizmente não estou vendo outra saída... estou chegando a conclusão que pelo jeito em GO em produção (com alguns certificados A1, principalmente novos) não existe nenhuma solução que não dependa da atualização do Windows e/ou configurações do IE. Tinha migrado para OpenSSL justamente por não ter que passar pelo transtorno da atualização do Windows, dando uma solução imediata para o cliente na época. Desanimante uma coisa dessas... ? e sem saber o que está acontecendo. Obrigado por tentar ajudar.
  3. Tenho vários clientes em produção utilizando OpenSSL com MinGW em GO sem problemas, agora estão atualizando os certificados que estão expirando e está parando de funcionar em seus ambientes (produção), dado o erro do título do tópico. Então peguei o problema para analisar e fiquei sem ter como testar (em homologação) com OpenSSL com MinGW, pois infelizmente em GO em homologação não funciona nem os certificados antigos e nem os novos. Sobre alterar para httpWinHttp, sei que não depende de configurações do IE, mas não tenho como fugir da atualização do Windows né?
  4. Eita @BigWings, mesmo com outro certificado, que o cliente está emitindo normalmente em produção, o ambiente de homologação em GO dá o mesmo erro... agora me enrolei mesmo. Será que a questão do problema em homologação está refletindo em produção em GO? O chato é que só está acontecendo com os novos certificados... já não sei mais o que testar, mais alguma sugestão?
  5. @BigWings, estou testando em homologação. Mas em GO em homologação só não funciona o StatusSevico, que nem uso, se enviar funcionava normalmente. Mas para desencargo de consciência vou ver se consigo outro certificado A1 de outro cliente e vou validar o ambiente em GO novamente. @Felipe E. Resende Mesquita, tinha visto exatamente essa dica sua em outro post, já tentei ela. Usei o instalador da VALID (utilizei esse que baixei agora InstaladorCadeias_1.0.2.0.exe), então instalei o certificado, exportei para arquivo pfx e nada. Inclusive para a exportação ainda utilizei essa dica aqui: https://suporte.contabilizei.com.br/hc/pt-br/articles/213827443-Como-exportar-o-seu-certificado-digital-A1-com-chave-privada
  6. @Felipe E. Resende Mesquita, obrigado por tentar ajudar. Verifiquei todo o tópico, e novamente se enquadra em alterações de configuração com ou uso de OpenSSL com SSLHttpLib com httpWinINet (aí voltamos a ter dependência de atualização do Windows e config. do IE), ou outra sugestão foi deixar de utilizar a MinGW (que preferia manter, até para não dar conflito com outro sistema que por acaso utilizasse a openssl original, até porque as dlls da MinGW possui nomes diferentes e as mantenho junto do exe). Vale lembrar que tenho vários clientes em GO utilizando normalmente a solução OpenSSL com MinGW (inclusive com SSL.SSLType = LT_TLSv1_2), mas com a substituição do certificado estão parando de funcionar. É aquela estória... acredito que com certeza o problema está com o novo certificado, mas não sei o que é, fiz várias coisas como atualizar várias cadeias, instalar o certificado e exportar novamente para arquivo depois de instalar novas cadeias e nada de funcionar.
  7. Até onde sei @Augusto Knirsch, com OpenSSL com MinGW funcionaria até no WinXP que nem sequer tem suporte a TLS 1.2, portanto não tem dependência do Windows. O duro é que em GO passou a ser obrigatório o uso de NFC-e no início do ano, então vários clientes adquiriram certificados A1 no fim do ano passado, que agora estarão renovando o certificado e estão começando a apresentar esse erro ao substituir o certificado.
  8. Obrigado por tentar ajudar @Augusto Knirsch, mas não queria dar essa solução de modificar a configuração e ter a dependência do Windows atualizado, por isso queria identificar o que é necessário fazer para que continue funcionando com a OpenSSL com MinGW que funcionava antes normalmente.
  9. Olá pessoal, Encontrei outros posts sobre esse assunto, mas nenhum deu uma solução satisfatória, pois muitos conseguiram fazer funcionar mudando a configuração para Wincrypt ou Capicom, mas não queria partir para essa solução, já que para certificados A1 com OpenSSL com MinGW, não tenho que me preocupar com atualizações do Windows, ou configurações do IE. O cenário que está ocorrendo o problema, é que o cliente estava utilizando o seu certificado A1 normalmente, emitindo NF-e / NFC-e 4.0, com OpenSSL com MinGW, então estava perto de expirar o seu certificado e então adquiriu um novo A1, e agora simplesmente não funciona com o novo certificado, dando o erro: Erro Interno: 10091 Erro HTTP: 500. As configurações utilizadas são de OpenSSL com MinGW: libOpenSSL: SSLCryptLib = cryOpenSSL; SSLHttpLib = httpOpenSSL; SSLXmlSignLib = xsXmlSec; As dlls ficam junto do meu executável, são as mesmas copiadas da pasta ACBr\DLLs\XMLSec\MinGW\32 O certificado é informado via diretório, apontando para o arquivo pfx. Esse cliente em específico é de GO e peguei o certificado dele e o mesmo ocorre em minha máquina. O que vocês sugerem pessoal? Porque parou de funcionar com a solução OpenSSL com MinGW? Quem puder ajudar, agradeço desde já.
  10. Obrigado por tentar ajudar @Daniel Simoes. Perguntei da questão da USB mais por desencargo de consciência, pois sabia que com a Bematech não era possível via ACBrECF. Como o suporte da empresa está no meu pé por conta do "trabalhozinho" a mais de ter que instalar o emulador de porta e configurar novamente o sistema para porta COM, e então devido ao fato de ter (em alguns clientes) ficado mais lento, então o suporte está tentando achar um culpado, que para eles seria deixar de usar a USB diretamente, sendo que sei que não, que apenas tenho que identificar a melhor configuração para resolver o real problema que é a lentidão. A lentidão é a percepção do usuário ao emitir o cupom fiscal, o chato é que nem é possível ver presencialmente e constatar a questão da lentidão, pois somos de GO e praticamente só temos clientes em MG que ainda utilizam ECF. Infelizmente não é possível utilizar o ECFTeste, pois só ocorre em alguns cliente e então não poderia emitir cupons fiscais de testes com o ECFTeste, como disse antes, com a minha ECF de desenvolvimento Bematech 2100 TH FI, funciona normalmente, nada de lentidão. Um dos itens que posso verificar é questão da atualização dos drivers, vai que ajuda, obrigado pela dica. @Daniel Simoes, mas além disso, como você faz em seus sistemas em relação a que tipo de configuração utilizar por modelo de Bematech? Tipo em relação aquelas configurações de Baund Rate, Handshaking, ou outras, você tem uma pré-configuração para cada modelo (MP-2100/MP-4000...), ou disponibiliza em seu sistema para informar essas configurações manualmente, tipo na base de tentativa e erro, ou tem como saber a melhor configuração por modelo? Desculpa pelo textão, mas sem querer abusar da sua boa vontade, se puder passar mais alguma informação que possa ajudar, a ajuda sempre será bem vinda, e agradeço desde já.
  11. Pessoal, Antes utilizada a dll da Bematech para comunicação com as ECF, até já tinha outros modelos de outros fabricantes já programado com uso do ACBrECF, então devido a migração de um Delphi mais antigo para o atual, decidimos migrar e unificar toda a programação para uso único do componente ACBrECF. Só que alguns clientes estão reclamando de lentidão na impressão que não ocorria antes. Seguem algumas perguntas se puderem me auxiliar: 1. Nas pesquisas que fiz, realmente não tem como configurar o ACBrECF para comunicação direta pela USB? Realmente a única opção é somente por emulação de porta COM? 2. Que configurações poderei testar para tentar resolver a questão da lentidão na impressão dos comandos? Tenho uma Bematech 2100 TH FI para desenvolvimento e não tive problema algum, funciona normalmente e super rápido, mas em alguns clientes ocorre a questão da lentidão e como não tem como utilizar o ECF dos clientes para teste fica difícil identificar algo. Quem puder ajudar com alguma dica, qualquer sugestão será bem vinda.
  12. @jcdatrindade, Não uso o Monitor, mas sei que pelo Demo, com uso da WinCrypty, suporta tanto A1 como A3. Essa descrição no Monitor onde está: "Número de Série (Certificado A3)", seria melhor descrita se fosse algo do tipo "Número de Série (Certificado instalado A1 ou A3)". Portanto o que imagino que aconteceu com você, é que está utilizando o certificado A1 da matriz que você instalou, por isso está funcionando normalmente, ou seja, o número de série informado é o A1 da matriz. Não seria isso?
  13. Nossa... não sabia disso @BigWings, muito obrigado pela informação, valeu d+.
  14. Obrigado por responder @BigWings. Realmente inverti as diretivas de compilação, bobeira minha mesmo. Agora não entendi sobre não utilização das dlls da pasta LibXml2, pois a ideia é permitir também a configuração: - libWinCrypt: SSLCryptLib = cryWinCrypt; SSLHttpLib = httpWinHttp; SSLXmlSignLib = xsLibXml2;, ou seja, para certificados A3 utilizaria WinCrypt, e para A1, utilizaria OpenSSL com MinGW, portanto seria um executável só, podendo escolher a configuração. Não teria que distribuir todas as dlls que citei? Realmente, só teria a opção de 32 bits, e sobre as dlls da MinGW, só copiei do pdf, mas realmente pegaria todas da pasta do MinGW
  15. Olá pessoal, Vejam se o meu raciocínio está correto. Caso queira distribuir um mesmo executável do meu sistema, suportando configurar tanto a WinCrypt e OpenSSL (com MinGW), com somente as 2 possíveis configurações associadas: - libWinCrypt: SSLCryptLib = cryWinCrypt; SSLHttpLib = httpWinHttp; SSLXmlSignLib = xsLibXml2; - libOpenSSL: SSLCryptLib = cryOpenSSL; SSLHttpLib = httpOpenSSL; SSLXmlSignLib = xsXmlSec; (com MinGW) Então em relação às diretivas de compilação, ficariam assim: {$DEFINE DFE_SEM_OPENSSL} {$DEFINE DFE_SEM_XMLSEC} {$DEFINE DFE_SEM_LIBXML2} {.$DEFINE DFE_SEM_CAPICOM} {.$DEFINE DFE_SEM_MSXML} {.$DEFINE DFE_SEM_INDY} {$DEFINE USE_MINGW} E em relação as dlls distribuídas junto com o meu executável seriam: libxml2.dll, libxslt.dll, libexslt.dll, libiconv.dll e libxmlsec1.dll, libxmlsec1-openssl.dll, libxml2-2.dll, libexslt-0.dll, libxslt-1.dll, libiconv-2.dll, libintl-8.dll, libltdl-7.dll, libcharset-1.dll, libgcc_s_dw2-1.dll, libwinpthread-1.dll, zlib1.dll E então pessoal, o entendimento é esse mesmo? Tem alguma coisa que deixei passar?
  16. @israeloplopes, além da dica do arquivo .ini do colega, verifica também se a sua pasta schemas está atualizada, pois se estiver desatualizada, não irá aceitar a versão do qrcode 2.
  17. Você ainda está emitindo na versão 3.10 e agora tem que ser a 4.00.
  18. Olá @FabianoCunha, resolvi fazer um teste com a url que está no XML da NFC-e que foi emitida em produção no cliente dia 19/09/2018, e para minha surpresa listou a nota, sem fazer nenhuma alteração no pipe. Então acredito que a Sefaz/GO ajustou a consulta para seguir a especificação da nota técnica corretamente, espero que continue assim.
  19. Ué... SP e CE tem a exigência de equipamento específico (SAT)... não me surpreenderia nenhum pouco... fazer o quê...
  20. @Claudiomir, por aqui a ativamos recentemente em produção (NFC-e 4.0) em MT, e percebemos que vira e mexe acontece algumas instabilidades, como erro de "Erro Interno: 0 Erro HTTP: 404", mas depois volta ao normal. Não sei dizer sobre cancelamento, mas ninguém me relatou nada. Acredito que por esses dias ainda teremos algumas instabilidades, pois as SEFAZ estão correndo para cumprir o prazo e devem estar ajustando seus servidores.
  21. Só uma dica... infelizmente esse site não é muito confiável... pois em GO sempre a bolinha está amarela (nunca vi verde), e por aqui os meus clientes emitem NFC-e normalmente e inclusive na versão 4.00 desde jun/18.
  22. O tópico abaixo foi fechado: Só queria dar continuidade com meu relato, pois consegui autorizar NFC-e no ambiente de Produção em GO, tanto a url que estava antes quando as novas publicadas no post acima, ou seja, em GO não está validando em Produção as urls do qr-code 2.0, aceita qualquer coisa. Testado em Produção com: URL-ConsultaNFCe_2.00=http://www.sefaz.go.gov.br/nfce/consulta e URL-ConsultaNFCe_2.00=http://www.nfce.go.gov.br/post/ver/214344/consulta-nfce O inconveniente de ativar agora o qr-code 2.0 em GO, é que se bipar o código, ainda a Sefaz não está preparada para listar a NFC-e, abrindo um site com mensagem de qr-code inválido. Portanto o que vou fazer é manter o meu sistema já emitindo NFC-e 4.00, mas com qr-code 1.0, então na virada do dia 01/10/2018 (se não adiarem), viro a chave no meu sistema para ativar o qr-code 2.0. Pessoal, como estão se planejando para essa virada?
  23. Já houve uma conversa sobre o assunto aqui: Pelo que entendi, o @FabianoCunha informa que a url em produção está ok, só a de homologação que não... funcionada como você testou mesmo em homologação, igual a da 1.0.
  24. Talvez seja o mesmo caso do MA, chegou a testar não informar a tag do cartão, para isso informe o tpIntegra = tiNaoInformado. No MA a NF-e passa dessa forma.
  25. No seu exemplo, "Produção para Revenda", acredito que não gerou o MVA (pMVAST), porque você não informou nenhum valor para ele, e acredito que pela programação do componente, por se tratar de um campo não obrigatório, ele só é preenchido quando informado um valor. Já no seu exemplo, "Produção uso e Consumo", você utilizou um CSOSN que é um dos mais básicos de todos, que só existem dois campos disponíveis (orig e CSOSN). Dá uma olhada nesse post, que ilustra bem os campos disponíveis para cada tipo de tributação (mas também seria bom verificar a última NT (NT_2016_002_v1_60), que foram criados mais campos):
×
×
  • 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.

The popup will be closed in 10 segundos...