Problemas WinCrypt

Jonatas de Alencar Alves · 19 Setembro, 2017

Olá,

Muito bom!!!

Entendi a ideia, o "A3" após ser invocado permanece na memória aberto - independente se o objeto que o invocou for ou não destruído - com a senha informada inicialmente no Owner.

Funcionou aqui...

Desculpe minha ignorância, mas e se por algum motivo for necessário trocar a senha?

Vlw Adair, agora tenho apenas que aplicar esta regra.

Obs: Fiz os testes com revision 13882.

Haveria alguma forma de evitar que a instância do "A3" ficasse na memória?

Grato!

Adair Filho · 19 Setembro, 2017

Boa tarde Sr. Valdir dill. A Minha idéia foi a seguinte: Ter uma variavel (global) para saber se o campo ja foi preenchido no componente. A senha eu tenho o campo: TB_parametros.SENHACERT, e para saber se eu ja preenchi, eu fiz a variavel para receber apenas um "S" e nao entrar novamente para inserir os dados novamente. Minha ideia talvez mudando o nome da variavel fica mais facil de entender: VSENHADIGITADACERT para VSENHAPREENCHIDACERT . Mas até o presente momento tudo ok!

Adair Filho · 19 Setembro, 2017

Boa tarde @Jonatas de Alencar Alves , tudo bem? Eu tenho a senha salva no banco de dados.No Parametro, eu tenho a opcao de alterar a senha. Lembrando que a variavel que fiz é so para eu nao colocar novamente os dados no componente. Tentei a opcao de descarregar o certificado, e depois carregar o certificado, mas nao resolveu. Tudo isso ocorreu em clientes que tem o A3 de cartao.

Outra coisa que analisei, nao sei se é o caso, mas ocorreram defeito somente com os certificados A3 da SERASA. Tenho clientes que tem A3 de outra operadora, e nao teve problema, por isso houve demora na solucao do problema. Pois uns davam e outros nao. Mas hoje, interessante que colocamos essa observacao com a turma aqui e vimos isso! A3 da SERASA. Mas depois desta situacao que fizemos no programa de ler somente 1 vez, nao deu problema!

Jonatas de Alencar Alves · 19 Setembro, 2017

Olá,

os clientes aqui da empresa (na qual atuo), utilizam certificados "A3" de fornecedores diferentes: CertSign, Serasa e etc. E todos eles (não me lembro a quantidade exata) mencionaram o mesmo problema (Erro 12175).

Após aplicar as mudanças, fiz os testes utilizando um certificado "A3" da Certsign, e funcionou normalmente.

Agradeço muito @Adair Filho !!!!

Obs: Só para constar, passei a alimentar o campo <TACBrNFe>.SSL.Senha apenas uma vez, durante todo o ciclo de vida do form responsável pela emissão de NFC-e.

Caso este form seja fechado, é necessário preencher novamente a "Senha" no "ACBr".

Grato!

Editado 19 Setembro, 2017 por Jonatas de Alencar Alves
Faltaram algumas informações!

Marcelo_R · 22 Setembro, 2017

Bom dia,

@Adair Filho, ótima ideia, funcionou perfeitamente.

Eu sempre (re)carreguei o certificado a cada validação de nota, e isto começou a gerar o problema 12175, mas foi recentemente apenas.

Agora, controlando uma variável para carregar somente uma primeira vez, agilizou o processo e eliminou o erro.

Testei uma sequencia de 5 notas e foi tranquilamente. Lembro que na segunda em diante já dava o problema..

Obrigado a todos que contribuíram!

Marcelo

Editado 22 Setembro, 2017 por Marcelo_R

andre@prodez · 22 Setembro, 2017

Boa tarde a todos.

Também estou com problemas para emissão da NF-e em clientes com certificado A3 (erro relacionado a canal seguro) a partir da segunda Nota enviada (a primeira vai corretamente). Fechando a aplicação e abrindo novamente o ciclo se repete.

Ok sobre as alterações sugeridas com relação a alimentação da informação de senha no certificado.

No entanto, esse problema passou a ocorrer apenas após as atualizações do ACBr a partir de set/17; será que não é algum bug nessas versões novas do ACBr a partir de setembro, pois utilizando versões do meu aplicativo compiladas com o ACBr no início de agosto o problema não ocorre.

