Pesquisar na Comunidade

Senhores, bom dia! Estou tentando usar a versão de 64bits do ACBrMonitor mas está dando a mensagem "EACBrDFeException - Erro ao carregar bibliotecas do OpenSSL". Este erro ocorre ao tentar ver o Status Serviço da NF-e ou ver as informações do certificado. Na versão de 32 bits do ACBrMonitor funciona normalmente. Já removi os arquivos LIBEAY32.DLL e SSLEAY32.DLL da pasta e coloquei as verões de 64 bits baixas de http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/x64/ e mesmo assim o problema persiste. Tem mais alguma coisa necessária a ser feita?

Acredito que eu esteja enfrentando problemas com as DLLs para usar o ACBrMail; Exemplo: Na minha máquina eu mando minha aplicação enviar 100, 200 e-mails e uma vez (sem thead) e ela envia de boa. Na máquina do cliente, só envia 6, 7, no máximo 10 e dá erro nos demais (smtp error : Unable to login), aí eu tenho de fechar a aplicação e abrir de novo, mandar enviar de novo, aí a aplicação vai enviar novamente no máximo, 6, 7, 10 e gerar erro novamente nos demais. Aí tenho de repetir a operação até terminar os 100, 200 e-mails. E não é problema no Servidor de Hospedagem, pois as duas máquinas tem as mesmas configurações do ACBrMail. Host, User, Senha, etc, etc. O que muda é que minha máquina tem o Delphi instalado. Gostaria que me sanassem minhas dúvidas em relação às DLLs usadas pelo ACBrMail. Afinal, qual a dll o ACBrMail utiliza? Qual devo jogar na pasta da minha aplicação? Até a pouco tempo eu usava libeay32 e ssleay32, agora aparecem LibCrypto e LibSSL na pasta OpenSSL do ACBr. E estas 2 últimas aparecem com os nomes libcrypto-1_1-x64 (ou x86) e libssl-1_1-x64 (ou x86). Para usar elas eu tenho de renomea-las? deixar só LibCrypto e Libssl? E as libeay32 e ssleay32? não precisa mais? Preciso registrar as DLLs? ou não precisa, basta estar na pasta da minha aplicação? E devo usar as DLLs versão 32 ou 64 bits? O Windows é 64 bits, a aplicação 32 bits.

Olá, estou precisando usar o o LT_TLSv1_2 só que aparece o erro : fev 14, 2020 1:53:54 PM com.acbr.nfe.principal.FrmMain btnStatusServActionPerformed GRAVE: null java.lang.Exception: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. OpenSSL 0.9.8e 23 Feb 2007, não suporta LT_TLSv1_2 gostaria de saber se devo atualizar as DLL's libeay32.dll e ssleay32.dll e como isso é feito no projeto Java. ACBrLibNFE-20200214.log

ATUALIZAÇÃO: As informações abaixo podem ser desconsideradas. Veja o próximo post que mostra que o ACBr é compatível com o OpenSSL 1.1.x. Olá, Como sabemos, diversos componentes do ACBr utilizam a lib OpenSSL para comunicação segura. No Linux utilizamos exclusivamente a lib OpenSSL, até o momento o ACBr é compatível apenas com versões 1.0.v da OpenSSL mas algumas distros do Linux instalam por padrão, a versão 1.1.v, neste caso é necessário baixar e instar a versão anterior para funcionar com o ACBr... Segue abaixo o procedimento para atualização: 1- Para saber qual versão OpenSSl está instalada no Linux, utilize o comando: # openssl version Se estiver utilizando a versão 1_1_v, precisará baixar e instalar a versão 1_0_v. 2- No nosso exemplo estamos utilizamos a distro OpenSuse Leap 15.1, que por padrão é instalada com a versão 1_1_v da OpenSSL. Utilizando a ferramenta de Instalação de Pacotes YaST do OpenSuse, selecionamos a opção: "Software" e "Gerenciamento de Software". Pesquisamos por: "OpenSSL" - Selecione para instalar a versão OpenSSL-1_0_0 que esta disponível no seu repositório (Note que é a versão 1.0.2p), será informado que precisa desinstalar algumas dependências da versão atual. Selecione a primeira opção e dê OK. - Selecione para instalar também a LibOpenSSL-1_0_0. (caso essa dependência não seja adicionada automaticamente no passo anterior). Click em Aceitar para Baixar e Instalar... 3- Confira os pacotes da versão OpenSSL 1_0_0 que precisam estar instalados: obs: Caso esteja obtendo o erro abaixo na tentativa de comunicação com a SEFAZ, significa que está faltando alguma dependência da OpenSSL-1_0_0 para ser instalada, basta instalar todas as dependências conforme está no passo 3.

