Pesquisar na Comunidade

Contextualizando. As configurações de SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType são comuns a todos as soluções de Documentos Fiscais Eletrônicos do ACBr. Aqui vamos considerar os exemplos nativos, mas essas configurações também se aplicam ao ACBrMonitorPLUS e ACBrLib. As configurações SSLLib, CryptLib, HttpLib e XMLSignLib costumam ficar na aba Certificado dos programas exemplo e podem ser definidas via código da seguinte maneira: ComponenteDFe.Configuracoes.Geral.SSLLib := libOpenSSL ou libWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.CryptLib := cryOpenSSL ou cryWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLHttpLib := httpOpenSSL ou httpWinHttp;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Se o certificado digital for A3 só vai ser possível usar as configurações do WinCrypt, por outro lado se for A1 poderá usar o WinCrypt ou OpenSSL. Recomendamos fortemente que o certificado seja A1. Desta forma podemos usar o OpenSSL e não precisamos nos preocupar com a versão Windows e suas atualizações. Além disso, o certificado não precisa ser instalado, pode ser lido de uma pasta onde esta salvo ou de um campo do banco de dados. Essas configurações influenciam comportamentos como protocolo de comunicação, assinatura, validação de schema, entre outros. Já a configuração SSLType costuma ficar na aba WebService dos programas exemplos e pode ser definida via fonte assim: ComponenteDFe.SSL.SSLType := LT_TLSv1_2; Como o nome sugere, essa configuração influencia se vai qual protocolo TLS ou SSL será usado na comunicação. Porque você está atrasado. Além de não suportar 64 bits, a Microsoft condenou a CAPICOM como obsoleta desde 2016. Então, se você ainda usa configuração de Capicom está usando algo defasado, aberto a erros e com brechas de segurança. A MsXML foi descontinuada pela Microsoft em 2014 e atualmente é considerada obsoleta. Usar essa configuração para assinatura ou validação significa usar algo ultrapassado, que não sofre manutenção e com maior propensão a erros. Se você vai usar certificado A3, não deve em hipótese alguma usar MsXML, sob risco de inutilizar a chave privada do certificado digital. Praticamente todos os DFes atuais estabeleceram que deve ser usado TLS1.2 na comunicação. Por isso, foi atualizado nos fontes para que os DFes usem como padrão TLS1.2 ao invés de LT_all. Se você mesmo assim ainda usa essa configuração, o componente vai usar o primeiro protocolo disponível e não o mais indicado. O que eu uso então? As configurações recomendadas por tipo de certificado podem ser encontradas neste tópico: Caso prefira, também pode acompanhar este vídeo com orientações e demonstração prática: Mais informações. Veja mais detalhes sobre como o ACBr deu Bye Bye para a Capicom neste tópico: No tópico abaixo foi relatado o problema com MsXML e perda da chave privada de certificados A3:

Bom dia, pessoal! Atualizei o ACBr ontem e estou tendo problema ao tentar carregar um arquivo de certificado digital A1, tendo como resposta a mensagem "Parâmetro incorreto". Segue abaixo trecho do meu código de como funcionava antes e em anexo um PDF com detalhes do debug. ACBrNFe.Configuracoes.Certificados.ArquivoPFX := ArquivoPFXLocal; ACBrNFe.Configuracoes.Certificados.Senha := DM.DtsParametrosSENHA_CERTIFICADO.AsString; ACBrNFe.SSL.CarregarCertificado; Debug.pdf

Boa tarde! Vi em alguns tópicos antigos que é possível informar previamente a senha do certificado A3 no sistema para não ficar pedindo ao enviar uma NFe, NFCe, estou informando o seguinte código ao configurar o componente: ACBrNFCe.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFCe.Configuracoes.Certificados.NumeroSerie := TheIni.ReadString('Certificado_' + Q_Empresa.FieldByName('CPF_CNPJ').AsString, 'NumSerie', ''); ACBrNFCe.Configuracoes.Certificados.Senha := TheIni.ReadString('Certificado_' + Q_Empresa.FieldByName('CPF_CNPJ').AsString, 'Senha', ''); Existe mais alguma configuração que preciso efetuar? Obrigado!

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?

