ACBrNFe 4.0 - Erro ao executar status Serviço

[JJA]

Em 23/10/2017 at 10:12, BigWings disse:

As DLLs da MinGW são usadas quando você define SSLLib como OpenSSL, elas são necessárias para habilitar o acesso a webservices protegidas com TLS 1.2. Se você não vai usar OpenSSL, não precisa do MinGW.

Não.

MinGW é OpenSSL, não substitui a CAPICOM. A substituta do CAPICOM é a WinCrypt.

Ok,  entendido.

Então para ter o ACBr atendendo tanto certificados A1 quanto A3, o que devo instalar? O ACBr com WinCrypt para atender certificados A3 e o que mais para certificados A1?

[Juliomar Marchetti]

13 minutos atrás, JJA disse:

Ok,  entendido.

Então para ter o ACBr atendendo tanto certificados A1 quanto A3, o que devo instalar? O ACBr com WinCrypt para atender certificados A3 e o que mais para certificados A1?

WinCrypt atende A1 e A3

 

[BigWings]

21 minutos atrás, JJA disse:

Ok,  entendido.

Então para ter o ACBr atendendo tanto certificados A1 quanto A3, o que devo instalar? O ACBr com WinCrypt para atender certificados A3 e o que mais para certificados A1?

Já respondi lá atrás:

Citar

Para A1 é preferível o OpenSSL. Para A3 eu diria o WinCrypt que não depende das configurações do IE nem da CAPICOM.dll que já foi depreciada pela MS.

O Juliomar está correto em dizer que WinCrypt atende ambos, mas certificados A1 novos vem com encriptação de 2048 bits, o que WinCrypt e CAPICOM vão acusar o erro "The Cryptographic Service Provider type '24' is not supported.", sendo necessário fazer a conversão do certificado.

Esse problema não existe com OpenSSL.

[JJA]

1 minuto atrás, BigWings disse:

Sim, acabei de testar aqui, mudei para winCrypt e deu este erro '24'.

Meu componente estava confgurado para OpenSSL, não dava  este erro '24' e agora entendi o porque, como vocês falaram, é porque OpenSSL suporta 2048 bits nos certificados,  porém estou tendo problemas na hora de enviar a NFe, está me dando Access Violation na DLL libXMLSec.dll ao assinar a NFe. Começou a ocorrer este erro depois que atualizei o ACBr, meu executável antigo não dava este problema. O que pode ser?

 

Já respondi lá atrás:

O Juliomar está correto em dizer que WinCrypt atende ambos, mas certificados A1 novos vem com encriptação de 2048 bits, o que WinCrypt e CAPICOM vão acusar o erro "The Cryptographic Service Provider type '24' is not supported.", sendo necessário fazer a conversão do certificado.

Esse problema não existe com OpenSSL.

 

[BigWings]

19 minutos atrás, JJA disse:

Meu componente estava confgurado para OpenSSL, não dava  este erro '24' e agora entendi o porque, como vocês falaram, é porque OpenSSL suporta 2048 bits nos certificados,  porém estou tendo problemas na hora de enviar a NFe, está me dando Access Violation na DLL libXMLSec.dll ao assinar a NFe. Começou a ocorrer este erro depois que atualizei o ACBr, meu executável antigo não dava este problema. O que pode ser?

Incompatibilidade de DLLs provavelmente.

Se você está compilando o ACBr com a diretiva {DEFINE USE_MINGW} ativada, deve usar as DLLs da pasta ACBr\DLLs\XMLSec\MinGW\32.

Senão, usar as DLLS da pasta ACBr\DLLs\XMLSec e ACBr\DLLs\OpenSSL\0.9.8.14

[JJA]

18 horas atrás, BigWings disse:

Incompatibilidade de DLLs provavelmente.

Se você está compilando o ACBr com a diretiva {DEFINE USE_MINGW} ativada, deve usar as DLLs da pasta ACBr\DLLs\XMLSec\MinGW\32.

Senão, usar as DLLS da pasta ACBr\DLLs\XMLSec e ACBr\DLLs\OpenSSL\0.9.8.14

Obrigado, funcionou. Substituí as DLLs e deu certo.

Eu realmente estava confundindo WinCrypt com MinGW, achando que era meio que a  mesma  coisa.

WinCrypt veio para  substituir a CAPICOM, e atentando assim tanto certificados A1 como A3 correto?

MinGW é aquela atualização para usar TLS 1.2 para a NFe 4.0  correto? Neste caso, para usar o ACBrNFe de forma correta para  a versão 4.0, obrigatóriamente eu preciso instalar o componente com MinGW?

[BigWings]

46 minutos atrás, JJA disse:

WinCrypt veio para  substituir a CAPICOM, e atentando assim tanto certificados A1 como A3 correto?

Sim.

46 minutos atrás, JJA disse:

