Configuração OpenSSL com TLS1.2

[Marcos RV Carvalho]

Bom dia.

Preciso de auxílio, não consigo configurar o uso do OpenSSL para o TLS 1.2.

Estou tentando emitir documentos na 4.00 (NF-e / NFC-e) no estado de Goiás, com a biblioteca OpenSSL e recebo o erro "Erro Interno: 10091 Erro HTTP: 500 URL: https://homolog.sefaz.go.gov.br/nfe/services/NFeConsultaProtocolo4?wsdl error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca".

Utilizo o certificado A1.
Consigo emitir para outros estados como Bahia com o "SSLType := LT_all", ao tentar um estado que exija o TLS 1.2 não consigo.

Minhas configurações estão da seguinte forma:

SSLLib := libOpenSSL;

SSLCryptLib := cryOpenSSL;

SSLHttpLib := httpOpenSSL;

SSLXmlSignLib := xsXmlSec;
SSLType := LT_TLSv1_2;

Segui todos os passos para atualização das dll's do OpenSSL e XmlSec e recompilação do componente com o MinGW, como sugerido no tópico https://www.projetoacbr.com.br/forum/topic/34177-acbrdfe-openssl-e-tls12/

Também li os seguintes tópicos 
https://www.projetoacbr.com.br/forum/topic/35950-erro-500-usando-openssl/
https://www.projetoacbr.com.br/forum/topic/41946-erro-interno10091-http500-depois-de-atualizar-o-acbr/
https://www.projetoacbr.com.br/forum/topic/25032-opensslxmlsec-ou-capicom-dependencia-de-bibliotecas-externas/
https://www.projetoacbr.com.br/forum/topic/30205-configurações-de-ssl-e-tls/
https://www.projetoacbr.com.br/forum/topic/42334-configurar-openssl/

Mas mesmo assim continuo recebendo esse mesmo erro.
Alguém sabe o que posso ter configurado errado?

Grato.

[Juliana Tamizou]

Bom dia 

Você também viu este video?

 

 

[Marcos RV Carvalho]

Olá Juliana, obrigado pela resposta.

Sim, vi o vídeo, retestei, reinstalei tudo para confirmar mas continuo recebendo esse mesmo erro.

Apenas um breve histórico do que fiz até o momento pra que entendam: fizemos a migração para o ACBr recentemente, e por tudo que havia estudado do componente cheguei a conclusão que o WinCrypt atenderia nossas necessidades, já que temos clientes com certificado A1 e A3, e havíamos liberado previamente um anúncio para nossa carteira de clientes sobre a compatibilidade do nosso sistema com sistemas operacionais obsoletos (como o XP por exemplo), e a necessidade de manter o SO sempre atualizado.

Mas tivemos problemas mesmo utilizando WinCrypt e com todas as condições do SO satisfeitas (atualizado, não pirata, etc).

O mais preocupante no nosso caso é o estado de GO que com o WinCrypt ainda estamos recebendo o erro "Erro Interno: 12175Erro HTTP: 0URL: https://homolog.sefaz.go.gov.br/nfe/services/NFeConsultaProtocolo4?wsdlFalha no Envio da Requisição.Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor".

Lembrando que consigo emitir para GO com o WinCrypt em alguns terminais, entretanto, ainda estamos enfrentando problemas com Windows 8, 8.1 ou 10 mesmo com todas as atualizações instaladas, e isso me deixou sem muitas opções.

Por fim decidimos testar o uso do OpenSSL para evitar qualquer dependência do SO, mas consigo utilizar essa biblioteca apenas com LT_all, quando emito com TLS 1.2 recebo o erro que informei no início do tópico "Erro Interno: 10091 Erro HTTP: 500 URL: https://homolog.sefaz.go.gov.br/nfe/services/NFeConsultaProtocolo4?wsdl error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca".

Não me importo em usar um ou o outro (de preferência o WinCrypt, já que temos clientes com A3).