Galera Ainda uso CAPICOM e tive necessidade de saber se o CERTIFICADO estava carregado antes de começar a operação. Encontrei no forum solução para WINCRYPT Abaixo a solução que achei pesquisando o fonte de ACBrCAPICOM_TLB NFSE.SSL.CarregarCertificado; if (NFSE.SSL.SSLCryptClass is TDFeCapicom) and (TDFeCapicom(NFSE.SSL.SSLCryptClass).Certificado.Get_PrivateKey.IsAccessible) then begin mmo_status.Text := mmo_status.Text + 'INFORMAÇÕES CERTIFICADO' +cr+ 'CertSubjectName : ' + NFSE.SSL.CertSubjectName+cr+ 'Razão Social : ' + NFSE.SSL.CertRazaoSocial+cr+ 'CNPJ : ' + NFSE.SSL.CertCNPJ+cr+ 'Numero Serie : ' + NFSE.SSL.CertNumeroSerie+cr+ 'Data Vcto : ' + FormatDateTime('DD/MM/YYYY', NFSE.SSL.CertDataVenc)+cr+ 'Certificado Tipo: ' + tipo_cert+cr; if TDFeCapicom(NFSE.SSL.SSLCryptClass).Certificado.Get_PrivateKey.IsHardwareDevice then mmo_status.Text := mmo_status.Text + 'IsHardwareDevice: TRUE' +cr; mmo_status.Text := mmo_status.Text + '++++++++++++++++++++++++++++++++++++'+cr+ '+++ CERTICADO LIDO COM SUCESSO +++'+CR+ '++++++++++++++++++++++++++++++++++++'; end else mmo_status.Text := mmo_status.Text + '+++++++++++++++++++++++++++++++++++++++++'+cr+ '+++ ERRO CERTIFICADO INACESSÍVEL ERRO +++'+CR+ '+++++++++++++++++++++++++++++++++++++++++'; mmo_status.Lines.SaveToFile( sPathExe+'log.txt');

Pessoal, Todos os fontes estão atualizados e foram instalados ontem. A empresa é nova e é a primeira NFSe via lote (RPS n. 1). Já emito com o sistema de outras empresas sem problemas. Uso Capicom, certificado A1 Erro: Alguém passou por isso ao enviar o 1.o RPS?

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

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"

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:

Olá, Estou com uma duvida, e não encontrei algo referente a isto no fórum, se caso passei despercebido ou não estou no lugar correto, desculpe desde já. Na versão 4.0 agora será utilizado TSL1.2, e também o Capicom foi retirado, agora não é mais necessário o mesmo para trabalhar dentro da ACBR. Mas existe algum problema de eu continuar usando ele? Existe algum prazo para remoção completa dele ? ou eu posso estar optando por utilizar ele ou não. Tenho alguns clientes com windows desatualizados, que não é bem uma opção efetuar a atualização das maquinas, e com o CAPICOM funciona normalmente, porém se eu usar tsl1.2, e suas devidas configurações, não consigo conexão, pois o windows não está atualizado. Apenas uma duvida se realmente tem um prazo para exclusão completa do CAPICOM ou eu posso continuar utilizando ele em alguns casos. Obrigado desde já, fico grato pela ajuda.

Bom dia! Estou com um problema relacionado ao método fACBrNFe.WebServices.StatusServico.Executar e na inutilização de faixas fACBrNFe.WebServices.Inutiliza(...). Realizando uns testes em homologação, pude perceber que esses dois procedimentos executa a primeira vez com sucesso, porém as próximas chamadas apresenta o erro abaixo Então se eu finalizar a aplicação e reabrir, qualquer um dos métodos de inutilização ou verificar serviço volta a funcionar, porém, apenas a primeira chamada em seguida irá da erro em qualquer procedimento que se venha solicitar à classe TACBrNFe. Depurei o projeto, fiz várias alterações em configurações avançadas do IE no painel de controle e não consegui desvendar o mistério, além de destruir o objeto e instanciá-lo após cada chamada, nenhuma sem êxito. Não entendo o motivo, parece que algo do S.O fica bloqueando as próx. requisições do aplicativo, desativei firewall, etc td.. Em fACBrNFe.Configuracoes.Geral.SSLLib tenho atribuído libCapicom, atualizei cadeia de certificados, etc. Já vi diversos tópicos falando a cerca do problema, mas realizando essas conf. no IE resolve para os outros métodos de envio de nota, cancelamento, etc, mas esses dois em específico não... Mais alguém já percebeu isto? Ou alguma solução para o caso?

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.

