Delcio

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:

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

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?

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

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.

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 é fogo, agora resolveram enviar e-mail. E ainda por cima a explicação deles não tem nada a ver com oque realmente acontece. Não consegui fazer essa dupla funcionar, então parti pra assinatura direta, usando somente a MSCrypto, gerando o hash, assinando e aplicando as transformações diretamente no XMl, não é um processo tão complicado, mas estou apanhado pra aplicar a Canonification c14n, não estou conseguindo selecionar corretamente os nodes para aplicar o cn14, o resto estaria pronto já.

Sim estava testando com senhas diferentes e sempre é solicitado o PIN. Fiz mais alguns testes: Testando com outro cartão, esse da Oberthur, que permite ativar um log dos acessos ao certificado descobri mais umas coisas: Após cada transação, o hardware do cartão é reiniciado como pode ser visto abaixo; 2017-11-03 16:03:10.240 (TID=9840) DEBUG [PCSCReader.cpp:83] SCardEstablishContext (0000) 2017-11-03 16:03:10.260 (TID=9840) DEBUG [PCSCReader.cpp:430] begin Transaction 2017-11-03 16:03:10.266 (TID=9840) DEBUG [PCSCReader.cpp:94] POWER_ON 2017-11-03 16:03:10.585 (TID=9840) DEBUG [PCSCReader.cpp:107] SCardConnect on reader ACS CCID USB Reader 0 (0000) 2017-11-03 16:03:10.595 (TID=9840) DEBUG [PCSCReader.cpp:629] APDU 00 A4 04 0C 10 A0 00 00 00 77 01 08 00 07 00 00 FE 00 00 01 00 2017-11-03 16:03:10.665 (TID=9840) DEBUG [PCSCReader.cpp:677] Return :90 00 2017-11-03 16:03:10.665 (TID=9840) DEBUG [PCSCReader.cpp:629] APDU 00 A4 04 0C 0D E8 28 BD 08 0F F2 50 4F 54 20 41 57 50 2017-11-03 16:03:10.695 (TID=9840) DEBUG [PCSCReader.cpp:677] Return :90 00 2017-11-03 16:03:10.695 (TID=9840) DEBUG [PCSCReader.cpp:520] end Transaction 2017-11-03 16:03:10.698 (TID=9840) DEBUG [PCSCReader.cpp:239] POWER_OFF 2017-11-03 16:03:10.702 (TID=9840) DEBUG [PCSCReader.cpp:260] SCardDisconnect (0000) Demora um tempo para essa "reinicialização" acontecer, e caso seja chamado o método createKeyFromCSP ou createKeyFromCertContext da MSXML5.dll durante esse intervalo, algum bug nessa DLL faz com que uma chamada para exclusão do conjunto de chaves seja feita ao hardware do cartão, como pode ser visto mais abaixo: 2017-11-03 16:03:10.702 (TID=9840) DEBUG [PCSCReader.cpp:260] SCardDisconnect (0000) 2017-11-03 16:03:10.704 (TID=9840) [OcsCsp.cpp:245] CPAcquireContext returned ERROR 0x80090016 2017-11-03 16:03:10.708 (TID=9840) [OcsCsp.cpp:166] AcquireContext (container "{2E6C5A0A-2AE2-7ff6-D224-EA19FB355731}", flags CRYPT_DELETEKEYSET 0x00000010) Nesse momento o gerenciador do cartão solicita o PIN e caso o usuário digite o certificado é excluído. Essa DLL é a que usamos para a assinatura dos XMLs, ela é da Microsoft, faz parte do office e na sua versão mais atual, a MSXML6 não tem mais suporte a assinatura de XMLs, portanto é muito provável que não haverá qualquer correção ou suporte nessa DLL por parte da Microsoft. Notei que a Oberthur já contornou o problema: Na nova versão 5.1.8 SR1 do AWP Manager é exibida uma mensagem de "Acesso Negado" no momento da tentativa de exclusão e o certificado não é excluído. Testei o gerenciador da Safesign e mesmo na versão mais atual o certificado foi excluído, inclusive certificados armazenados em tokens USB. Estou trabalhando em uma Unit de assinatura que usa somente a MSCRYPTO, assim que terminar vou disponibilizar aqui, precisarei de ajuda para testá-la e quem sabe assim se livramos da MSXML5 e conseguimos conviver em paz com os A3.

Acho que não resolveria, porque o usuário não está removendo o cartão, mas no momento da assinatura, quando é solicitado o PIN, o certificado dá uma "reiniciada", como se tivesse sido removido e inserido novamente. Só notei isso em métodos de assinatura que usam MSXML. Quanto ao certificado ser excluído pela biblioteca não encontrei nenhuma especificação que mencione isso, sempre diz que o certificado deve ser bloqueado em caso de tentativas de PIN incorretas, e não excluído. Então acho que os fabricantes tem alguma culpa aí sim. Também recomendo o A1 a todo custo, mas convencer o cliente a usar é outra história. Sempre tem alguém que vai dizer pra ele: Uso a anos e nunca vi isso acontecer. As próprias certificadoras recomendam o A3 e dizem que não vai ter problema, depois que a bomba explode tiram o corpo fora e colocam a culpa em nossos sistemas. Vou fazer uns testes com libXMLSec pra ver se consigo algo com ela.