Se for pra manter o WinCrypt queria saber se há algum outro problema que eu ainda não verifiquei. Ou se for pra substituir para o OpenSSL no TLS 1.2, gostaria de ver como solucionar esse problema do erro interno 10091.

Com o OpenSSL tentei até mesmo mudar a propriedade SSLXmlSignLib para o xsLibXml2 para não precisar recompilar com o MinGW no xmlSec, mas sem sucesso, recebo o mesmo problema.

 

Agradeço as respostas.

[André Ferreira de Moraes]

A versão OpenSSL não funciona com ambiente de homologação de Goias. 

Vc pode usar a seguinte configuração para o ambiente de homologação em Goias:

[Marcos RV Carvalho]

Obrigado pela resposta André, na sexta-feira fizemos testes em produção e com outras UF e funcionou perfeitamente. Com sua resposta posso ter certeza de que configuramos corretamente, apenas não funciona com GO mesmo.

 

Mais uma dúvida pra quem souber e puder ajudar. Como meu sistema utiliza os certificados A1 e A3, não posso manter apenas o OpenSSL. É possível manter as duas bibliotecas (OpenSSL e WinCrypt) com o mesmo conjunto de dll's, mudando apenas a configuração do componente? Fiz testes com as dll's do OpenSSL compiladas com o MinGW para emitir no WinCrypt, e até agora não tive problemas, mas gostaria de confirmar se posso manter esse conjunto de dll's com o MinGW para as duas bibliotecas sem risco de algum conflito.

Caso exista conflito vou ter que bolar alguma forma de separação do conjunto de dll's e ver como faço pra carregar corretamente cada biblioteca quando necessário.

Minha intenção é manter o OpenSSL como padrão a fim de evitar uso de recursos do SO, e utilizar o WinCrypt apenas para clientes com certificado A3, já que esses são minoria pra mim.

 

Agradeço.

[Daniel Simoes]

A compilação com a MinGW não afeta a Wincrypt.. . São conjuntos de APIs bem diferentes...

Uma dica... se você configurar para usar a xsLibXml2... não precisaria das DLLs da XMLSec e nem da configuração para compilar com a MinGW... poderia usar apenas as DLLs do OpenSSL e da LibXML2 

[Marcos RV Carvalho]

Obrigado Daniel, legal, facilitaria muito minha vida.

Então eu poderia manter a compilação do componente igual para as duas bibliotecas (sem o MinGW), e utilizar sempre o xsLibXml2 ?

E as dll's libeay32.dll e ssleay32.dll posso utilizar a 1.0.2.13 do diretório do OpenSSL para as duas bibliotecas também. Correto?

 

Obrigado desdes já.

[Dercide Alvarez]

4 minutos atrás, Marcos RV Carvalho disse:

Obrigado Daniel, legal, facilitaria muito minha vida.

Então eu poderia manter a compilação do componente igual para as duas bibliotecas (sem o MinGW), e utilizar sempre o xsLibXml2 ?

E as dll's libeay32.dll e ssleay32.dll posso utilizar a 1.0.2.13 do diretório do OpenSSL para as duas bibliotecas também. Correto?

 

Obrigado desdes já.

Eu configuro no INI dos clientes se irão utilizar OpenSSL ou Wincrypt e funciona tranquilamente.

Dercide.

[Marcos RV Carvalho]

Obrigado pela ideia Dercide, creio que farei o mesmo.

[Marcos RV Carvalho]

Pessoal, consegui solucionar a maior parte de meus problemas, mas ainda tenho uma dúvida.

Tem alguma forma de obter o arquivo .pfx do certificado A1 a partir da leitura da store do windows utilizando a lib do WinCrypt?

Quando chamo o SSL.SelecionarCertificado são carregadas todas as informações no componente, mas não consegui gerar o .pfx a partir delas.

 

Há alguma forma de se fazer isso? @Daniel Simoes @André Ferreira de Moraes ?

Meu objetivo com isso é posteriormente salvar esse arquivo em banco para usar com o OpenSSL, já que não consigo carregar diretamente da store com o OpenSSL.

