O mistério da exclusão dos certificados A3

[Delcio]

Boas Novas:

Consegui assinar usando a MScrypto sem MSXML e LibXMLSec. Amanhã vou refatorar e testar se não causa nenhum problema no certificado.

[Daniel Simoes]

Muito bom... poderíamos criar uma nova classe de TDFeSSLXmlSignClass, que dispensaria o uso de XMLSec ou MSXML... tudo em código Pascal...

[Delcio]

Sim, já segui esse padrão, ela vai depender apenas da libXML2, que usei para aplicar as transformações.

Estou terminando de fazer os ajustes, depois posto a unit para ser avaliada.

[marcio-carneiro]

Parabéns. Boa iniciativa. E mostra um grande desprendimento pessoal para ajudar toda comunidade ACBR

Muito obrigado pelo empenho.

[Delcio]

Segue uma prévia da Unit.

Antes de mais nada: USE POR SUA CONTA E RISCO. NÃO ME RESPONSABILIZO POR QUALQUER PROBLEMA QUE POSSA DECORRER DESSE CÓDIGO DIRETA OU INDIRETAMENTE! (sim é gritado mesmo).

Não está pronta, precisa implementar/melhorar/testar muita coisa ainda, se você não é um desenvolvedor do ACBR é melhor esperar um versão final.

Está funcionando:

• Assinatura de NFe;
• Assinatura de Evento da NFe;
• Assinatura de Inutilização de Numeração da NFe; 
• Validações de DFe; 

Precisa ser feito:

• Implementar VerificarAssinatura;
• Testar com certificado CNG(no momento não tenho nenhum em mãos, mas vou ter que resolver isso pois pretendo colocar em produção em breve);
• Melhorar a forma de seleção dos elementos a serem assinados;
• Compatibilizar com outros documentos(no momento tenho apenas NFe em produção no ACBR);
• Testar/Compatibilizar com Lazarus;
• Verificar Memory Leaks;
• Alterações nas demais Units para suportar a nova classe;

Estou com pouco tempo disponível então toda ajuda é bem vinda. Qualquer dúvida estou a disposição.

 

ACBrDFeXsMsCrypto.pas

[Daniel Simoes]

Fiz uma analise superficial...

Me parece que você implementou métodos que já existem em TDFeSSLCryptClass como por exemplo:

   function CalcHash( const AStream : TStream;
       const Digest: TSSLDgst;
       const Assina: Boolean =  False): AnsiString; virtual; 

As classes filhas de TDFeSSLXmlSignClass (como é o caso da sua), não deveriam implementar isso... elas devem delegar esse trabalho para a classe TDFeSSLCryptClass que estiver instanciada.. como por exemplo: TDFeWinCrypt ou TDFeOpenSSL

[Delcio]

Humm, olhei só para TDFeSSLXmlSignClass e não analisei a  TDFeSSLCryptClass, fiz um retrabalho danado pois o método CalcHash já assina o Hash também .

Apenas fiquei na duvida no seguinte: Seguindo esse principio que você passou, na TDFeSSLXmlSignMsCrypto quem de fato geraria o Hash e a assinatura seria a  TDFeWinCrypt,  enquanto nas outras a isso fica a cargo da própria classe, como no caso da TDFeSSLXmlSignXmlSec, da TDFeSSLXmlSignMsXml e da TDFeSSLXmlSignMsXmlCapicom, isso não chega a ser um problema, mas não fica meio fora do padrão?

Editado 8 Novembro, 2017 por Delcio
Ortografia

[Rafael Dias]

@Delcio eu já fiz algumas alterações para usar a TDFeWinCrypt e também uma forma melhor de localizar os elementos.

ACBrDFeXsMsCrypto.pas

[Delcio]

3 horas atrás, Rafael Dias disse:

... eu já fiz algumas alterações para usar a TDFeWinCrypt e também uma forma melhor de localizar os elementos.

Testei aqui (na NFe somente) e funcionou bem, ficou bem mais limpa.

[Daniel Simoes]

Estamos analisando como validar a assinatura... em ACBrEAD, existe um método de validação de Hash com Sign Digest e chave pública...

[Filipe Natividade]

Alguma previsão de quando essa nova forma de assinatura estada disponível no ACBr oficialmente.

[Rafael Dias]

@Filipe Natividade estamos em fase final de implementação para liberação, a liberação deve ocorrer até o final da próxima semana, se tudo der certo.

[Bruno Meireles]

Eu já tive dois clientes que utilizavam certificado A3 e magicamente, as chaves públicas contendo o nome e CNPJ da empresa sumiram(foram excluídas), quando eu entrava em contato com a fabricante, eles sempre colocavam culpa no software emitente do documento fiscal. Na última vez tive até uma discussão feia com o atendente "Nível 4". Mas a fabricante sempre resolvia DANDO gratuitamente outro certificado para o cliente  enviando um voucher para o email do responsável do cert.

[Hércules Russano]

Olá

Tive recentemente um certificado A3 da Boavista, que também foi deletado. A Boavista se isentou de culpa, e na briga entre a Boavista e meu sistema que usa o ACBR, não temos dúvida: fui obrigado a comprar outro certificado para o cliente.

Daí em diante só recomendo que comprem o A1, e nunca desta Boavista.

[Daniel Simoes]

Tópico foi dividido...

https://www.projetoacbr.com.br/forum/topic/40260-nova-biblioteca-para-assinatura-de-xmls-baseada-apenas-na-libxml2/