Boa Tarde, Preciso registar a Capicom.dll para utilizar em uma aplicação x64. Testei copiar as dll's necessárias para a pasta SysWOW64 e executar o comando "regsvr32", porem quando abro a aplicação em x64 e utilizo a função: 'class function CoStore.Create: IStore3; begin Result := CreateComObject(CLASS_Store) as IStore3; end;' me retorna a mensagem de Classe não Registrada. Por favor, preciso de uma ajuda para solucionar esse problema.

Boa tarde! Ao colocar minha aplicação no ambiente Windows 7/2008, percebi que em algumas chamadas realizadas pelo componente ACBRMDFe, programa trava ou é fechado "do nada" sem informar mensagem de erro ou algo do gênero, mesmo usando try/exception (Delphi XE). Percebi que esse evento ocorre ao invocar as funções de Envio/Consulta/Encerramento do XML, não sempre mas uma vez ou outra. Alguém já passou por isso e conseguiu resolver? É relacionado a DLL Capicom, e para evitar tal possível conflito, devo atualizar a mesma? Att, João.

boa tarde utilizando o AcbrMonitor Plus 0.3.08.1 funciona normal.....ai fizemos atualização acbrmonitor plus 1.1.0.8 porem com o mesmo não estamos conseguindo emitir as NF-e/DANFE.....não sei se configurei alguma coisa errado na aba certificado com essa mudança se preciso mudar alguma coisa nas configurações avançadas do internet explorer ou pode ser algum bloqueio do meu SQUID já que não me retorna nenhum erro, testei a mesma configuração utilizando uma outra conexão sem bloqueio e funcionou, se for algo referente ao squid alguém sabe me dizer as portas/endereço que devo liberar............obrigado entnfe.txt

boa tarde utilizando o AcbrMonitor Plus 0.3.08.1 funciona normal.....ai fizemos atualização acbrmonitor plus 1.1.0.8 porem com o mesmo não estamos conseguindo emitir as NF-e/DANFE.....não sei se configurei alguma coisa errado na aba certificado com essa mudança se preciso mudar alguma coisa nas configurações avançadas do internet explorer ou pode ser algum bloqueio do meu SQUID já que não me retorna nenhum erro, testei a mesma configuração utilizando uma outra conexão sem bloqueio e funcionou, se for algo referente ao squid alguém sabe me dizer as portas/endereço que devo liberar............obrigado entnfe.txt

Boa tarde pessoal, estou tentando compilar minha aplicação em x64 mas me retorna um erro em uma função que não dá erro no x86: CertContext.Get_CertContext(Integer(PCertContext)); dá esse erro: [dcc64 Error] uWebServiceClass.pas(153): E2197 Constant object cannot be passed as var parameter como posso resolver? Se alguém quiser saber o contexto do uso, é esse: procedure TWebService.OnBeforePost(const HTTPReqResp: THTTPReqResp; Data: Pointer); var Cert : ICertificate2; CertContext : ICertContext; PCertContext : Pointer; ContentHeader: string; begin Cert := GetCertificate(xCert); CertContext := Cert as ICertContext; CertContext.Get_CertContext(Integer(PCertContext)); //PESQUISA PARA 64BIT if not InternetSetOption(Data, 84, PCertContext,SizeOf(CERT_CONTEXT)) then begin //showmessage('Certificado não lido. Tente novamente!'); end; if (pos('SCERECEPCAORFB',UpperCase(HTTPReqResp.URL)) <= 0) and (pos('SCECONSULTARFB',UpperCase(HTTPReqResp.URL)) <= 0) then begin ContentHeader := Format(ContentTypeTemplate, ['application/soap+xml; charset=utf-8']); HttpAddRequestHeaders(Data, PChar(ContentHeader), Length(ContentHeader), HTTP_ADDREQ_FLAG_REPLACE); end; HTTPReqResp.CheckContentType; end;

