Boa tarde.
Primeira vez interagindo com a comunidade do ACBr. Quero dizer que estou utilizando o ACBr a algum tempo já.. E que antes utilizava o Monitor feito pelo pessoal da Unimake. Bom, seguinte.. Estou registrando o mesmo problema relatado pelos colegas.. Em 3 Clientes, que utilizam win7 32 e 64 bits, as chaves privadas do certificado foram apagadas... Todas elas eram certificados da Certsign e pesquisando na internet achei esse tópico. Primeiramente quero dizer que estive utilizando Unimake com (.net framework para asssinar) de 2008 a 2014 e nenhuma vez tive problema de clientes perderem o certificado.
Não acredito também que seja um problema de código do ACBr, por que conforme relato do colaboradores do projeto.. sempre está em mode de somente leitura. Store.Open(CAPICOM_CURRENT_USER_STORE, FCertStoreName, CAPICOM_STORE_OPEN_READ_ONLY);
Quero levantar algumas observações e algumas suposições que talvez nem façam sentido.. Mas..
1. O problema pode estar em várias camadas - No código de minha aplicação.. (Mas não chamo algumas funções especificas para a seleção do certificado, acho que não pode ser isto) - No código do ACBr.. (mas como já cidado acima, sempre utiliza CAPICOM_STORE_OPEN_READ_ONLY) - Nas próprias .Dlls do Capicom
2. Concorrência de aplicações - Pelo que percebi, um certificado A3 fica alocado no componente TACBrNFe na inicialização e uma segunda aplicação que tenta utlizar o certicado A3 dispara problemas de "canais seguros". - Se a aplicação for bastante persiste e com acessos simultaneos acredito que existe a possibilidade de se corromper a chave privada..
3. Se parar para pensar.. Os Certifidos A1 também em algum momento já corrompeu.. Mas como temos o backup acabamos por desistalar e instalar novamente.. Então talvez nem seja um problema isolado com A3..
4. ACBrCAPICOM_TLB quando cria o Objeto IStore3.. Utilizar CreateComObject de System.Win.ComObj.pas do delphi.. e consequentemente .dll do Windows, podendo ser BUG do Delphi mesmo ou do SO.
5. Qualquer aplicação pode utilizar Certificados.. Imagine um software mal intensionado que não tem a senha do A3, mas que utilize as .dll do capicom, e utilizando um comando para apagar o certificado? (sem senha, iria abrir a caixa de dialogo padrão, o usuário iria digitar manualmente a senha e o certificado já era).
Penso que existem muitas possibilidades a se considerar para resolver este problema.. Talvez algumas formas de tentar remediá-lo.
Penso que se o programador tem a possibilidade de conseguir excluír uma chave privada de um certificado.. Também deveria ter a possibilidade de se fazer um backup do mesmo.. Talvez extrai-lo para um .PFX e utiliza-lo como A1..
A JwaWinCrypt.pas do ACBrCapicom contém constantes e funcoes de exportação, não sei se é somente para as chaves públicas.. o fato é que estou pensando em sustituir a const "CRYPT_DELETEKEYSET = $00000010;" para um valor de leitura e compilar uma nova .dll somente para ter certeza que não é algo do ACBr/Capicom que está ocasionando tudo isso..
sei lá