[Daniel Simoes]

Wincrypt também permite a carga do Certificado por PFX

Veja o método abaixo, em ACBrDFeWinCrypt.pas

function ExportCertContextToPFXData(ACertContext: PCCERT_CONTEXT; APass: AnsiString
  ): AnsiString;

 

[Marcos RV Carvalho]

Tem algum exemplo de uso desse método @Daniel Simoes?

Utilizei passando o context do certificado que carreguei mas me sobe a exceção "EACBrDFeExceptionNoPrivateKey with message 'Certificado não permite Exportar Chave Privada.'"

 

Chamei da seguinte forma

  NFe.SSL.NumeroSerie := NFe.SSL.SelecionarCertificado;
  NFe.SSL.CarregarCertificado;

  if NFe.SSL.CertificadoLido then
  begin
    Memo1.Lines.Add('Certificado carregado com sucesso!');
    Memo1.Lines.Add(ExportCertContextToPFXData(TDFeWinCrypt(NFe.SSL.SSLCryptClass).Certificado, 'password'));
  end

 

Tentando exportar o certificado que carreguei pelo repositório do windows.

Editado 6 Agosto, 2018 por Marcos RV Carvalho

[Marcos RV Carvalho]

Se eu já carregar pelo ArquivoPFX consigo utilizar esse método que me passou... mas queria exportar um certificado que foi carregado via "SelecionarCertificado", do repositório do windows. Nesse caso eu não tenho o .pfx ainda.

Editado 6 Agosto, 2018 por Marcos RV Carvalho

[Daniel Simoes]

24 minutos atrás, Marcos RV Carvalho disse:

Utilizei passando o context do certificado que carreguei mas me sobe a exceção "EACBrDFeExceptionNoPrivateKey with message 'Certificado não permite Exportar Chave Privada.'"

A3 não permite exportar a chave ... e A1 dependendo de como foi instalado, também não permitiria

[Marcos RV Carvalho]

Agora, Daniel Simoes disse:

A3 não permite exportar a chave ... e A1 dependendo de como foi instalado, também não permitiria

Não é A3.. o A3 vou manter o uso do winCrypt mesmo e deixar o processo normal. Essa "conversão" que to tentando fazer é para o A1 que o cliente não salvou no banco ainda.

É que no meu caso o sistema é maleável quanto a isso, eu permito que o usuário carregue uma única vez no banco ou utilize o certificado a partir do repositório. Mas como vou passar a usar o OpenSSL eu to tentando diminuir o impacto da mudança e manter da mesma forma q ele usa hoje, então pra isso eu teria que carregar o certificado via winCrypt do repositório e salvar o pfx no banco, para depois importar para o OpenSSL.

A minha necessidade é do A1 mesmo. Instalei em raiz confiável, normal.

[RibaSoft]

Ola, tenho um cliente entre 47 que não aceita nenhuma das dlls do OpenSSL que veio na pasta dos fonts baixados a 3 dias, só aceita as dlls da pasta 1.0*** de uma versão antiga dos fontes, alguém sabe o que pode ser?

Ele usa windows 10

Pergunto pq eu gostaria de colocar no meu instalador as mesmas dlls para todos os clientes de preferencia com as ultimas versões do OpenSSL

Minhas configurações

NFC.SSL.SSLType := LT_TLSv1_2; //Protocolo de Segurança de Comunicação

  NFC.SSL.SSLXmlSignLib := xsLibXml2; //Gerenciador de Assinatura
  NFC.SSL.Senha := Config.CertSenha;

  //Certificado A1
  if (Config.CertTipo = 0) then //arquivo pfx
  begin
    NFC.SSL.SSLCryptLib := cryOpenSSL; //Gerenciador de Certificado
    NFC.SSL.SSLHttpLib := httpOpenSSL; //Gerenciador da Comunicação
    NFC.SSL.ArquivoPFX := Config.CertLocalPFX;
  end;

  //Certificado A3
  if (Config.CertTipo = 1) then //do repositorio
  begin
    NFC.SSL.SSLCryptLib := cryWinCrypt; //Gerenciador de Certificado
    NFC.SSL.SSLHttpLib := httpWinHttp; //Gerenciador da Comunicação
    NFC.SSL.NumeroSerie := Config.CertSerie;
    NFC.SSL.CarregarCertificado;
  end; 