[marcio-carneiro]

Agora aconteceu comigo.

Vou descrever o passo-a-passo para servir de estudo para os companheiros.

Tinha um cliente que tinha uma versão antiga do meu software de nfe, de 12/2016.

Ontem atualizei o software para a minha versão mais nova, já com atualização do ACBR que com certeza não é a mais nova, pois foi compilado em 10/17

e o desgraçado do certificado SOLUTION sumiu do cartão.

É um A3, emitido em 04/2017.

Já tive clientes que emitiram o mesmo cartão, digo do mesmo fornecedor, agora no segundo semestre, e no entanto está tudo correto.

Uma coisa que me chamou atenção, que quando coloquei a nova versão, ao emitir uma nfce ele pediu a senha do cartão, mesmo a mesma sendo informada via software.

Achei estranho, mas prossegui.

Agora o certificado aparece como desconhecido. Do nada sumiu.

O que pode estar acontecendo?

O que me chamou a atenção foi o fato do software antigo rodar tranquilamente com ele, e a versão mais nova acontecer isto.

O que pode ter acontecido?

 

[João Alberto Amaral]

Também estou com este problema, o certificado A3 foi removido duas vezes do cartão do cliente !

[ricardolopes]

3 horas atrás, marcio-carneiro disse:

Agora aconteceu comigo.

Vou descrever o passo-a-passo para servir de estudo para os companheiros.

Tinha um cliente que tinha uma versão antiga do meu software de nfe, de 12/2016.

Ontem atualizei o software para a minha versão mais nova, já com atualização do ACBR que com certeza não é a mais nova, pois foi compilado em 10/17

e o desgraçado do certificado SOLUTION sumiu do cartão.

É um A3, emitido em 04/2017.

Já tive clientes que emitiram o mesmo cartão, digo do mesmo fornecedor, agora no segundo semestre, e no entanto está tudo correto.

Uma coisa que me chamou atenção, que quando coloquei a nova versão, ao emitir uma nfce ele pediu a senha do cartão, mesmo a mesma sendo informada via software.

Achei estranho, mas prossegui.

Agora o certificado aparece como desconhecido. Do nada sumiu.

O que pode estar acontecendo?

O que me chamou a atenção foi o fato do software antigo rodar tranquilamente com ele, e a versão mais nova acontecer isto.

O que pode ter acontecido?

 

 

1 hora atrás, João Alberto Amaral disse:

Também estou com este problema, o certificado A3 foi removido duas vezes do cartão do cliente !

Pessoal bom dia.

Esse problema vem acontecendo já ha algum tempo, porém desde a semana passada já tem um tópico informando de um novo método para assinatura, a dúvida é o seguinte, em seus casos você já atualizaram o componente e setaram as configurações para o novo método de assinatura ou não? Pois essa é uma informação muito importante para a comunidade toda.

 

[marcio-carneiro]

No meu caso não, ainda uso capicom. 

O que foi estranho foi somente eu trocar a versão do programa acontecer. Pode ser coincidência.

 

[cbsistem]

Ola .. Meu certificado A3 acabou de ser excluido. 

 

E justamamente foi após um loop de assinatura de xml. Apos dar uma pausa... e tentar assinar outro xml.. a surpresa.

E realmente foi excluido.

 

 

[Delcio]

Em 05/01/2018 at 16:56, cbsistem disse:

Ola .. Meu certificado A3 acabou de ser excluido. 

 

E justamamente foi após um loop de assinatura de xml. Apos dar uma pausa... e tentar assinar outro xml.. a surpresa.

E realmente foi excluido.

 

 

 

Em 12/12/2017 at 18:42, marcio-carneiro disse:

No meu caso não, ainda uso capicom. 

O que foi estranho foi somente eu trocar a versão do programa acontecer. Pode ser coincidência.

 

Se você usa certificado A3 a unica forma de evitar a perda de mais certificados é usar a nova biblioteca de assinatura que não depende da libxml5.dll que  causava esse problema.

Já testei amplamente e não ocorreu mais a exclusão usando as novas classes, inclusive estou usando em produção já.

Mais informações em:

 

[RPadovezzi]

Em 23/11/2017 at 14:07, Rafael Dias disse:

@Filipe Natividade estamos em fase final de implementação para liberação, a liberação deve ocorrer até o final da próxima semana, se tudo der certo.

Boa tarde, nas versões atuais do ACBR já tem essa implantação? Estou orientando meus clientes a usarem A1, tenho 1 migração mas o cliente tem A3, será que posso fazer sem risco de ter essa exclusão?

[Rafael Dias]

@Rodrigo Goulart Padovezzi
Faz 2 Meses que já tem esta implementação, mas não posso garantir que não tenha risco nenhum.

[Daniel Simoes]

5 horas atrás, Rodrigo Goulart Padovezzi disse:

Boa tarde, nas versões atuais do ACBR já tem essa implantação? Estou orientando meus clientes a usarem A1, tenho 1 migração mas o cliente tem A3, será que posso fazer sem risco de ter essa exclusão?

Por favor leia o Topico todo... não é um problema ou erro do ACBr... mas sim do driver do fabricante ou da MSXML.

O ACBr abre a Store do certificado do Windows  em modo Readonly, portanto nunca conseguiria excluir o certificado...

[RPadovezzi]

Obrigado pela resposta. Eu li sim, desculpe se me expressei mal, quis na verdade ter conhecimento se após essa nova implementação alguém passou por esse problema. Mesmo não sendo o ACBR.