Arquivo temporario ao assinar documentos ocupando todo o HD

[MarcosRWeimer]

Ao assinar, seja NF-e, CT-e, NFS-e, está criando arquivos temporários, após alguns minutos ja chegam a 670mb ocupados em disco, imagina um dia todo, ou semanas, acabamos descobrindo por que o HD de um cliente encheu sem explicação.

 

Os componentes são criados em runtime e liberados após terminar o envio, a cada novo documento, o componente é criado novamente de acordo com o documento que está emitindo.

A cada documento assinado cria um arquivo temporário com 3Kb, não estamos encontrando onde está o problema.

 

[Antonio Carlos L]

Isso aqui deve te ajudar

https://stackoverflow.com/questions/34527477/clean-my-machinekeys-folder-by-removing-multiple-rsa-files-without-touching-iis

 

[MarcosRWeimer]

21 horas atrás, Antonio Carlos L disse:

Isso aqui deve te ajudar

https://stackoverflow.com/questions/34527477/clean-my-machinekeys-folder-by-removing-multiple-rsa-files-without-touching-iis

 

Não entendi uma possível solução com base nestas informações.

O local que gera o arquivo temporário é:

 

[BigWings]

Pelo que vi o arquivo é criado quando configurado como cryWincrypt e informando o arquivo PFX e senha, a cada carga do certificado.

O componente vai carregar o certificado apenas uma vez então se você mantiver o objeto ACBrNFe em memória deve reduzir massivamente a quantidade de arquivos criados.

Outra solução seria usar OpenSSL no lugar da WinCrypt.

[MarcosRWeimer]

47 minutos atrás, BigWings disse:

Pelo que vi o arquivo é criado quando configurado como cryWincrypt e informando o arquivo PFX e senha, a cada carga do certificado.

O componente vai carregar o certificado apenas uma vez então se você mantiver o objeto ACBrNFe em memória deve reduzir massivamente a quantidade de arquivos criados.

Outra solução seria usar OpenSSL no lugar da WinCrypt.

Exato, estamos usando libWinCrypt

 

[everson.turossi]

20 horas atrás, BigWings disse:

Pelo que vi o arquivo é criado quando configurado como cryWincrypt e informando o arquivo PFX e senha, a cada carga do certificado.

Fiz alguns testes e é isso mesmo.

Aqui também utilizo os componentes em runtime. O jeito vai ser criar no momento uma rotina pra excluir os arquivos gerados, e pelo que percebi, a pasta final muda de PC para PC. Aqui os arquivos são gerados na pasta C:\Users\MeuUsuario\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-1848721904-2759955265-3548017548-1001

[MarcosRWeimer]

Em 18/10/2019 at 09:36, everson.turossi disse:

Fiz alguns testes e é isso mesmo.

Aqui também utilizo os componentes em runtime. O jeito vai ser criar no momento uma rotina pra excluir os arquivos gerados, e pelo que percebi, a pasta final muda de PC para PC. Aqui os arquivos são gerados na pasta C:\Users\MeuUsuario\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-1848721904-2759955265-3548017548-1001

A parte final muda de um certificado para outro, não necessáriamente de um pc para outro

[Dipold]

A flag PKCS12_ALLOW_OVERWRITE_KEY, segundo a documentação do wincrypt.h, diz:

Citar

Allow overwrite of the existing key. Specify this flag when you encounter a scenario in which you must import a PFX file that contains a key name that already exists. For example, when you import a PFX file, it is possible that a container of the same name is already present because there is no unique namespace for key containers. If you have created a "TestKey" on your computer, and then you import a PFX file that also has "TestKey" as the key container, the PKCS12_ALLOW_OVERWRITE_KEY setting allows the key to be overwritten.

Ou seja, o arquivo com a chave privada armazenada em cache é sempre sobrescrito para o mesmo PFX.

Em meus testes, criando o componente múltiplas vezes em runtime, com a alteração sugerida abaixo, o arquivo com a chave privada é criado no diretório de cache dos certificados, mas apenas uma vez.

 

Essa alteração resolve o problema de quem precisa criar o componente em runtime e importar o PFX a cada ciclo de execução.

[Daniel Simoes]

olá pessoal... obrigado pela analise e detecção do problema (e da solução)...

Poderia por favor enviar os fontes modificados, para analise ?

[Balena]

Olá!

 

Arquivo em anexo.

ACBrDFeWinCrypt.pas