MinGW é aquela atualização para usar TLS 1.2 para a NFe 4.0  correto? Neste caso, para usar o ACBrNFe de forma correta para  a versão 4.0, obrigatóriamente eu preciso instalar o componente com MinGW?

Se quiser usar OpenSSL com NFe 4.00.

[JJA]

2 horas atrás, BigWings disse:

Sim.

Se quiser usar OpenSSL com NFe 4.00.

Certo, entendi. Então MingGW é para uso da OpenSSL.

Então se eu for usar WinCrypt, no qual atende tanto Certificados A1 como A3, ele já atende a NFe 4.0 sem precisar do MingGW?

Porém para certficados A1 usando WinCrypt, sou obrigado a instalar o Certificado A1 no padrão 1024bits,  pois se mante-lo como 2048 bits, me retorna o erro de suporte a criptografia 24. Está correto?

[Daniel Simoes]

48 minutos atrás, JJA disse:

Porém para certficados A1 usando WinCrypt, sou obrigado a instalar o Certificado A1 no padrão 1024bits,  pois se mante-lo como 2048 bits, me retorna o erro de suporte a criptografia 24. Está correto?

Para certificados A1, você não é obrigado a instalar o Certificado... basta apontar para o conteúdo do PFX, usando ArquivoPFX ou DadosPFX

[JJA]

2 minutos atrás, Daniel Simoes disse:

Para certificados A1, você não é obrigado a instalar o Certificado... basta apontar para o conteúdo do PFX, usando ArquivoPFX ou DadosPFX

Olá Daniel,

Então aquele erro de suporte a criptografia 24 só ocorre quando o certificado está instalado? 

Neste caso em que está ocorrendo usando o WinCrypt, posso então desinstalar o certificado A1 da máquina e apontar ele no componente ACBrNFe que já funcionará ou o problema está no arquivo PFX mesmo? Ele foi gerado com criptografia 2048 bits e neste caso para usar o WinCrypt, que suporta apenas A1 com criptografia 1024 bits, teria sim que instala-lo usando o programa da valid que converte certificados em 1024 bits?

Não sei se estou viajando,  mas hoje eu já aponto o certificado A1 no componente ACbrNFe, mas eu também instalava ele achando que precisava.
 

[BigWings]

3 minutos atrás, JJA disse:

Olá Daniel,

Então aquele erro de suporte a criptografia 24 só ocorre quando o certificado está instalado? 

Neste caso em que está ocorrendo usando o WinCrypt, posso então desinstalar o certificado A1 da máquina e apontar ele no componente ACBrNFe que já funcionará ou o problema está no arquivo PFX mesmo? Ele foi gerado com criptografia 2048 bits e neste caso para usar o WinCrypt, que suporta apenas A1 com criptografia 1024 bits, teria sim que instala-lo usando o programa da valid que converte certificados em 1024 bits?

Não sei se estou viajando,  mas hoje eu já aponto o certificado A1 no componente ACbrNFe, mas eu também instalava ele achando que precisava.
 

Mesmo apontando o arquivo .pfx o erro ocorre.

A solução nesses casos é usar OpenSSL, ou instalar o certificado num Windows XP e exportar, ou usar o instalador da certificadora como já foi discutido no outro post.

 

Caso aponte o arquivo não é preciso instalar.

E sim, o WinCrypt já atende a TLS 1.2.

[Daniel Simoes]

Recentemente eu apliquei no SVN um possível ajuste para o problema: "Nao ha suporte para criptografia 24"

[JJA]

Boa tarde Daniel,

que bacana! Vou testar logo mais. Aproveitando, uma dúvida:

Pelo que eu havia entendido, este problema era aplicado em cima do certificados instalados com criptografia 2048 Bits no qual a libCapicom não conseguia utilizar correto? E no caso a libOpenSSL conseguia. Se sim, este erro não deveria ocorrer usando OpenSSL correto?

[Daniel Simoes]

Na verdade a limitação é da DLL MSXML... ela que não suporta esse tipo de certificado... mas para SHA1, podemos usar a engine de criptografia do próprio Windows... veja o simples ajuste nos fontes de ACBrDFeXsMsXml.pas, no tratamento da Exceção...

Se você usar SSLXmlSignLib = xsLibXml2 ou  xsXmlSec, o problema nunca ocorreria...
 

      try
        dsigKey := xmldsig.createKeyFromCSP( ProviderType,
                                             WideString(ProviderName),
                                             WideString(ContainerName), 0);
      except
        on E: Exception do
        begin
          Erro := LowerCase(E.Message);
          if (pos('provider type', Erro) > 0) and
             (pos('not supported', Erro) > 0) then
          begin
            ProviderType := 1;
            ProviderName := 'Microsoft Enhanced Cryptographic Provider v1.0';
            dsigKey := xmldsig.createKeyFromCSP( ProviderType,
                                                 WideString(ProviderName),
                                                 WideString(ContainerName), 0);
          end;
        end;
      end;  

Mais informações em: