Certificado cadeia v5 nao funciona no OpenSSL

[Vitor JR]

Olá. 

Fizemos um certificado novo e não estou conseguindo substituir o certificado atual pelo NOVO certificado dentro do ACBrMonitorPlus (OpenSSL). Ao substituir o certificado ATUAL pelo NOVO o ACBr retorna "Inativo ou Inoperante" relativo aos webservices da NFe SEFAZ SP. Os webservices do RS e o MDF-e de SP respondem normalmente com "Serviço em Operação", mesmo com o NOVO certificado.

A única coisa que consegui diferenciar de um certificado para outro é que esse NOVO certificado só possui Autoridade Certificadora Raiz Brasileira v5, enquanto que o atual também possui Autoridade Certificadora Raiz Brasileira v4.

Usando Capicom e instalando o certificado NOVO e cadeias dentro do Windows, consigo comunicar com a SEFAZ-SP pelo ACBr, porém em produção utilizo Linux, que suporta somente OpenSSL, mesmo utilizando a versão Windows do ACBr pelo "emulador wine".

Também tentei várias combinações de Libs sem nenhum sucesso - só consegui mesmo com Capicom em um Windows NATIVO.

Não consegui encontrar outros tópicos a respeito desse assunto, desculpem-me se já existir.

Aguardo orientações sobre o que pode estar acontecendo aqui - não consegui entender, mesmo pesquisando bastante (mais de um mês).

 

Desde já, agradeço MUITO a ajuda. Utilizo o ACBrMonitorPlus há anos (desde o tempo do ACBrNfeMonitor) e sempre funcionou de maneira excelente. 

 

[Daniel Simoes]

Não temos esse certificado para testes...

Se for possível, considere nos ceder por empréstimo para testes...

( pode usar M.P. para resposta )

[Daniel Simoes]

Obrigado pelo envio dos Certificados para teste...

Eu realmente consegui reproduzir o problema, com OpenSSL, certificado em PFX, consultando o Status de Serviço em SP, em um Certificado onde todas as cadeias, são V5 (imagem abaixo)

Creio que seja algo no lado do Servidor, que ainda não deve ter as novas cadeias de certificado instaladas...

Este problema me remeteu a esse tópico, de problema muito similar:

Usando a solução de converter o PFX para PEM, e posteriormente lê-lo usando o "FHTTP.Sock.SSL.CertCAFile", realmente funcionava... o que me fez concluir que a maneira como a Synapse estava lendo o arquivo PFX, não estava completa, pois não lia os certificados da Cadeia, no contexto...

A solução foi simples, há um comando para inserir uma cadeia de certificados, no contexto... (porém somente descobri após muita pesquisa)

        if PKCS12parse(p12, FKeyPassword, pkey, cert, ca) > 0 then
          if SSLCTXusecertificate(Fctx, cert) > 0 then
            if SSLCTXusePrivateKey(Fctx, pkey) > 0 then
              Result := True;

        //  Set Certificate Verification chain
        if Result and (ca <> nil) then
          SslCtxCtrl(Fctx, SSL_CTRL_CHAIN, 0, ca);   // <---- AQUI

Por favor teste, substituindo as Units e anexo, na sua pasta:

ACBr\Fontes\Terceiros\synalist

 

ssl_openssl_lib.pas ssl_openssl.pas

[Vitor JR]

Agradeço imensamente por ter ido a fundo nessa parte e encontrado a solução correta; porém, eu utilizo o ACBrMonitorPlus já compilado - nunca tentei compilar o projeto. Eu utilizo o harbour no meu dia-a-dia, que manda o arquivo .ini através do ent.txt / sai.txt .
Teria alguma .lib ou .dll ou mesmo algum arquivo de configuração na pasta C:\ACBrMonitorPLUS (ou subpastas) que eu consiga substituir para poder testar essa solução?

Valeu!

[Daniel Simoes]

Creio que o @José M. S. Junior possa compilar uma versão de testes...

[BigWings]

@Daniel Simoes @Vitor JR

Eu tive um problema recente com um certificado de cliente com essa mesma cadeia, mas acessando pela SVRS.

Usando OpenSSL ocorria o erro HTTP 403 em qualquer operação, com WinCrypt a consulta de status funcionava mas ao tentar emitir a NFCe retornava a rejeição "Certificado Transmissor erro no acesso a LCR".

Após vários contatos com a certificadora que dizia que estava tudo certo com o certificado, a resposta veio da SEFAZ-RS:

Citar