[Daniel Simoes]

Confesso que tenho um pouco de receio dessa mudança...

Provavelmente não está relacionado... ainda mais que essa rotina somente seria usada quando se trata de um certificado A1 (PFX)...

Mas a opção "PKCS12_ALLOW_OVERWRITE_KEY", poderia reacender os tópicos "O ACBr apagou meu certificado"...

 

[Balena]

Olá!

Testamos em variados bancos de dados com variados certificados digitais, todos A1, e resolveu. Até indicamos a nossos clientes que adquiram o A1 ao invés do A3.

Nosso caso pode ser um pouco diferente, pois não temos o certificado instalados nos computadores, nem fisicamente nas estações. Armazenamos os dados em banco e passamos ao componente para os DadosPFX, NumeroSerie e Senha. 

Preferimos assim pois facilita muito o operacional.

 

Das opções de: Voltar para OpenSSL ou apagar manualmente, penso que ambas são (bem) ruins, pois deve ser responsabilidade do componente fechar a store da forma adequada. 

 

Para nós resolveu e somente estamos aguardando o parecer de vocês se vão subir para o repositório para por para produção.

Se decidirem por não subir iremos manter a alteração no nosso.

 

Obrigado!

[Daniel Simoes]

55 minutos atrás, Balena disse:

Das opções de: Voltar para OpenSSL ou apagar manualmente, penso que ambas são (bem) ruins, pois deve ser responsabilidade do componente fechar a store da forma adequada. 

A sua sugestão de modificação no código, não implementa isso...

Para A1, OpenSSL é com certeza a melhor e mais sensata escolha...

Pois você não depende de atualizações do Windows, para funcionar adequadamente TLS1.2

[Balena]

1 hour ago, Daniel Simoes said:

A sua sugestão de modificação no código, não implementa isso...

Me expressei mal Daniel. Mas penso que é responsabilidade do componente controlar isso. Ele não deve ser responsável por fazer com que em alguns minutos 670mb de arquivos duplicados sejam gerados no servidor.

 

Quanto a melhor opção, aí penso que é opção pessoal, para a nossa situação na empresa foi muito mais simples criar o pré-requisito do usuário ter o windows atualizado.

Volta e meia tínhamos problemas com DLL com versão incompatível em cliente, ou então com erros como o citado abaixo:

 

 

Se não me engano tínhamos um problema com o envio de e-mail também, mas agora a minha memória não ajudou.

 

Depois da migração total para o WinCrypt os processos que o utilizam ficaram bem mais estáveis. 

Claro que não é perfeito, mas para o nosso caso a experiência com ele foi, sem dúvidas, muito melhor que o OpenSSL.

 

Mas Ok, estou vendo que você não vai querer subir. 

Vou criar uma versão paralela para nosso sistema e, caso tenhamos problemas, irei voltar aqui para relatar.

 

Obrigado.

[Daniel Simoes]

2 horas atrás, Balena disse:

Me expressei mal Daniel. Mas penso que é responsabilidade do componente controlar isso. Ele não deve ser responsável por fazer com que em alguns minutos 670mb de arquivos duplicados sejam gerados no servidor.

Mas não é o componente que faz isso... e sim a Wincrypt...  O problema não ocorre com a OpenSSL

2 horas atrás, Balena disse:

Volta e meia tínhamos problemas com DLL com versão incompatível em cliente, ou então com erros como o citado abaixo:

Se você distribuir as DLLs na mesma pasta do seu .EXE, nunca terá problemas de "dll hell"

 

[Balena]

1 hour ago, Daniel Simoes said:

Se você distribuir as DLLs na mesma pasta do seu .EXE, nunca terá problemas de "dll hell"

 

É uma forma de pensar, bem como se você não usar a DLL não precisará distribuí-la junto de seu .EXE

 

Enfim, pode fechar o tópico.

 

Obrigado pela ajuda.

[Daniel Simoes]

a WinCrypt é uma DLL...
 

Citar

Onde posso encontrar a WinCrypt ?

Ela já está instalada, de forma nativa, no seu Windows... com o nome: "crypt32.dll"

• Se o seu Windows é 64 bits, você encontrará a mesma em:
  • 32 bits: "C:\Windows\SysWOW64"
  • 64 bits "C:\Windows\System32"
• Se o seu Windows é 32 bits, você encontrará a mesma em:
  • "C:\Windows\System32"