Novo projeto

[fladimir]

Testei em uma outra maquina sem o ACBr funcionou

Desativei (fechei o programa) do ACBr da minha maquina q estava testando e refiz os testes e funcinou.

Agora a diferença é q 1 é 32 e outra 64

A 32 é XP e a 64 Windows 7

Acredito q não seja o ACBr pq mesmo desativado da o problema

Creio q esteja mais pra SO, agora novamente o q? Versoes Dlls especificas? Se sim pq o ACBr funciona, não teria q o projeto tb funcionar?

[JoséQuintas]

Porque ACBR funciona?
Talvez ele acesse as DLLs por 64 bits, e justamente por elas entrarem como 64 bits não funcionem em 32 bits.
E se for isso, resta saber se pelo ACBR vai funcionar por 32 bits.

Então na máquina 64 bits, deixar as DLLs apenas como 32 bits, o que na verdade elas são.
Detalhe: a DLL tem que estar acessível também pra "des-registrar, e tem que usar o regsvr32.exe correto.

cd \Windows\system32
regsvr32 /u capicom.dll
regsvr32 /u msxml5.dll

cd \Windows\syswow64
regsvr32 /u capicom.dll
regsvr32 /u msxml5.dll

regsvr32 capicom.dll
regsvr32 msxml5.dll

Só pra lembrar:
não tem a ver com as pastas aonde estão as dlls, e sim com o regsvr32.exe. Não existe regsvr64.exe, mas existem 2 regsvr32.exe.
\Windows\system32\regsvr32.exe
\Windows\syswow64\regsvr32.exe

A pasta \Windows\system32 não é 32 bits, é apenas um nome default, portanto em 64 bits tem componentes 64 bits
A pasta \Windows\syswow64 não é 64 bits, tem componentes 32 bits

[JoséQuintas]

Encontrei sobre abrir o repositório de certificados como somente leitura, ou leitura/gravação.

Por enquanto só imagino duas hipóteses:
- O que mencionei de carregar como 64 bits impedir carregar como 32 bits
- Uma abertura por parte do ACBR como modo não compartilhado, deixando o acesso pelo ACBR sempre instantâneo, mas impedindo o uso por outro aplicativo

Inclusive, por via das dúvidas, alterei a seleção do certificado pra usar modo somente leitura.
Seria um ponto a observar nos fontes do ACBR, se ele faz isso também. Poderia ser um motivo de bloqueio (considerando bloqueio como hipótese).

[fladimir]

Descobri!!!!

Funcionou!!!!

Eu tinha na minha maquina W7 64 2 certificados de mesmo nome instalados, porém de validades diferentes 1 era do ano passado e outro desse ano.

Ai o ACBr consegue distinguir mas o projeto não, talvez pq pegue pelo nome o certificado não sei.

Na maquina virtual 1 funcionou pq não tinha certificado e eu instalei somente o valido (vencimento 2016) ai funcionou.

Pra tirar a prova fui na outra maquina virtual XP 32 bits q não tinha funcionado tb e fui ver tinha 2 certificados instalados, mesmo eu escolhendo o CERTIFICADO CORRETO não funciona, tem q excluir o certificado velho pra funcionar.

Podiamos ver isso no projeto se tem como fazer ficar igual ao ACBr, ou seja, se escolhi o correto independente de ter outro VENCIDO de mesmo nome ir pelo q eu escolhi q não esta vencido.

Legal, agora vou dar continuidade.

Obrigado pela força José

[JoséQuintas]

Encontrei isto:

http://balaiotecnologico.blogspot.com.br/2009/07/acessando-o-certificate-store-do.html

que chamou a atenção nesta parte:

A função Close do Store tem que ser chamada quando não for mais usar o Store ou se for necessário reabrí-lo para acessar outro conjunto de certificados.

Não sei se isso se restringe ao aplicativo.

Inclusive eu também não estava fazendo isso, o close().
Isso não altera o problema em questão, mas pode evitar algum.

[fladimir]

vou dar continuidade aki na migração de ACBr para o projeto novo do hbNFe e depois q terminar volto a testar isso pq tenho o outro certificado velho ai instalo e ele e já q sabemos onde é o problema tentamos resolver pra ficar mais redondinha a classe.

Agora se vc tiver um certificado de mesmo nome vencido ai já pode ir vendo caso queira.

Vlw José, qualquer coisa posto aki novamente.