[Daniel Simoes]

Qual a exata mensagem do erro ?

Pode ser a falta o Runtime do Visual C

Rode junto com seu instalador,
http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/Diversos/x86/VC_redist.x86.exe

Aqui tem algumas dicas de como instalar ele em modo silencioso...
https://asawicki.info/news_1597_installing_visual_c_redistributable_package_from_command_line.html

 

[Jéter Rabelo Ferreira]

Bom dia.

Estou com um problema semelhante.

Passei a enviar somente as DLL's OpenSSL (1.1.1) e libxml2 e versão x64 de um de nossos sistemas.

Hoje um cliente me reportou o erro (imagem abaixo). Mudei para TLS1.2, e erro mudou para não suporte LT_TLS1_2.

Peguei as DLL's do MINGW e colei na pasta e funcionou.

Minha instalação não exige MINGW (Antigamente utilizava).

Como resolver isso para não precisar dessas DLL's (MINGW -x32/x64)?

[Daniel Simoes]

na imagem indica que está em LT_all

por favor atualize seus fontes... havia um bug que não mostrava o código de erro, corretamente...

[Jéter Rabelo Ferreira]

13 minutos atrás, Daniel Simoes disse:

na imagem indica que está em LT_all

por favor atualize seus fontes... havia um bug que não mostrava o código de erro, corretamente...

Sim, a imagem está em LT_all.

Mas eu mudei no sistema para LT_TLS1_2 e o erro ficou igual, mas informando que não suporta LT_TLS1_2 (Somente não colei a imagem).

Fontes atualizados nessa semana. Vou atualizar novamente para verificar.

"Obs.: Como disse acima, bastou colar as DLL's do MINGW que  Notas foram autorizadas."

Atenciosamente.

[Daniel Simoes]

Acho que você está compilando com a diretiva de MinGW, ligada... nesse caso, apenas as DLLs compiladas pela MinGW serão compatíveis...

Por favor tente compilar com o ACBr.inc original (sem XMLSec e MinGW)

[Jéter Rabelo Ferreira]

8 minutos atrás, Daniel Simoes disse:

Acho que você está compilando com a diretiva de MinGW, ligada... nesse caso, apenas as DLLs compiladas pela MinGW serão compatíveis...

Por favor tente compilar com o ACBr.inc original (sem XMLSec e MinGW)

 Veja imagem do meu ACBr.inc quanto a MINGW  

Vou clonar um repositório totalmente novo e instalar e testar.

Depois informo o resultado.

Atenciosamente.

[Jéter Rabelo Ferreira]

Seguinte.

Atualizei o componente e o erro foi o mesmo, precisando das DLL's MINGW para consultar uma NF-e.

Porém, ao utilizar a versão x32 do programa funcionou somente com as DLL's OpenSSL e Libxml2.

O erro ocorre somente com a versão x64 do programa.

[Daniel Simoes]

Pela falta do código de erro  na sua mensagem dá pra concluir que seus fontes não estão atualizados 

[Jéter Rabelo Ferreira]

11 minutos atrás, Daniel Simoes disse:

Pela falta do código de erro  na sua mensagem dá pra concluir que seus fontes não estão atualizados 

Eu apaguei todo o meu repositório e clonei um totalmente novo (veja datas na imagem abaixo),

Foi como eu disse.

x32 - OK
x64 - Não (Sem as DLL's OpenSSL com nomenclatura antiga - ssleay32 e etc). Eu coloquei as MINGW e funcionou.

Obs.: A pasta fontes está informada como alterada é o ACBr.inc alterado para retirar as opções (Capicom, XMLSec e etc)

 

Editado 20 Maio, 2020 por Jéter Rabelo Ferreira