Boa tarde pessoal, estou instalando meu sistema em computador com windows 10 64Bits Single language, já copiei todas as DLL's utilizadas pelo ACBR, conforme descrito beste tópico. Porém continuo não conseguindo abrir o sistema. Mensagem de erro: O aplicativo não pôde ser iniciado corretamente (0xc000007b). Mais alguma ideia do que pode ser?

Erro 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor. O erro acima está acontecendo no cliente mesmo com todas as atualizações dos Windows instaladas e a configuração correta para certificado A3, no caso WinCrypt. Alguém pode ajudar ?

Boa tarde, tudo bem? Estou com problemas na transmissão do MDF-e, onde o erro "1824 - Element '{http://www.portalfiscal.inf.br/mdfe}cInt': '17' is not a valid value of the local atomic type." é retornado. Em resumo, sempre que o campo 'cInt', que representa o 'Código interno do veículo', tem exatamente 2 caracteres, esse erro é retornado. Em nosso sistema, usamos dois tipos de DLLs: As do tipo OpenSSL, através da biblioteca xsXmlSec, para certificados apontados de arquivos, e as do tipo MSXML5, através da biblioteca xsMsXml, para certificados instalados. O usuário define a melhor opção. Realizei vários testes alternando entre essas duas opções, e renomeando os Schemas do MDFe, e após os testes percebi que somente quando usado o OpenSSL com os Schemas conforme vêm no ACBr (usando o arquivo 'tiposGeralMDFe_v3.00.xsd' por padrão) é que acontece esse erro, mas se usado o MsXml, esse erro não ocorre, e ao renomear os arquivos para usar sempre o arquivo 'tiposGeralMDFe_v3.00-OPENSSL.xsd', o erro não ocorre em nenhum dos dois tipos de transmissão. Ao comparar esse dois Schemas, vi que a única diferença entre eles está na linha 565: <xs:pattern value="[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}"/> (no OpenSSL, ao invés do "{0,}" temos o "*") Gostaria de saber porque existem esses dois arquivos de Schemas, sendo que o 'tiposGeralMDFe_v3.00-OPENSSL.xsd' funciona para os dois casos. Seria para alguma outra biblioteca? Desde já agradeço pela ajuda e compreensão. Valeu!

Pessoal, até o momento estávamos utilizando a Capicom para assinar os XMLs da NFS-e. Mas por causa de problemas em alguns provedores, mudamos para a WinCrypt. Mas agora ao abrir o executável pede várias DLLs, exemplo: iconv.dll, libxml2.dll, libxmlsec.dll, libxslt.dll e zlib1.dll Isso está normal? Fiz tudo certo?

Estou com essa mensagem ao tentar validar uma nota usando openssl. Access violation at Address 74AF934E in module 'msvcrt.dll'. Read of address 00000000. Uso delphi xe5 mas o erro ocorre tambem no delphi 7. Windows 10 x64. Estranho que estava funcionando tudo certinho. Grato, Diran erro acbrnfe.docx

Olá pessoal, Com o intuito de acabar com a dependência da CAPICOM, nos fontes do Projeto ACBr, apliquei um amplo refactoring, nas Units de ACBrDFeSSL e suas derivadas... O que é CAPICOM ? https://en.wikipedia.org/wiki/CAPICOM Porque usávamos a CAPICOM ? Usar diretamente as APIs do Windows não é uma tarefa simples.... A CAPICOM, facilita um pouco, as tarefas que podem ser feitas com a WinCrypt (ou MS Crypto), para acesso a certificados digitais instalados no Windows Quais as desvantagens da CAPICOM ? A Microsoft condenou a mesma como obsoleta. (esse é o principal motivo) Ela precisa ser registrada no Windows para funcionar Não suporta 64 bits O que será usado no lugar da CAPICOM ? Usaremos diretamente as APIs do Windows, ou seja, a WinCrypt (também conhecida como "MS Crypto" ou "CAPI"). Ou seja, encaramos o desafio e agora usamos apenas métodos da WinCrypt para acessos a Certificados Digitais no Windows. Para facilitar o acesso a API WinCrypt, estamos usando as Units do diretório: "Fontes\Terceiros\CodeGear\", mas especificamente a Unit "ACBr_WinCrypt.pas". Quais as vantagens da WinCrypt ? Ela está presente de forma nativa, em todas as versões do Windows (desde o Windows XP), ou seja, não requer instalação. Possui versões 32 e 64 bits Não requer registro da DLL Não requer a instalação de pacotes .NET ou Java Onde posso encontrar a WinCrypt ? Ela já está instalada, de forma nativa, no seu Windows... com o nome: "crypt32.dll" Se o seu Windows é 64 bits, você encontrará a mesma em: 32 bits: "C:\Windows\SysWOW64" 64 bits "C:\Windows\System32" Se o seu Windows é 32 bits, você encontrará a mesma em: "C:\Windows\System32" O suporte a Delphi7 será mantido ? SIM. Apesar de já anunciarmos o fim do Suporte a D7, tivemos o cuidado de testar as alterações no D7. Para isso, adaptamos as units da pasta "Fontes\Terceiros\CodeGear\" para o suporte a D7... Como configurar para usar a WinCrypt e não a CAPICOM ? A maneira mais simples é configurar a seguinte propriedade: ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; Na verdade, a propriedade ACBrDFe.Configuracoes.Geral.SSLLib passou a ser virtual... ou seja, ela configurará de forma indireta, as 3 novas bibliotecas de TDFeSSL... Se você ler os fontes, quando rodamos o código acima, o seguinte código será executado. procedure TGeralConf.SetSSLLib(AValue: TSSLLib); case AValue of ..... libWinCrypt: begin SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsMsXml; end; end; Se você deseja uma configuração diferenciada, poderá configurar as bibliotecas individualmente...Exemplo: ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinINet; ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec; Como remover completamente, as Units da CAPICOM dos meus fontes ? Abra o arquivo \ACBr\Fontes\ACBrComum\ACBr.inc e altere a seguinte linha: {.$DEFINE DFE_SEM_CAPICOM} para: {$DEFINE DFE_SEM_CAPICOM} Ou seja, remova o "." do inicio O que mudou em ACBrDFeSSL ? Muita coisa.... (veja abaixo o trecho do "Change-Log").. Estudar os fontes do projeto Demo "\ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi", é a melhor maneira de conhecer as modificações. Veja abaixo, um resumo ilustrado: 1 - Agora você pode criar a sua própria janela de escolha de Certificado Veja esse exemplo de código, extraído de ACBrNFe_Demo. onde usamos o método "ACBrNFe1.SSL.LerCertificadosStore", para carregar todos os certificados da Store, definida em "ACBrNFe1.SSL.StoreName", após isso, as informações dos certificados podem ser obtidas em "ACBrNFe1.SSL.ListaCertificados" ACBrNFe1.SSL.LerCertificadosStore; For I := 0 to ACBrNFe1.SSL.ListaCertificados.Count-1 do begin with ACBrNFe1.SSL.ListaCertificados[I] do begin 2 - Agora você pode selecionar as bibliotecas de TDFeSSL, individualmente CryptLib: Permite definir qual será a biblioteca de Criptografia. Ela possui métodos como:"SelecionarCertificado", "CarregarCertificado", "CalcHash". além de propriedades como "DadosCertificado" e "ListaCertificados". TSSLCryptLib = (cryNone, cryOpenSSL, cryCapicom, cryWinCrypt) HttpLib: Usada para acesso HTTP e HTTPs, permitindo informar o Certificado na conexão. Possui métodos como: "Enviar" e propriedades como: "HTTPResultCode" e "InternalErrorCode" TSSLHttpLib = (httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy); XMLSignLib: Usada para validar XMLs (contra um Schema), assinar um XML, Validar a assinatura existente em um XML. Possui métodos como: "Assinar", "Validar" e "VerificarAssinatura" TSSLXmlSignLib = (xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom); 3 - Independência das configurações de segurança do I.E. Isso pode ser obtido, se você utilizar SSLHttpLib = "httpWinHttp" ou "httpOpenSSL" Você poderá definir nos seus fontes, independente das configurações do Internet Explorer, configurações como o Tipo de segurança e TimeOut da tentativa de conexão. Essa funcionalidade já estava presente nas Units de acesso que utilizavam o OpenSSL a algum tempo. e agora com a nova Unit que faz acesso a HTTPS, usando a API do Windows chamada "WinHTTP", isso também será possível. O modelo: "httpWinINet" irá usar a API do Windows, chamada "WinINet", a qual já utilizávamos, e ela depende de configurações do I.E. 4 - Carregar o certificado por ArquivoPFX ou DadosPFX, com a WinCrypt ou CAPICOM Essa funcionalidade já estava presente, quando SSLCryptLib = cryOpenSSL. e não estava disponível para CAPICOM. Mas agora isso é possível, com a SSLCryptLib = cryCapicom ou cryWinCrypt. Ou seja, Se você tem um certificado A1, você não precisa instalar o certificado no Windows. Isso pode parecer pouco importante em uma primeira impressão... Mas veja as possibilidades: O certificado A1 poderia estar em um Banco de dados, ou em um Servidor Web, e ser carregado de forma dinâmica pela sua aplicação, independente de ser instalado manualmente no Windows. 5 - Compilar seu Executável em 64 bits Lembre-se que quando você compila o seu programa em 64 bits, todas as DLLs externas de qual ele necessitar, também devem ser de 64 bits. Portanto para isso, você não poderá usar a XMLSignLib = xsMsXml, pois a biblioteca da Microsoft para assinatura de XMLs "MSXML" não possui versão 64 bits. Mas observe que agora você pode usar a biblioteca WinCrypt com a XmlSec, basta configurar corretamente as bibliotecas de criptografia. Nota: Ainda não conseguimos, fazer com que a XMLSec possa usar certificados A3, mas isso deverá ser possível no futuro, pois a XMLSec tem suporte a "MSCrypto" Diagrama de Classes Como posso ajudar ? (Tarefas a serem efetuadas) 1 - Fazer a XmlSec funcionar usando a "mscrypto" Ainda não conseguimos fazer a XMLSec, usar a MSCrypto, atualmente ele apenas usa a "openssl". Porque isso é importante ? Temos vários problemas, com a msxml, como por exemplo: A Microsoft não distribui a mesma, de forma nativa, com o Windows (arquivo msxml5.dll) Ela não suporta 64 bits A licença de uso dassa biblioteca, é valida apenas para quem tem o Office instalado... Portanto, seria ótimo se pudéssemos ficar livres da MSXML, mas para isso, precisamos fazer o ACBr conseguir usar a XMLSec com suporte a MSCrypto (hoje ele só suporta OpenSSL)... Na verdade, já podemos usar WinCrypt + XmlSec, mas apenas para certificados A1, pois o ACBr é capaz de exportar o certificado A1 do Windows, para que o mesmo seja usado pelo OpenSSL. (ele fará isso internamente, e de forma transparente para o usuário) Quando conseguirmos fazer a XmlSec usar a MSCrypto (ou WinCrypt), conseguiremos compilar a aplicação em 64 bits, e com suporte a certificados A3 2 - Compilar os fontes da XMLSec no Windows, em 32 e 64 bits Hoje o único site que distribui a XMLSec já compilada para Windows é https://www.zlatkovic.com/libxml.en.html (Thanks Igor). Entretanto, podemos notar que os binários estão defasados, e não há uma versão 64 bits, com suporte a "mscrypto" Veja como ficou o "Change-Log" do refactoring em ACBrDFeSSL -- ACBrDFeSSL -- [*] Amplo refactoring promovido, separando a classe "TDFeSSLClass" em 3 novas classes: "TDFeSSLCryptClass" - para Carregar certificados e efetuar criptografia "TDFeSSLHttpClass" - para comunicação HTTP/HTTPS com suporte a Certificados "TDFeSSLXmlSignClass" - Para Validar XMLs, validar assinaturas e Assinar XML com Certificados [+] "TSSLLib", adicionado os tipos "libWinCrypt, libCustom" [+] Criada nova classe "TDadosCertificado", para conter os dados do certificado carregado [+] Criada nova classe "TListaCertificados",para conter uma lista de Objetos do tipo TDadosCertificado, com todos os certificados de uma "Store", e após a chamada do método "TDFeSSL.LerCertificadosStore" [+] Adicionada propriedade "TDFeSSL.StoreName: String", usada apenas no Windows. Nome da Store a ser aberta, padrão "MY" [+] Adicionada propriedade "TDFeSSL.StoreLocation: TSSLStoreLocation", usada apenas no Windows. Default "slCurrentUser". TSSLStoreLocation = (slMemory, slLocalMachine, slCurrentUser, slActiveDirectory, slSmartCard); [+] Adicionado o método: "TDFeSSL.LerCertificadosStore", apenas Windows, para carregar todos os Certifcados de "TDFeSSL.StoreName" para a lista de Objetos: "TDFeSSL.ListaCertificados" [+] Adicionado a propriedade "TDFeSSL.DadosCertificado", para permitir acesso aos dados do certificado carregado [+] Adicionada a propriedade "TDFeSSL.SSLCryptLib: TSSLCryptLib" default cryNone; para definir a classe de criptografia TSSLCryptLib = (cryNone, cryOpenSSL, cryCapicom, cryWinCrypt); [+] Adicionada a propriedade "TDFeSSL.SSLHttpLib: TSSLHttpLib" default httpNone; para definir a classe de comunicação HTTP/HTTPS TSSLHttpLib = (httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy); [+] Adicionada a propriedade "TDFeSSL.SSLXmlSignLib: TSSLXmlSignLib" default xsNone; para definir a classe de assinatura de validação de XML TSSLXmlSignLib = (xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom); [+] Adicionada a propriedades "TDFeSSL"SSLType: TSSLType" default LT_all; para permitir definir o tipo de criptografia em HTTPS sendo: TSSLType = (LT_all, LT_SSLv2, LT_SSLv3, LT_TLSv1, LT_TLSv1_1, LT_TLSv1_2, LT_SSHv2) suportado apenas em TDFeHttpOpenSSL e TDFeHttpWinHttp -- ACBrDFeConfiguracoes -- [+] Adicionada as propriedades: property SSLCryptLib: TSSLCryptLib property SSLHttpLib: TSSLHttpLib property SSLXmlSignLib: TSSLXmlSignLib [*] Propriedade "SSLLib: TSSLLib" passou a ser virtual, e mantida por compatibilidade. Ajusta-la irá produzir ajustes em "SSLCryptLib", "SSLHttpLib" e "SSLXmlSignLib". Exemplo: if SSLLib = libOpenSSL then begin SSLCryptLib := cryOpenSSL; SSLHttpLib := httpOpenSSL; SSLXmlSignLib := xsXmlSec; end; -- ACBrDFe -- [+] Adicionado suporte a configurações de "SSLCryptLib", "SSLHttpLib", "SSLXmlSignLib" -- ACBrDFeOpenSSL -- [*] Amplo refactoring. Removido código referente a comunicação HTTP/HTTPs que foi migrado para "ACBrDFeHttpOpenSSL" [*] Removido código referente a assinatura digital e Validação de XML, que foi migrado para "ACBrDFeXsXmlSec" -- ACBRDFeWinCrypt -- [+] Nova Unit, para manipular Certificados do Windows e efetuar assinatura digital, usando a Win API WinCrypt (MSCrypto/CAPI) -- ACBrDFeCapicom -- [*] Refactoring, para usar boa parte do código de "ACBRDFeWinCrypt" -- ACBrDFeHttpOpenSSL -- [+] Adicionada nova Unit, derivada de ACBrDFeOpenSSL, criando implementação da classe de TDFeSSLHttpClass para comunicação http e https, usando a Synapse e OpenSSL -- ACBrDFeHttpWinApi -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLHttpClass para comunicação http e https, usando as APIs do Windows WinHttp ou WinINet -- ACBrDFeHttpIndy, ACBrDFeCapicomDelphiSoap -- [*] Unit renomeada de "ACBrDFeCapicomDelphiSoap" para "ACBrDFeHttpIndy", e refatorada para não depender da CAPICOM -- ACBrDFeXsXmlSec -- [+] Adicionada nova Unit, derivada de ACBrDFeOpenSSL, criando implementação da classe de TDFeSSLXmlSignClass usando a Lib XMLSEC -- ACBrDFeXsMsXml -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLXmlSignClass usando a Lib MSXML -- ACBrDFeXsMsXmlCapicom -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLXmlSignMsXml usando a Lib MSXML e CAPICOM -- ACBrDFeException -- [+] Adicionado o exception "EACBrDFeExceptionNoPrivateKey" -- ACBrDFeUtil -- [+] Adicionado o método "SignatureElement: String" (por DSA) Obrigado... e considere nos ajudar, contratando o SAC, por pelo menos 1 mês http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/ Fique atento.... Em breve, organizaremos um Webinar sobre essas modificações

Boa tarde fiz todas alterações mencionadas no tópico, 1 = Todo o fonte atualizado 2 = De {.$DEFINE USE_MINGW} para {$DEFINE USE_MINGW} 3 = Reinstalar 4 = Atualizei as dll da pasta ACBr\DLLs\XMLSec\MinGW\32 - Para o System32, SysWOW64 e pasta da minha aplicação 5 = Configuração do componente AcbrNfce.SSL.SSLType := LT_TLSv1_2; AcbrNfce.Configuracoes.Geral.ModeloDF := moNFCe AcbrNfce.Configuracoes.Geral.VersaoDF := ve400 AcbrNfce.Configuracoes.Geral.SSLLib := libOpenSSL; AcbrNfce.Configuracoes.Geral.SSLCryptLib := cryOpenSSL; AcbrNfce.Configuracoes.Geral.SSLHttpLib := httpOpenSSL; AcbrNfce.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec; E o problema persiste; - Inativo ou Inoperante tente novamente. Erro Interno: 10091 Erro HTTP: 500. Porem quando utilizo libWinCrypt funciona tudo perfeitamente AcbrNfce.Configuracoes.Geral.SSLLib := libWinCrypt; Alguém já passou ou esta passando; Att;

Boa Tarde! A OpenSSL passou a dar suporte ao Certificados A3 ou ainda é somente A1 ?

Porque a minha aplicação, quando compilada no Trunk2 exige as DLLs do XMLSec ? O Trunk2, tem a habilidade de suportar OpenSSL (XMLSec) e CAPICOM, na mesma aplicação... e no ACBrNFe, existe a Classe TDFeSSL, que permite configurar qual será a biblioteca de SSL em Design ou Run-time Para isso, basta mudar a configuração usando comandos como abaixo: ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap; // Mesmo que "libCapicom", mas usando a Indy Porém, para efetuar essa "magica", precisamos compilar todas as Units que dão suporte a CAPICOM e OpenSSL\XMLSec, e elas injetam a dependência de DLLs externas Porque eu usaria o suporte a OpenSSL ? O OpenSSL é ótimo para certificados do tipo A1... pois você não precisa instalar o certificado no Windows... basta apontar o caminho do arquivo PFX e a Senha: ACBrNFe1.Configuracoes.Certificados.ArquivoPFX := edtCaminho.Text; ACBrNFe1.Configuracoes.Certificados.Senha := edtSenha.Text; Porque remover o suporte a uma das bibliotecas de SSL ? A desvantagem, é que a sua aplicação agora ficou dependente de mais DLLs, e para alguns pode ser um problema, distribuir e instalar as mesmas Onde eu encontro as DLLs ? \ACBr\DLLs\OpenSSL \ACBr\DLLs\XMLSec Para onde eu copio essas DLLs ? Você deve copiar TODAS as DLLs das pastas acima indicadas (e não apenas algumas). Você pode copiar para a mesma pasta da sua aplicação .EXE ou para o "System" do Windows Observe que, essas DLLs são 32 bits, e portanto só funcionarão para aplicações compiladas com um compilador 32 bits (que é o padrão para Delphi e Lazarus)... Uma aplicação 32 bits roda em um S.O. 64 bits, mas o oposto não ocorre... Considerando que essa DLLs são 32 bits, então: Se o seu Windows for 32 bits, copie para a pasta: C:\Windows\System32 Se o seu Windows for 64 bits, copie para a pasta: C:\Windows\SysWOW64 Se você estiver instalando DLLs de 64 bits em um Windows 64 bits, então a pasta correta é: C:\Windows\System32 (vai entender... pergunte pra Microsoft) Como eu removo a dependência ? Nunca usou o OpenSSL ? Nunca deseja usar ? Então você pode remover o suporte do ACBr ao OpenSSL/XMLSec, e com isso, remover a dependência de sua aplicação das DLLs do XMLSec.. Edite o ACBr.inc... Observe que no inicio do mesmo, existem as linhas abaixo: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_CAPICOM} Apenas remova o ".", se quiser ativar a remoção... {$DEFINE DFE_SEM_OPENSSL} Por que mesmo assim, a sua aplicação fica dependente das DLLs do OpenSSL (libeay32.dll, ssleay32.dll) ? O ACBr usa o OpenSSL para várias outras tarefas, como: criptografia e assinatura (ACBrEAD), comunicação segura (ACBrMail, ACBrHttp)... e outras... Então hoje, elas sempre serão necessárias... essa dependência já existia no "Trunk1"