Alguém teria um retorno sobre isso?

Obrigado.

André Luis.

Lucas L. · 22 Setembro, 2017

1 hora atrás, andre@prodez disse:

Boa tarde a todos.

Também estou com problemas para emissão da NF-e em clientes com certificado A3 (erro relacionado a canal seguro) a partir da segunda Nota enviada (a primeira vai corretamente). Fechando a aplicação e abrindo novamente o ciclo se repete.

Ok sobre as alterações sugeridas com relação a alimentação da informação de senha no certificado.

No entanto, esse problema passou a ocorrer apenas após as atualizações do ACBr a partir de set/17; será que não é algum bug nessas versões novas do ACBr a partir de setembro, pois utilizando versões do meu aplicativo compiladas com o ACBr no início de agosto o problema não ocorre.

Alguém teria um retorno sobre isso?

Obrigado.

André Luis.

Boa Tarde!

Comecei a ter o mesmo problema após atualização também.Com versões anteriores do ACBr também não tinha esse problema. E como você mencionou só ocorre com certificados do tipo A3, e a partir da segunda Nota enviada ou consulta de status, ou manifestação e pelo menos nos testes que eu fiz, se remover o certificado e colocar novamente na leitora ou fechar e abrir o sistema, consigo emitir mais uma vez normalmente mas depois é retornado os erros:

Quando uso a capicom(loACBrNFe.Configuracoes.Geral.SSLLib := libCapicom):

-----------------------------------------------------------------------
Erro Interno: 12157
Erro HTTP: 0
Erro: Requisição não enviada.
Erro: 12157 - Erro relacionado ao Canal Seguro

-----------------------------------------------------------------------
-----------------------------------------------------------------------
Ou quando uso WinCrypt(loACBrNFe.Configuracoes.Geral.SSLLib := libWinCript):

Erro Interno: 12175
Erro HTTP: 0
Falha Recebendo Dados. Erro:Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor
-----------------------------------------------------------------------

Como alguns colegas sugeriam pode parecer que tem ficado algum memory leak que mantém o estado do ultimo certificado lido na store.

Outro fato relevante, é que o tratamento que os colegas sugeriam de passar a senha uma única vez para a certificado, afim de minimizar o impacto do erro já tinha um tratamento parecido internamente na classe ACBrDFeWinCrypt no método TDFeWinCrypt.CarregarCertificado, para que não criasse uma nova instancia do certificado e consequentemente não passasse tbm a senha novamente:

{...}
//Unity ACBrDFeWinCrypt Line 960 
if (FpDadosCertificado.Tipo = tpcA3) and
     (FpDFeSSL.Senha <> '') and
     (pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin) = 0) then  // Se Atribuir novamente em outra instância causa conflito... //
  begin
    try
      SetCertContextPassword(FpCertContext, FpDFeSSL.Senha);
      CertificadosA3ComPin := CertificadosA3ComPin + FpDadosCertificado.NumeroSerie + ',';
{...}

Depois no método TDFeWinCrypt.DescarregarCertificado, limpava da váriavelCertificadosA3ComPin o certificado instanciado;

{...}
//Unit ACBrDFeWinCrypt Line 1068
if (FpDadosCertificado.NumeroSerie <> '') then
   if (pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin) > 0) then
     CertificadosA3ComPin := StringReplace( CertificadosA3ComPin, FpDadosCertificado.NumeroSerie + ',', '', [rfReplaceAll]);
{...}

E nas linhas abaixo do método TDFeWinCrypt.DescarregarCertificado:

 // Limpando objetos da MS CryptoAPI //
  if Assigned(FpCertContext) then
    CertFreeCertificateContext(FpCertContext);

  if Assigned(FpStore) then
    CertCloseStore(FpStore, CERT_CLOSE_STORE_CHECK_FLAG);

  FpCertContext := Nil;
  FpStore := Nil;
  FpPFXData := '';

Todos objetos relacionados a criação da instância do certificado são "destruídos", mas ainda sim fica algo em memória que mantém o estado do certificado.

Então teoricamente depois de todos esses tratamentos não era pra ocorrer esse memory leak, pois também trabalho com o componente ACBrNFe em tempo de execução e destruo o mesmo com FreeAndNil logo após de utiliza-lo.