[]´s

[JoséQuintas]

Rotina CapicomCertificado() é a que pega o certificado.
Incluir lá a checagem de validade.
Na atual pega o primeiro que encontrar com mesmo nome, sem verificar validade.

[JoséQuintas]

OK, inclui um IF na rotina.

         IF oColecao:Item( nCont ):ValidToDate >= Date()
            oCertificado := oColecao:Item( nCont )
         ENDIF

E um alerta, pelo menos na assinatura

   oCert:= CapicomCertificado( cCertCn )
   IF oCert == NIL
      cRetorno := "Erro Assinatura: Certificado não encontrado ou vencido"
      RETURN cRetorno
   ENDIF

É só uma ajuda.
No webservice é passado o nome, e a seleção é fora da classe.
Não sei como o ACBR teria controle nisso.

[fladimir]

Legal vou testar

[fladimir]

Coloquei as alterações e testei mas se deixo 1 certificado vencido e 1 válido (não vencido) não funciona.

O ACBrNFeMonitor qdo escolhemos o certificado ele mostra o Serial.

Será q não tem como setar o certificado pelo Serial ao invés do Nome?

Outro detalhe q achei estranho, no Método MicrosoftXMLSoapPost na linha

         oServer:setOption( 3, "CURRENT_USER\MY\" + ::cCertificado )

a propriedade ::cCertificado esta VAZIA = ""

nem sei se tem a ver, somente me chamou a atenção.

Tentei forçar a passagem de algum conteúdo seja, Serial ou Nome do certificado mas o erro permanece, ou seja, ::cCertificado pode ter conteúdo ou não q aparentemente não faz diferença
Se se deixo instalados os 2 certificados continua o erro, se removo o vencido funciona e em qualquer 1 dos testes (com certificado vencido ou não) fica VAZIO a propriedade ::cCertificado na linha em questão

Mas acho q temos q mudar algo antes só não sei o q ainda, estou pesquisando.

Mas acho SUPER importante corrigir isto pq no dia a dia em campo na carteira de cliente os clientes vão atualizando seus certificados e vão ter na maquina certificados VENCIDOS e VALIDOS e isto pode dar problema como verifiquei, só fico com uma dúvida, tem colegas q usam esta classe a mais de anos será q não tiveram os mesmos problemas nos clientes deles em campo?

Pq depois q identifiquei o problema e removi o certificado vencido a classe original do hbNFe tb esta funcionando o exemplo de testes q eu havia comentado q tb estava tendo problemas em outros tópicos.

[JoséQuintas]

Com a alteração que fiz, ao selecionar certificado vencido ele não é aceito, por isso o nome fica em branco.

Ainda não encontrei solução.
Fica a cargo do usuário excluir certificados vencidos, o que ocorre uma vez por ano.

Uma rotina pode ser usada pra avisar sobre certificados vencidos a serem excluídos.
A própria seleção de certificados serve como base.
Aliás... quem instalar um certificado novo já pode aproveitar e excluir os antigos, é isso que costumo fazer.

Talvez alguém que conheça Delphi consiga decifrar o enigma olhando os fontes do ACBR.

Por enquanto removi a alteração, e fixei o xmlhttp pra 6.0, pra ver se faz diferença.

[JoséQuintas]

Achei algo.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa388120(v=vs.85).aspx

Retrieves the name of the certificate store that this object represents.

CAPICOM 2.0.0.3 and earlier: The Name property is not supported.

Agora falta encontrar documentação pra esse recurso.
A partir daí, ao invés de indicar o CN, seria indicar diretamente o nome.

[JoséQuintas]

Nada feito.
Caso abra o repositório "My", o novo recurso vai retornar "My".
deve servir pra alguma coisa... sei lá... talvez pra fazer o caminho inverso de onde veio...

[JoséQuintas]

Até abri a capicom no VB6, pra ver tudo que tem disponível, mas nada que ajude.

[fladimir]

Blz José, obrigado, já valeu a nível de conhecimento e pelo menos agora posso tocar o barco.

Fora isso pegando tua sugestão poderia ser feito algo a nível de uma rotina q pegasse os certificados instalados e repassasse 1 a 1 e os vencidos perguntar se exclui ou algo do tipo, porém essa questão de excluir o certificado (REMOVER) via programação teria q pesquisar, mas isso é assunto pra outra hora.

No mais vamos continuar.

[]´s