Olá pessoal, Acabei de enviar para o SVN, modificações para que o ACBrDFe e ACBrDFeOpenSSL suportem comunicação segura usando TLS 1.2 O componente ACBrNFe, já irá tentar ajustar a comunicação para TLS 1.2, se detectar que a versão é superior a 3.1 Atualizando o OpenSSL Para usar TLS 1.2, é necessário ter a versão do OpenSSL superior a 1.0.1, normalmente a versão usada é a 0.9.8.14, e portanto ela precisa ser substituída. Se você tentar utilizar uma versão inferior, o ACBrDFeOpenSSL acusará o seguinte erro: Porém não basta apenas baixar e copiar uma nova versão das DLLs do OpenSSL (libeay32.dll e ssleay32.dll). O problema, é que a libxmlsec, que se encontra na pasta: "ACBr\DLLs\XMLSec", não é compatível com OpenSSL superior a 0.9.8... e se você simplesmente atualizar as Libs do OpenSSL no seu sistema, provavelmente o ACBrNFe, passará a acusar Exceptions no momento de assinar o XML A solução, é utilizar um novo conjunto de DLLs, da OpenSSL e libXmlSec, libXML, e demais... você pode achar essas DLLs em: ftp://ftp.zlatkovic.com/libxml/ Essas DLLs foram compiladas com "MinGW", e portanto elas precisarão das DLLs de RunTime, da MinGW. Para sua conveniência, copiamos todas as DLLs necessárias para a pasta: \ACBr\\DLLs\XMLSec\MinGW. Observe que temos a versão 32 e 64 bits dessas DLLs... quais eu devo usar ? Em resumo, use 32 se o seu Compilador é 32 bits, e 64 apenas se você estiver usando um Compilador que gere .EXE em 64 bits... Leia esse tópico, para compreender melhor: Copie TODAS as DLLs (e não somente algumas) da pasta "\ACBr\DLLs\XMLSec\MinGW\32" ou "\ACBr\trunk2\DLLs\XMLSec\MinGW\64" (conforme o seu compilador), para o seu diretório de DLLs... (se não tem certeza para onde você deve copiar as DLLS, leia com atenção o Post indicado anteriormente) Outro problema, é que a MinGW, gera as DLLs com uma nomenclatura ligeiramente diferente do VisualC, exemplo: libxmlsec1.dll com MinGW, e "libxmlsec.dll" com VisualC. Portanto, o ACBr teria dificuldades em encontrar essas DLLs e carrega-las de forma dinâmica. Precisamos portanto, informar ao ACBr, que usaremos o conjunto de DLLs no formato da MinGW... Isso é feito, editando o arquivo: ACBr.inc. Repare que lá no final do ACBr.inc, temos a seguinte linha: {.$DEFINE USE_MINGW} Apenas remova o ".", alterando para: {$DEFINE USE_MINGW} Pronto... com isso você estará pronto para usar o ACBr com OpenSSL e TLS 1.2, seja em 32 ou 64 bits... Obrigado... e considere nos ajudar, contratando o SAC ocasionalmente: http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/