U R G E N T E Após atualizar a ACBr via Tortoise, na compilação da aplicação deu o seguinte erro: [dcc32 Fatal Error] ACBrDFeXsMsXmlCapicom.pas(2062): F2063 Could not compile used unit 'ACBrDFeXsMsXml.pas' - como não salvei a versão anterior a atualização agora não consigo colocar uma nova versão no Cliente... Desde já agradeço

Fiz essa configuração somente: ACBrCTe1.Configuracoes.Geral.SSLLib := libWinCrypt; Não funcionou, ao enviar o CT-e retorna uma tela de erro vazia (sem mensagem de erro). Voltando para libCapicom o CT-e é enviado normalmente. Falta mais alguma configuração? O certificado é A1 e está instalado em um micro com Windows7 32 Professional original. Não informei caminho do pfx, nem senha como já fazia antes. Mas também tentar informar e o retorno foi vazio. A série e a data de validade do certificado (vence em 2018) aparecem corretamente.

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 a todos. Após atualizar a pasta no dia de ontem estou com problemas na função GetCNPJFromExtensions do .pas ACBrDFeCapicom e não estou conseguindo enviar NF-e gostaria de informações se ocorreu alguma alteração ou falha na ultima atualização. Agradeço a atenção de todos.

Olá, boa tarde pessoal... Estava tendo muitos problemas com o envio de DFe utilizando a CAPICOM (principalmente com certificados A3), necessidade de ficar instalando certificados da VALID com instalador próprio deles (para evitar o erro The Cryptographic Service Provider type '24) e PRINCIPALMENTE: Alguns certificados A3 não funciona NEM NA MARRETA com WS do Mato Grosso... Enfim, gostaria de disponibilizar e também contar com a ajuda de vocês para testar uma solução que fiz para não utilizar a CAPICOM nem OPENSSL... Como não encontrei nenhuma solução "boa" para o Delphi, acabei fazendo as rotinas de assinatura e envio para o WS dentro do C# e utilizando essas DLLs no Delphi... APENAS essas duas funções são utilizadas, todo o restante é tratada diretamente pelo ACBR no Delphi... Peço ajuda pois estou com "pouco" tempo para melhorar o código, e sei que será bem útil para muitos aqui... PS1: Estou usando ela em produção em alguns clientes, está se mostrando satisfatório até agora. PS2: Vou deixar aberto o código em C#, só preciso de um tempo para criar um repo no github e upar PS3: Não limpei nada no código (sem tempo), utilizei a mesma classe do ACBrDFeCapicom, então está com quase tudo da original. PS4: A DLL deverá ficar no diretório da aplicação. PS5: Foi feita utilizando .NET Framework 2.0 (único requisito para funcionar) PS6: A empresa gentilmente cedeu o código de fonte para que possa ser usado pelos demais programadores do ACBr. Modificações: - ACBrDFeSSL.pas: Adicionar a uses: uses strutils, synacode, ACBrDFeUtil, ACBrValidador, ACBrUtil, ACBrDFeException, ACBrDFeKinyx... Adicionar o novo tipo de biblioteca a ser utilizado: TSSLLib = (libNone, libOpenSSL, libCapicom, libCapicomDelphiSoap, libKinyx); Adicionar outra condição na função SetSSLib: procedure TDFeSSL.SetSSLLib(ASSLLib: TSSLLib); begin ... libKinyx: begin FSSLClass := TDFeKinyx.Create(Self); end .. end; ACBrDFeKinyx.pas KinyxDFeLib.dll

Olá, Gostaria de saber qual o método correto para verificar Assinaturas Digitais em arquivos XML. Meu sistema precisa receber e enviar arquivos XML assinados. Para os arquivos que o sistema recebe, é necessária a validação das assinaturas. Fiz um projeto para Assinar arquivos XML e enviar ao servidor. A assinatura está válida. Então peguei esse mesmo arquivo assinado e tentei utilizar o método VerificarAssinatura da classe TDFeSSL (utilizando CAPICOM) para ver se o componente validava a assinatura que ele mesmo fez... mas um erro ocorre: Assinatura inválida: Erro ao verificar assinatura do arquivo: Invalid Signature. Poderiam me ajudar?