Se mais alguém tiver informações ou idéias de como evitar esse problema seria muito bom ou até mesmo esclarecendo se trata de alguma restrição(limitação/segurança) das dll's de criptografia e acesso ao certificado.
Pois no meu caso é muito comum os clientes, principalmente os de NF-e terem um único leitor e alternarem os cartões com o certificado digital de acordo com a filial que eles desejam emitir notas, realizar manifestação etc... e quando o certificado e desconectado é reconectado eu tenho necessidade de informar a senha novamente.E caso eu opte pela opção de nunca informar a senha e deixar o próprio manager do certificado pedir a senha além de alguns usuários taxarem de inconveniente, aumenta muito a chance do usuário informar uma senha errada e bloquear o certificado.

Att, agradeço por toda ajuda recebida e pelos esforços de toda equipe do ACBr.

Editado 22 Setembro, 2017 por Lucas L.

Daniel Simoes · 22 Setembro, 2017

Qual é exatamente o passo a passo, para reproduzir o problema, usando o Demo do ACBrNFe ?

Valdir Dill · 22 Setembro, 2017

Boa tarde,

Bem, em primeiro lugar é preciso salientar que o problema só ocorre com certificados A3 SERASA. Pelo menos comigo foi assim.

1 - AcbreNFe1.Configuracoes.Geral.SSLLiB = Wincrypt
2 - AcbreNFe1.SSL.Senha := '123456'
3 - Enviar uma nota
4 - Sem sair do sistema, repetir passos 2 e 3. Ao tentar enviar a segunda nota, dá o erro.

Observações:
1 - Se não informar a senha para o componente nenhuma vez (passo 2), aí quando vai enviar a nota, será aberta a tela do PIN (só pede a primeira vez), informa-se a senha normalmente e o erro não ocorre;

2 - No passo 2 acima, se mudar para "if AcbreNFe1.SSL.Senha <> emptyStr then AcbreNFe1.SSL.Senha := '123456'", aí o erro não ocorre, ou seja, se não atribuir a senha uma segunda vez ao componente, aí o erro também não ocorre.

Obrigado

Lucas L. · 22 Setembro, 2017

42 minutos atrás, Daniel Simoes disse:

Qual é exatamente o passo a passo, para reproduzir o problema, usando o Demo do ACBrNFe ?

Daniel, como no demo ACBr o componente ACBrNFe é utilizado em design para todas as funções e a senha é passado somente no create do formulário e/ou ao salvar uma configuração, não é comum ocorrer o erro. Mas se alterar o método de consultar status para utilizar um componente em tempo de execução, e toda vez setar a senha no componente é gerado o erro.

procedure TForm1.btnStatusServClick(Sender: TObject);
var
  loACBR: TACBrNFe;
  ok:Boolean;