Senhores, boa tarde. Estamos migrando alguns sistemas que utilizam o componente ACBrNFe de 32 para 64 bits, utilizando o Delphi 10.2. Pois bem, estou utilizando uma versão do ACBr baixada do repositório hoje (26/04/2018). O componente está configurado da seguinte maneira: o arquivo ACBr.inc está configurado da seguinte maneira: Quando efetuo a compilação para 64bits o meu sistema acusa o seguinte erro (Ao que me parece, não estão sendo carregadas as DLL's do OpenSSL): Quando efetuo a compilação em 32bits, a compilação transcorre sem nenhum problema, sendo efetuada a transmissão normalmente. Alguem pode me dar alguma dica com relação à isso? Obs: já li todo o conteúdo relacionado nos tópicos abaixo e não consegui resolver o meu problema:

Bom dia, Ao tentar enviar uma NFS-e para a prefeitura de Goiânia, no momento de assinar o documento, está ocorrendo um erro no método function "TDFeSSLXmlSignXmlSec.XmlSecSign(const ConteudoXML: AnsiString; SignatureNode, SelectionNamespaces, InfElement: AnsiString): AnsiString" , no seguinte trecho de código: SignResult := xmlSecDSigCtxSign(FdsigCtx, SignNode); if (SignResult < 0) then begin xmlsecMsg := xmlSecErrorsGetMsg(2); raise EACBrDFeException.CreateFmt(cErrDSigSign + sLineBreak + xmlsecMsg, [SignResult]); end; A mensagem é "Erro -1: Falha ao assinar o Documento strdup function failed" Consigo carregar as informações do cerficado normalmente no método SSL.CarregarCertificado

Boa tarde, Na tentativa de adicionar notas ao lote, usando o comando NFe.AdicionarNfe, obtenho no retorno o erro acima. Estou usando a versão 1.1.0.33 do monitor. Alguma sugestão de configuração do SSL na aba certificados? De modo a evitar essas ocorrências? Obrigado.

Ao consultar o manual do monitor plus constatei que o comando NFE.CertificadoDataVencimento funciona apenas para a versão capicom. Como vou fazer para checar a data do vencimento do certificado se não estou usando a CAPICOM?

Bom dia. Estou tendo problemas com alguns clientes depois da última atualização referente à comunicação com os certificados digitais. Gostaria de saber como ajustar as propriedades para que os componentes trabalhem da mesma forma utilizada anteriormente ao refactoring. Reparei que o valor defaul para as propriedades é 'none': constructor TGeralConf.Create(AConfiguracoes: TConfiguracoes); begin ... FSSLLib := libNone; FSSLCryptLib := cryNone; FSSLHttpLib := httpNone; ... end; Dependendo do sistema operacional do cliente, estão sendo apresentados os seguintes erros: Método "Enviar" não implementado em: TDFeSSLHttpClass; Parâmetro incorreto; Falha em obter Provedor de Cripotografia do Certificado. Erro: 80090016. Como proceder? Obrigado.

Bom dia Galera. Estou no processo de troca de CAPICOM para OPENSSL acompanhei o topico do Daniel Simoes para fazer a migração Fiz em alguns sistemas aqui e funcionou sem problemas. Porem ontem fiquei o dia todo com um projeto do cliente e não consegui resolver tive que voltar uma versão do sistema para que o cliente conseguisse continuar com a emissão. O erro que apresenta segue em anexo. Aqui em maquina de teste esta funcionando certinho, erro apenas em produção. Certificado do cliente A1 NO projeto a unica alteração que fiz foi essa: NFE.Configuracoes.Geral.SSLLib := libWinCrypt; Eu passo o certificado através no numero de serie, o certificado esta instalado na maquina e funcionando. NFE.Configuracoes.Certificados.NumeroSerie := UpperCase(CertificadoDigital); (Ja alterei pra tentar passar o caminho do PFX e senha mais deu o mesmo erro) A versão estou usando NFE.Configuracoes.Geral.VersaoDF := ve310 .. Ja alterei pra NFE.Configuracoes.Geral.VersaoDF := ve400 e deu mesmo erro ... Compilei o demo .. e tambem com problema... testei em 2 computadores do cliente e mesmo problema ... não sei mais o que fazer.... Help-me .. uhahuuah

Bom dia Pessoal Bom, com a chegada do Trunk2, ocorreu a obrigatoriedade de enviar junto com o EXE as lib necessárias para o OpenSSL. Eu só utilizo CAPICOM.DLL Analisando o Install Packages do Delphi 7, pergunto? Se eu desligar esse componente "Acbr - OpenSSL através do LibXMLSec" vai trazer algum problema para os demais componentes ? Obrigado

Bom dia, senhores Estou recebendo a mensagem de erro "[Error] ACBrDFeOpenSSL.pas (146): Undeclared identifier 'Init' " quando tento compilar um projeto legado no qual estou trabalhando. É a primeira vez que utilizo componentes ACBr então posso estar perguntando algo extremamente básico, e desde já peço desculpas se esse for o caso, mas realmente estou há pelo menos três dias pesquisando, inclusive aqui no fórum e tentando alternativas para solucionar o problema, mas sem nenhum sucesso. Estou trabalhando com Delphi 7 e componentes ACBr Trunk 2 e já fiz a limpeza dos componentes e reinstalação várias vezes. A linha mencionada no erro de compilação traz o comando "libxml2.Init;" em uma referência à unit libxml2.pas, que declara vários métodos contidos na DLL libxml2.dll. No meu entendimento, a unit está tentando inicializar o acesso à DLL libxml2.dll, mas por algum motivo não está reconhecendo o método Init. Alguém sabe o que poderia estar acontecendo nesse caso e como resolver essa situação? Caso precisem de maiores detalhes estou à disposição! Grato pela atenção de todos!

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