Verificamos o caso. Não se trata de um problema de instabilidade no servidor. Trata-se de um problema com o certificado digital, que não está cadastrado na ITI.

Para que um certificado possa ser usado na emissão de NF-e ou NFC-e, é absolutamente essencial que esse certificado esteja cadastrado como válido na ITI. Um certificado que não estiver cadastrado na ITI não vai funcionar na emissão de NF-e ou NFC-e.

Vocês enviaram um XML em anexo. O certificado que enviou esse XML é o AC SOLUTI Multipla v5.

Notamos que a AC de 2º Nível deste certificado não está publicada no ITI, e por consequência, não está instalada em nossos servidores.

https://www.iti.gov.br/repositorio/84-repositorio/489-certificados-das-acs-da-icp-brasil-arquivo-unico-compactado

O certificado também não consta na lista ACs de segundo nível da AC Soluti:

http://www.iti.gov.br/repositorio/93-cadeias-da-icp-brasil/ac-soluti/445-ac-soluti-multipla-de-2-nivel

Portanto, pelo visto o certificado não foi cadastrado corretamente na ITI, e é isso que está gerando a rejeição. Vocês devem contatar a entidade que forneceu o certificado, e solicitar que ele seja cadastrado corretamente.

(editado)

Agente Fiscal do Tesouro do Estado

NAVi  -  Núcleo  de  Atendimento  Virtual

Receita Estadual – RS

Isso foi no dia 08/04/2019.

Depois de contatar novamente a certificadora com essa informação, eles admitiram o problema e foi solucionado no dia seguinte com a publicação da cadeia no ITI e atualização das mesmas pela SEFAZ-RS.

Então creio que a SEFAZ-SP deve fazer o mesmo.

13 horas atrás, Daniel Simoes disse:

Por favor teste, substituindo as Units e anexo, na sua pasta:

Infelizmente o certificado que tinha do cliente foi revogado e emitido um novo com ICP-Brasil v2. Testei mesmo assim (usando o certificado revogado) a consulta de status:

GO em homologação passou a funcionar.

Em SP continua o erro 403 mas ele acontece com WinCrypt também.

[Vitor JR]

@BigWings - vou passar o recado da SEFAZ-RS para minha certificadora (por sinal, é a SOLUTI também...)
Também vou testar a solução que o @José M. S. Junior vai fazer a gentileza de compilar prá mim, com este certificado da cadeia v5 e também com outros de outras certificadoras com a LibSSL.

Vamos evoluindo com o assunto!

[José M. S. Junior]

7 minutos atrás, Vitor JR disse:

@BigWings - vou passar o recado da SEFAZ-RS para minha certificadora (por sinal, é a SOLUTI também...)
Também vou testar a solução que o @José M. S. Junior vai fazer a gentileza de compilar prá mim, com este certificado da cadeia v5 e também com outros de outras certificadoras com a LibSSL.

Vamos evoluindo com o assunto!

Bom dia Vitor,

Aparentemente com o ajuste realizado pelo Daniel, solucionou o problema para este certificado no Windows e Linux... Favor realizar os testes com Versão em anexo, para o Windows basta substituir o executável na pasta do ACBrMonitor.

 

ACBrMonitorPLUS-1.2.0.60-1.x86_64.rpm ACBrMonitor.zip

[Vitor JR]

  Grandemente agradecido pela solução.   

Acabei de testar e funcionou corretamente (pelo menos o ConsultaStatus).

Estou anexando as evidências do funcionamento (somente o "sucesso" - guardei o comparativo com a versão anterior mas não vou postar para não confundir).
(...No meu caso, utilizo o ACBrMonitorPLUS.exe através do wine em um Ubuntu 14...)

Peço que aguardem mais 1 ou 2 dias antes de fechar o tópico, pois vou colocar para rodar nos outros usuários que REALMENTE emitem NF-e para garantir que os webservices de processamento de NFe aceitarão a solução da mesma forma.

Novamente, agradeço a atenção e solução!

[Daniel Simoes]

Obrigado pelo Retorno...

Não é mais simples usar o MonitorPlus em Linux?

[EMBarbosa]

Em 27/05/2019 at 10:11, Vitor JR disse:

(...No meu caso, utilizo o ACBrMonitorPLUS.exe através do wine em um Ubuntu 14...

Eu concordo com o Daniel acima. O ACBrMonitor tem versão funcional do Linux. Talvez seu cenário seja muito diferente.

 

[Daniel Simoes]

Acabei esquecendo de subir as modificações para o SVN...

Feito.. Rev: 17149