Até aí tudo bem, em nenhum momento culpo o ACBR, mas entre ele o o Certificado temos vários suspeitos: MSXML, Software Gerenciador do Certificado, Hardware da Leitora e o próprio Hardware do SmartCard. O fato é que o problema, mesmo que externo ao ACBR, está ocorrendo e causando muitos transtornos as empresas. Se encontrarmos o ponto exato onde o problema ocorre, talvez possamos contornar esse problema externo pelo próprio ACBR ou mesmo forçar as Certificadoras e fabricantes de dispositivos a resolver o problema.

Mais alguns testes: Ambos os métodos "IXMLDigitalSignature.createKeyFromCertContext()" e "IXMLDigitalSignature.createKeyFromCSP()" usados nas classes TDFeSSLXmlSignMsXml e TDFeSSLXmlSignMsXmlCapicom, causaram a exclusão do certificado quando forçada a sua chamada antes do cartão estar "Operacional". Isso aumenta minhas desconfianças sobre a MSXML. Ainda não deu tempo de testar com TDFeSSLXmlSignXmlSec, libxmlSec e OpenSSL.

Está solicitando PIN, e não tem nenhuma informação que é para a exclusão do certificado.

Veja que de qualquer maneira tem uma falha muito grande ai: Permitir a exclusão do certificado pelo PIN, se você for lá no administrador do token e remover manualmente o certificado, também será solicitado somente o PIN. Para excluir deveria ser o PUK ou mesmo outra senha diferente, aí não teria como o usuário ser "enganado" e excluir. Nem se quer um diálogo de confirmação é apresentado, o que leva a acreditar que estamos autorizando a assinatura quando na verdade estamos autorizando a exclusão.

Olá amigos, depois de mais um cliente ter perdido o certificado resolvi que ia tentar descobrir oque estava causando isso, e depois de muita peleja(são 4:00 da manhã ), acho que consegui chegar ao causador do problema, pelo menos tive sucesso em excluir um certificado por diversas vezes assinando um XML. E como muito se falava, não é diretamente o ACBR que está excluindo o certificado, pelo que constatei é a MSXML que está "reiniciando" o certificado e somando isso a mais algum problema está causando a exclusão. Se você assinar um XML e deixar o administrador do token aberto, verá que no momento da assinatura, no trecho "xmldsig.sign(dsigKey, CERTIFICATES);" o token muda de: Operacional >> Ausente >> Presente >> Operacional, como se o cartão fosse removido e inserido novamente. Pensei aí tem coisa! Tentei remover o cartão durante a assinatura mas não consegui simular a exclusão do certificado, imaginei que não estava sendo rápido o suficiente. Então coloquei um loop no trecho do ACBR que pega a chave privada do certificado, antes de executar a assinatura, percebi que até aí o PIN do certificado não era solicitado, somente mais a frente quando ocorre a assinatura com "xmldsig.sign(dsigKey, CERTIFICATES);". Porém quando removi o certificado da leitora e inseri novamente dentro do loop(o mesmo que a MSXML faz durante a assinatura) foi me solicitado o PIN e logo depois veio a mensagem: "O conjunto de chaves não está definido", olhando no administrador do token que estava aberto pude ver o certificado sendo excluído: O PIN que ele me solicitou foi para excluir o certificado! O que imagino que esteja acontecendo é que se você chamar o método Assinar repetidamente, antes de dar tempo do cartão ficar operacional novamente, o certificado pode ser excluído. Isso explicaria o porque da exclusão ser esporádica e também não acontecer com todos os sistemas, pois dependeria da lógica usada por cada um para assinar, como assinaturas em sequência ou mesmo mais de uma thread acessando o certificado. Fiz um vídeo mostrando o momento da exclusão, note que não consegui excluir na primeira tentativa, porque demorei muito pra inserir o cartão, estava com uma mão ocupada filmando, ia editar isso mas tô com muito sono. MODERAÇÃO: vídeo removido a pedido do usuário Vou dormir um pouco e amanha ver se me aprofundo no problema.

Adicionei as descrições dos motivos de ocorrência para o Bancoob. Estou postando caso alguém queira verificar e subir no SVN. ACBrBancoBancoob.pas

Seria muito interessante se eles pudessem passar em que momento ocorre e oque causa o problema, para que pudéssemos contornar de alguma forma nos outros cartões, pois comigo já aconteceu com cartões diferentes, alguns nem usam o AWP da Oberthur. Já são vários esse ano.

Olá. Apenas divulgando um projeto em que estou trabalhando: Um framework para Web em Delphi no estilo RAD. Servirá de base para nosso sistema que está sendo migrado para Web. Falta muita coisa ainda, se alguém puder ajudar fico grato. GitHub: https://github.com/DrHank/DelphiWeb