begin
    loACBR := TACBRNFe.Create(nil);
    try
       loACBR.Configuracoes.Certificados.Senha       := edtSenha.Text;
       loACBR.Configuracoes.Certificados.NumeroSerie := edtNumSerie.Text;
       with loACBR.Configuracoes.Geral do
       begin
         SSLLib                := TSSLLib(cbSSLLib.ItemIndex);
         SSLCryptLib           := TSSLCryptLib(cbCryptLib.ItemIndex);
         SSLHttpLib            := TSSLHttpLib(cbHttpLib.ItemIndex);
         SSLXmlSignLib         := TSSLXmlSignLib(cbXmlSignLib.ItemIndex);
         AtualizaSSLLibsCombo;
         ExibirErroSchema := cbxExibirErroSchema.Checked;
         RetirarAcentos   := cbxRetirarAcentos.Checked;
         FormatoAlerta    := edtFormatoAlerta.Text;
         FormaEmissao     := TpcnTipoEmissao(cbFormaEmissao.ItemIndex);
         ModeloDF         := TpcnModeloDF(cbModeloDF.ItemIndex);
         VersaoDF         := TpcnVersaoDF(cbVersaoDF.ItemIndex);
         IdCSC            := edtIdToken.Text;
         CSC              := edtToken.Text;
         Salvar           := ckSalvar.Checked;
       end;


       with loACBR.Configuracoes.WebServices do
       begin
         UF         := cbUF.Text;
         Ambiente   := StrToTpAmb(Ok,IntToStr(rgTipoAmb.ItemIndex+1));
         Visualizar := cbxVisualizar.Checked;
         Salvar     := cbxSalvarSOAP.Checked;
         AjustaAguardaConsultaRet := cbxAjustarAut.Checked;
         if NaoEstaVazio(edtAguardar.Text)then
            AguardarConsultaRet := ifThen(StrToInt(edtAguardar.Text)<1000,StrToInt(edtAguardar.Text)*1000,StrToInt(edtAguardar.Text))
         else
            edtAguardar.Text := IntToStr(AguardarConsultaRet);

         if NaoEstaVazio(edtTentativas.Text) then
            Tentativas          := StrToInt(edtTentativas.Text)
         else
            edtTentativas.Text := IntToStr(Tentativas);

         if NaoEstaVazio(edtIntervalo.Text) then
            IntervaloTentativas := ifThen(StrToInt(edtIntervalo.Text)<1000,StrToInt(edtIntervalo.Text)*1000,StrToInt(edtIntervalo.Text))
         else
            edtIntervalo.Text := IntToStr(loACBR.Configuracoes.WebServices.IntervaloTentativas);

         TimeOut := seTimeOut.Value;
         ProxyHost := edtProxyHost.Text;
         ProxyPort := edtProxyPorta.Text;
         ProxyUser := edtProxyUser.Text;
         ProxyPass := edtProxySenha.Text;
       end;

      loACBR.SSL.SSLType := TSSLType( cbSSLType.ItemIndex );

      with loACBR.Configuracoes.Arquivos do
       begin
         Salvar             := cbxSalvarArqs.Checked;
         SepararPorMes      := cbxPastaMensal.Checked;
         AdicionarLiteral   := cbxAdicionaLiteral.Checked;
         EmissaoPathNFe     := cbxEmissaoPathNFe.Checked;
         SalvarEvento       := cbxSalvaPathEvento.Checked;
         SepararPorCNPJ     := cbxSepararPorCNPJ.Checked;
         SepararPorModelo   := cbxSepararPorModelo.Checked;
         PathSalvar         := edtPathLogs.Text;
         PathSchemas        := edtPathSchemas.Text;
         PathNFe            := edtPathNFe.Text;
         PathInu            := edtPathInu.Text;
         PathEvento         := edtPathEvento.Text;
       end;

        loACBR.WebServices.StatusServico.Executar;

        MemoResp.Lines.Text := loACBR.WebServices.StatusServico.RetWS;
        memoRespWS.Lines.Text := loACBR.WebServices.StatusServico.RetornoWS;
        LoadXML(loACBR.WebServices.StatusServico.RetornoWS, WBResposta);

        pgRespostas.ActivePageIndex := 1;

        MemoDados.Lines.Add('');
        MemoDados.Lines.Add('Status Serviço');
        MemoDados.Lines.Add('tpAmb: '    +TpAmbToStr(loACBR.WebServices.StatusServico.tpAmb));
        MemoDados.Lines.Add('verAplic: ' +loACBR.WebServices.StatusServico.verAplic);
        MemoDados.Lines.Add('cStat: '    +IntToStr(loACBR.WebServices.StatusServico.cStat));
        MemoDados.Lines.Add('xMotivo: '  +loACBR.WebServices.StatusServico.xMotivo);
        MemoDados.Lines.Add('cUF: '      +IntToStr(loACBR.WebServices.StatusServico.cUF));
        MemoDados.Lines.Add('dhRecbto: ' +DateTimeToStr(loACBR.WebServices.StatusServico.dhRecbto));
        MemoDados.Lines.Add('tMed: '     +IntToStr(loACBR.WebServices.StatusServico.TMed));
        MemoDados.Lines.Add('dhRetorno: '+DateTimeToStr(loACBR.WebServices.StatusServico.dhRetorno));
        MemoDados.Lines.Add('xObs: '     +loACBR.WebServices.StatusServico.xObs);

    finally
       FreeAndNil(loACBR)
    end;
end;

Obs: Nos meus testes utilizei um certificado A3 SPC Brasil. Site Fabricante

Att, Lucas

Editado 22 Setembro, 2017 por Lucas L.

Daniel Simoes · 22 Setembro, 2017

38 minutos atrás, valdirdill disse:

