Data de Validade do Certificado já expirou: 30/12/1899

[KriarTecnologia]

Bom dia Daniel, primeiramente obrigado pela atenção. Resolvemos nosso problema copiando o componente acbrnfe de um projeto antigo que vem desde o delphi 7 e já está no seattle para esse em questão, nossas dlls capicom e openssl que estão instaladas no windows 10 são desde 2016.

O que pode ser?

Editado 17 Maio, 2018 por KriarTecnologia

[Daniel Simoes]

Desculpe mas não compreendi o seu tópico... O problema foi ou não resolvido ?

Se SIM, provavelmente você esqueceu de configurar alguma das propriedades (no projeto novo) que o componente do outro projeto tinha...

[KriarTecnologia]

O problema foi resolvido quando gero em .exe faço a requisição via browser e funciona ok.

 

 

mas quando gero em isapi .dll continua o mesmo problema quando faço a requisição em rede local.

 

o código responsável pela função consultanfe que dá o retorno mostrado na tela (imagem acima) segue abaixo:

 

function TServerMethods1.consultaNFe(nfe:string): string;
begin

  ACBrNFe1.NotasFiscais.Clear;
  ACBrNFe1.NotasFiscais.LoadFromFile(trim('c:\nfe\' + nfe + '-nfe.xml'));

 with acbrnfe1.EventoNFe.Gerador.Opcoes do
  begin
    IdentarXML := False;                                                   // Os arquivos que serão enviados para o SEFAZ não devem estar identados
    TamanhoIdentacao := 3;                                                 // Tamanho da identação do arquivo
    FormatoAlerta := 'TAG:%TAGNIVEL% ID:%ID%/%TAG%(%DESCRICAO%) - %MSG%.'; // Formato em que a mensagem vai ser gravada a ListaDeAlertas
    RetirarEspacos := True;                                                // Retira os espaços em branco duplos nas tag do xml
    SuprimirDecimais := true;                                             // Ignora valores não significativos nas casa decimais
    SomenteValidar := False;                                               // Não gera o arquivo apenas valida as informações
  end;
//    Seta Versão a ser utilizada em execução
 with acbrnfe1.Configuracoes do
   begin
    Geral.ModeloDF := moNFe;
    Geral.VersaoDF := ve400;
    //ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom;
    //ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL;
    //ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt;
    ACBrNFe1.Configuracoes.WebServices.UF := 'mg';

    //Geral.idCSC    := '000001';
    //Geral.CSC      := frmlogon.qryLojas_csc.AsString; //'39d58c8a-9ce8-43dc-83b7-1ea1fc3123f2';

    Certificados.NumeroSerie := '61A48A4D9E135BBB57F83B976ECB71E7'; //NFe_CertDigitalSenha;
    Certificados.Senha       := '123456';  //NFe_CertDigitalSerie;
    Certificados.ArquivoPFX  := 'c:\nfe\tmc.pfx';

    Geral.FormaEmissao := teNormal;
    Geral.Salvar       := True;

//    ACBrCTe1.Configuracoes.arquivos.PathSalvar   := edtPathLogs.Text;

    Geral.Salvar        := True;
    arquivos.PathSalvar := 'c:\nfe';
    WebServices.Visualizar := True;
    WebServices.Ambiente := taProducao;

   end;

  try
    ACBrNFe1.Consultar;
  except

    on E : Exception do
    begin
      result := 'ERRO AO CONSULTAR A NFE NA SEFAZ ' +
                E.ClassName+' error raised, with message : '+E.Message;
      exit;
    end;

  end;

  //qryCupom_capa_contingencia.Value := false;
  result :=
  '                   ***** Envio e Solicitação de Consulta    *****     ' +
  UTF8Encode(ACBrNFe1.WebServices.Consulta.RetWS)     +
  '                   ***** Retorno da Solicitação de Consulta *****     ' +
  UTF8Encode(ACBrNFe1.WebServices.Consulta.RetornoWS) +
  '                   ***************************************************';

end;

 

[KriarTecnologia]

Desculpe Daniel, o erro agora mudou: (quando gera isapi .dll)

{"result":["ERRO AO CONSULTAR A NFE NA SEFAZ EACBrDFeException error raised, with message : \r\nPFXDataToCertContextWinApi: Falha em \"PFXImportCertStore\" Erro: 80090020"]}

Editado 17 Maio, 2018 por KriarTecnologia

[KriarTecnologia]

Bom dia! Problema resolvido, foi apenas setar o sslib (ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL;):

    //ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom;
    ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL;
    //ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt;

[Daniel Simoes]

O Windows realmente tem problemas para acessar certificados que foram instalados na pasta pessoal, quando a aplicação está rodando em modo Serviço...

Usar OPENSSL contorna esse problema 

[Gr@c@]

2 horas atrás, Daniel Simoes disse:

O Windows realmente tem problemas para acessar certificados que foram instalados na pasta pessoal, quando a aplicação está rodando em modo Serviço...

Usar OPENSSL contorna esse problema 

Daniel este problema está ocorrendo em um cliente que está com a versao da NFe 4.00 usando wincrypt. Windows 7 32 bits sp1. Muitas vezes não reconhece o certificado (A1 Certinsign) que está instalado na máquina. Tem alguma sugestão?

[Daniel Simoes]

Se você já usa A1.. então mude para OpenSSL e esqueça de problemas com a instalação de Certificados no Windows

[fba fabio]

Este problema aparentemente tem relação com a versão do OpenSSL (estou usando OpenSSL 1.1.0i-fips 14 Aug 2018), acredito que o método da lib openssl que retorna a data de validade do certificado foi modificado e esta retornando nil, uma solução temporária que encontrei para bypass o problema foi o seguinte:

Alterar o método ./Fontes/ACBrDFe/ACBrDFeOpenSSL.pas linha 136
 

function GetNotAfter( cert: pX509 ): TDateTime;
var
  Validade: String;
  notAfter: PASN1_TIME;
begin

//  *** remover as linhas comentadas abaixo: ***
//  notAfter := cert^.cert_info^.validity^.notAfter;
//  Validade := {$IFDEF DELPHIXE4_UP}AnsiStrings.{$ENDIF}StrPas( PAnsiChar(notAfter^.data) );
//  SetLength(Validade, notAfter^.length);
//  Validade := OnlyNumber(Validade);
//  if notAfter^.asn1_type = V_ASN1_UTCTIME then  // anos com 2 dígitos
//  Validade :=  LeftStr(IntToStrZero(YearOf(Now),4),2) + Validade;
//  Result := StoD(Validade);}
//  *** adicionar apenas o Result abaixo que equivale retornar como data de validade a data 22/02/2022 ***
      Result := StoD('20220222000000');
end; 

Após a alteração abrir ./Pacotes/Lazarus/ACBrDFe/ACBrDFeComum.lpk e compilar novamente

[Daniel Simoes]

Realmente o ACBrOpenSSL (ainda) não é compatível com a séria 1.1 do OpenSSL...

Não é possível usar/instalar uma versão da Série 1.0, do OpenSSL ?

[fba fabio]

12 horas atrás, Daniel Simoes disse:

Realmente o ACBrOpenSSL (ainda) não é compatível com a séria 1.1 do OpenSSL...

Não é possível usar/instalar uma versão da Série 1.0, do OpenSSL ?

O único problema relacionado ao OpenSSL até o momento foi no método GetNotAfter

Estou usando o ACBrMonitor PLUS para emissão de NFE rodando no Ubuntu 18.04

Compilado com Lazarus 1.8.0 2018-03-17 FPC 3.0.2 no Fedora

[Daniel Simoes]

Acho que existe alguma incompatibilidade, também na rotina de Criptografia...

Você está usando libXMLSec ou LibXML2 para assinar o XML ?

[fba fabio]

15 horas atrás, Daniel Simoes disse:

Acho que existe alguma incompatibilidade, também na rotina de Criptografia...

Você está usando libXMLSec ou LibXML2 para assinar o XML ?

No Ubuntu após vários testes o que funcionou foi baixar e compilando diretamente do repositório o xmlsec1, no Fedora bastou instalar os pacotes diretamente dos repositórios e criar um link simbólico pois ao realizar o build do Lazarus ele não estava encontrando a lib xmlsec1, abaixo segue o passo a passo que utilizei baseado nas dicas do vídeo https://www.youtube.com/watch?v=wU8KRNMwUaw

#UBUNTU 18.04
apt install libxml2-dev
apt install libltdl-dev
apt install libssl-dev
wget http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.27.tar.gz
tar -zxvf xmlsec1-1.2.27.tar.gz
cd xmlsec1-1.2.27
./configure
make
make install

#FEDORA 27/28
yum install libxml2-devel
yum install libxslt-devel
yum install libtool-ltdl-devel
yum install openssl-devel
yum install xmlsec1
ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1.so

 

Editado 7 Fevereiro, 2019 por fba fabio

[Daniel Simoes]

Por isso que você não teve problemas na Assinatura... (o Hash está sendo calculado pela XMLSec)...

Hoje em dia, o ACBr usa rotinas próprias, para computar a Assinatura digital dos XMLs... isso é bom, pois remove a dependência da XMLSec... Nossas rotinas de calculo de Hash e Sign Digest, estão em: ACBrDFeOpenSSL.pas... e elas são usadas, quando a biblioteca de Assinatura do XML é configurada como xsLibXml2, creio que nesse cenário... você terá novos problemas, com o OpenSSL 1.1

[fba fabio]

6 horas atrás, Daniel Simoes disse:

Por isso que você não teve problemas na Assinatura... (o Hash está sendo calculado pela XMLSec)...

Hoje em dia, o ACBr usa rotinas próprias, para computar a Assinatura digital dos XMLs... isso é bom, pois remove a dependência da XMLSec... Nossas rotinas de calculo de Hash e Sign Digest, estão em: ACBrDFeOpenSSL.pas... e elas são usadas, quando a biblioteca de Assinatura do XML é configurada como xsLibXml2, creio que nesse cenário... você terá novos problemas, com o OpenSSL 1.1

Ola, você tem razão, ao usar xsLibXml2 quando tenta gerar a NFe ocorre 'ERRO: Access violation', usando a configuração conforme imagem anexa tudo funciona normalmente

Vou dar uma olhada no código em relação ao uso da xsLibXml2, as vezes com alguns ajustes seja possível rodar no Linux com a Openssl 1.1

[Daniel Simoes]

Parece que mudou a assinatura de alguns métodos que usamos... na versão 1.1

Teríamos que rever toda a Unit de "Bind"... a gigantesca "OpenSSLExt"  (uma versão estendida da Unit OpenSSL, do FPC)

[fba fabio]

2 horas atrás, Daniel Simoes disse:

Parece que mudou a assinatura de alguns métodos que usamos... na versão 1.1

Teríamos que rever toda a Unit de "Bind"... a gigantesca "OpenSSLExt"  (uma versão estendida da Unit OpenSSL, do FPC)

Fiz alguns testes (Fedora 28) e as libs estão dispostas da seguinte forma:

ls -sal /usr/lib64/libssl*
/usr/lib64/libssl3.so
/usr/lib64/libssl.so -> libssl.so.1.1.0i
/usr/lib64/libssl.so.10 -> libssl.so.1.0.2o
/usr/lib64/libssl.so.1.0.2o
/usr/lib64/libssl.so.1.1 -> libssl.so.1.1.0i
/usr/lib64/libssl.so.1.1.0i

ls -sal /usr/lib64/libcrypto*
/usr/lib64/libcrypto.so -> libcrypto.so.1.1.0i
/usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.2o
/usr/lib64/libcrypto.so.1.0.2o
/usr/lib64/libcrypto.so.1.1 -> libcrypto.so.1.1.0i
/usr/lib64/libcrypto.so.1.1.0i

A função LoadLibHack que é responsável por encontrar as libs, procura primeiro pela lib sem versão nenhuma, então bastou ajustar para que ele procure primeiro pelo '.10' para que fosse realizado o carregamento da lib correta

OpenSSLExt
DE: 
DLLVersions: array[1..16] of string = ('', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3',
                                        '.1.0.2', '.1.0.1','.1.0.0','.0.9.8',
                                        '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4',
                                        '.0.9.3', '.0.9.2', '.0.9.1');           
PARA: 
DLLVersions: array[1..17] of string = ('.10','', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3',
                                        '.1.0.2', '.1.0.1','.1.0.0','.0.9.8',
                                        '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4',
                                        '.0.9.3', '.0.9.2', '.0.9.1');           

Usando a lib da série 1.0 a assinatura ocorreu corretamente tanto usando xsLibXml2 como xsXmlSec e a conexão com o webservice também funcionou normalmente

 

Fiz alguns testes em C com as duas versões da lib série 1.0.2 e 1.1.0 para o método EVP_DigestInit, que é onde esta ocorrendo o erro usando a versão 1.1 da lib ao tentar assinar usando xsLibXml2. Foi preciso fazer várias pequenas modificações no código em C para funcionar na versão nova.

 

Atualmente estou usando a versão 1.1 da lib OpenSSL para emissão de NFe e esta rodando corretamente, as exceções ficam por conta da xsLibXml2 que pode ser substituída pela xsXmlSec e o bug do tópico em questão no método GetNotAfter, verificando no site https://www.openssl.org/source/ o suporte a versão da série 1.0.2 (LTS) terminará em 31/12/2019 e eles recomendam que todos migrem para a próxima versão LTS 1.1.1 que tem suporte até setembro de 2023

[Daniel Simoes]

Ajustar os links simbólicos para que ele se ligue a 1.0.2, não resolveria ?

Acho que apenas '.10', pode ser muito genérico... ele pode se confundir com outras versões, no futuro...