o informar a senha para o componente nenhuma vez (passo 2), aí quando vai enviar a nota, será aberta a tela do PIN (só pede a primeira vez), informa-se a senha normalmente e o erro não ocorre;

2 - No passo 2 acima, se mudar para "if AcbreNFe1.SSL.Senha <> emptyStr then AcbreNFe1.SSL.Senha := '123456'", aí o erro não ocorre, ou seja, se não atribuir a senha uma segunda vez ao componente, aí o erro também não ocorre.

Obrigado

Obrigado pelas informações... Acho que notei o problema... quando a Senha é atribuída, o certificado é descarregado...

procedure TDFeSSL.SetSenha(AValue: AnsiString);
begin
  if (FK <> '') and (FSenha = StrCrypt(AValue, FK)) then
    Exit;

  FK := FormatDateTime('hhnnsszzz',Now);
  FSenha := StrCrypt(AValue, FK);  // Salva Senha de forma Criptografada, para evitar "Inspect"

  if CertificadoLido then
    DescarregarCertificado;
end;

Estou avaliando uma correção, para esse cenário...

Daniel Simoes · 22 Setembro, 2017

O Método:

procedure TDFeSSL.SetSenha(AValue: AnsiString);

parece estar funcionando corretamente...

Não consegui reproduzir o problema... por favor crie, e anexe, um aplicação simples, onde o problema ocorra...

Agnaldo Prates · 23 Setembro, 2017

Não estou tendo problemas nem com certificados A3 ou A1, certificadoras diversas inclusive da SERASA. Porém, chamo o selecionar certificado apenas uma vez, atribuo o número de série apenas uma vez, inclusive a senha no caso do A1, para o A3, não atribuo nenhuma senha, isso quem faz é o app da certificadora.

Me parece que, se for informado a senha para o A3, não vai funcionar, visto que a mesma é validada apenas se digitada ao solicita o PIN.

Editado 23 Setembro, 2017 por Agnaldo Prates

Valdir Dill · 23 Setembro, 2017

1 minuto atrás, Agnaldo Prates disse:

Não estou tendo problemas nem com certificados A3 ou A1, certificadoras diversas inclusive da SERASA. Porém, chamo o selecionar certificado apenas uma vez, atribuo o número de série apenas uma vez, inclusive a senha no caso do A1, para o A3, não atribuo nenhuma senha, isso quem faz é o app da certificadora.

Me parece que, se for informado a senha para o A3, não vai funcionar, visto que a mesma é validada apenas se digitada ao solicita o PIN.

Bom dia,

Funciona sim Agnaldo, basta não atribuir a senha ao componente Acbr na segunda vez que for usá-lo. Mas só acontece com SERASA. Isso é certeza, pois fiz dezenas e dezenas de testes com outros certificados e não ocorre. Com SERASA, fiz dezenas e dezenas de testes e, se atribuir a vez segunda a senha ao componente antes a aplicação ser encerrada, dá o erro ao usar qualquer operação do Acbr que chame o certificado. E nem adianta destruir/recriar o componente Acbr, vai dar erro igual. Acho que o certificado controla isso da aplicação que o chamou e não pelo componente Acbr. Prova disso é que quando não se alimenta a senha no componente, a tela do PIN é chamada uma única vez pelo gerenciador do certificado (isso já vale para qualquer certificado A3).

Eu fiz da seguinte forma e e está funcionando 100% em vários clientes que antes (quando eu atribuía a senha na segunda vez) não funcionava:

1) No onCreate do DataModule (que é onde está meu componente):
- ACBRNFe1.tag := 0; //atribuo 0 só para garantir, pois 0 já é o default.
Obs.:
a) O DM é criado somente uma vez durante toda aplicação;
Não, não adianta criar o DM dinamicamente e destruí-lo depois. Como mencionei acima, o certificado faz algum tipo de controle pela aplicação que o chama.

2) Ao iniciar qualquer procedimento do Acbr que necessitará do certificado:
a) if ACBRNFe1.tag = 10 then exit;

try
b) ACBRNFe1.SSL.Senha := TBDadosCertif.FieldByName('SenhaCert').asString;
c) Configuracoes.Geral.SSLLib := libWinCrypt;
n) ...;
y) ACBRNFe1.SSL.CarregarCertificado;
z) ACBRNFe1.tag := 10;
except
ACBRNFe1.tag := 0;
end;

Funciona perfeito. Mas, se o item 2 b for executado uma segunda vez pela aplicação, e se tentar assinar um XML, por exemplo, vai dar o erro se o certificado vinculado for A3 SERASA.

Abraços.

Lucas L. · 25 Setembro, 2017

Em 22/09/2017 at 18:35, Daniel Simoes disse:
O Método:
procedure TDFeSSL.SetSenha(AValue: AnsiString);
parece estar funcionando corretamente...

Não consegui reproduzir o problema... por favor crie, e anexe, um aplicação simples, onde o problema ocorra...

Olá @Daniel Simoes, bom dia! Segue em anexo um exemplo simplificado do cenário de como pode emular o erro, pra quando você puder der uma olhada por favor.

1º Setar os parâmetros de configurações do ACBrNFe(Certificado, Schemas, Criptografia)
2º Consultar Status
3º Quando tentar a Consultar o Status pela 2ª vez irá ocorrer o erro.

Caso desconecte / conecte o cartão da leitora ou feche e abra a aplicação irá funcionar mais uma vez.

Caso precise realizar mais alguns testes, só avisar!

Muito Obrigado.

Att, Lucas

ErroCanaisSeguros.rar

Daniel Simoes · 25 Setembro, 2017

Obrigado pelo Projeto de Demonstração...

Não consegui reproduzir o problema, com o seu projeto e meu certificado A3, da Certisign... mas conforme dito aqui no tópico, o problema parece estar relacionado a apenas algumas marcas de certificado...

Analisando código antigo do ACBr.. o que notei, é que a variável Global "CertificadosA3ComPin"que atua como um "cache" de quais Certificados o PIN já foi atribuído, somente era zerada, no "finalization" da Unit... portanto.. teste a seguinte modificação, comentando o código a seguir:

procedure TDFeWinCrypt.DescarregarCertificado;
begin
{  if (FpDadosCertificado.NumeroSerie <> '') then
   if (pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin) > 0) then
     CertificadosA3ComPin := StringReplace( CertificadosA3ComPin, FpDadosCertificado.NumeroSerie + ',', '', [rfReplaceAll]);
}

Lucas L. · 25 Setembro, 2017

Por nada, somos os maiores interessados.Eu que agradeço.

Ao comentar o código não dá erro ao consultar mais de uma vez.Mas caso eu desconecte o certificado e conecto ele de novo ele abre o manager do certificado, solicitando senha.

Daniel Simoes · 25 Setembro, 2017

Isso pode não ter solução...

Tente o seguinte código abaixo... A ideia é tentar limpar o cache do PIN, quando descarregar o certificado...

procedure TDFeWinCrypt.DescarregarCertificado;
begin
  if (FpDadosCertificado.NumeroSerie <> '') then
   if (pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin) > 0) then
   begin
     SetCertContextPassword( FpCertContext, '' );
     CertificadosA3ComPin := StringReplace( CertificadosA3ComPin, FpDadosCertificado.NumeroSerie + ',', '', [rfReplaceAll]);
   end;

Nos meus testes, isso não funcionou... (mas também não atrapalhou)... a chamada do método, abaixo, com uma Senha vazia...

      if CryptSetProvParam(ProviderOrKeyHandle, PP_KEYEXCHANGE_PIN, PBYTE(APass), 0) then

...Retornava o erro: $80090005 = NTE_BAD_DATA

Leia também, esse tópico... relacionado ao Cache de PIN e assinatura digital...

Lucas L. · 25 Setembro, 2017

Obrigado Daniel.

Ao tentar o código:

procedure TDFeWinCrypt.DescarregarCertificado;
begin
  if (FpDadosCertificado.NumeroSerie <> '') then
   if (pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin) > 0) then
   begin
     SetCertContextPassword( FpCertContext, '' );
     CertificadosA3ComPin := StringReplace( CertificadosA3ComPin, FpDadosCertificado.NumeroSerie + ',', '', [rfReplaceAll]);
   end;

Voltou a ocorrer o erro de canais seguros. E como eliminar 100% o manager de senha do certificado digital é quase impossível.

A melhor alternativa é comentar o código abaixo, como você sugeriu :

Citar


procedure TDFeWinCrypt.DescarregarCertificado;
begin
{  if (FpDadosCertificado.NumeroSerie <> '') then
   if (pos(FpDadosCertificado.NumeroSerie, CertificadosA3ComPin) > 0) then
     CertificadosA3ComPin := StringReplace( CertificadosA3ComPin, FpDadosCertificado.NumeroSerie + ',', '', [rfReplaceAll]);
}

E só pra esclarecer, comentar esse código pode ser prejudicial em algum outro cenário(que você se lembre), assim como sugerido no post que você indicou? Principalmente se eu usar um certificado A3 de outra certificadora?

De todo jeito irei fazer mais testes, e qualquer novidade posto aqui! ; )

Mas uma vez, obrigado a todos!

Att, Lucas L.

Editado 25 Setembro, 2017 por Lucas L.

andre@prodez · 26 Setembro, 2017

Bom dia a todos.

Daniel, só para entender, o problema que estamos relatando (erro de canal seguro a partir da 2a NF-e com cert. A3 - no caso do meu cliente certificado da Valid) passou a ocorrer após o ajuste:

"Correção para remover o numero de Série do Certificado, de "CertificadosA3ComPin",
quando Descarregar o Certificado."

Conforme o post que vc citou, é isso mesmo?

Nesse caso, comentar as linhas que vc mencionou seria publicado no SVN? Isso não irá gerar problemas ref. o post citado?

Será que seria possível um parâmetro?

Aguardando retorno, desde já obrigado a todos.

André Luis.

Daniel Simoes · 26 Setembro, 2017

Sim, provavelmente o problema do outro tópico, voltaria a ocorrer... estou imaginando uma solução "pacificadora"...

andre@prodez · 28 Setembro, 2017

Bom dia Daniel.

Uma dúvida.

No meu caso eu ainda utilizo a lib Capicom para comunicação com o certificado. E reparei que a DescarregarCertificado que está mencionando comentar as linhas é da WinCrypt.

Mesmo assim ocorre comigo o problema com canais seguros conforme já descrito. É isso mesmo, deveria ocorrer tb o erro mesmo na Capicom?

O método DescarregarCertificado da unit ACBrDFeSSL dispara a chamada para o método na unit ACBrDFeWinCrypt?

Obs.: tentei rastrear o código e verifiquei que ocorre em diversas vezes a chamada a esse método DescarregarCertificado, tornando complexo o uso de um parâmetro no método; não sei, talvez o uso de uma variável de classe com valor padrão (flag). Enfim, não tenho a mesma dimensão que vc dos fontes.

Aguardando novidades, obrigado.

André Luis.

Daniel Simoes · 28 Setembro, 2017

Veja nos fontes:

  TDFeCapicom = class(TDFeWinCrypt)

ou Seja... por herança a classe da Capicom é filha da WinCrypt... e reimplementa apenas alguns métodos...

diogeneswinner · 6 Outubro, 2017

Em 14/08/2017 at 15:15, Diego Henicka disse:

Boa tarde, estou tendo o mesmo problema para emitir NFSe para a cidade de João Pessoa/Paraiba, ja segui as dicas, estou utilizando já a versão com WinCrypt sem precisar da capcon. Testei as diversas configurações da SSLType e nada, testei na minha máquina e na maquina do cliente mesmo erro. Funciona na versão antiga tendo que registrar a Capcon, alguem tem alguma dica. Agradeço. Segue configurações:

ACBrNFSe1.Configuracoes.Geral.SSLLib := libWinCrypt;

ACBrNFSe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt;
ACBrNFSe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp;
ACBrNFSe1.Configuracoes.Geral.SSLXmlSignLib := xsMsXml;

ACBrNFSe1.SSL.SSLType := LT_all;

Oi amigo conseguiu resolver este problema?, uso o windows 7 e da esse mesmo erro, com estas mesmas configuracoes.

Diego Henicka · 6 Outubro, 2017

4 horas atrás, diogeneswinner disse:

Oi amigo conseguiu resolver este problema?, uso o windows 7 e da esse mesmo erro, com estas mesmas configuracoes.

Boa tarde, ainda não, a solução foi deixar o cliente rodando com a Capcon

Entrar

Sobre nós...

Problemas WinCrypt

Recommended Posts

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Adair Filho

Daniel Simoes

Diego Henicka

Sobre nós...

Informação Importante