Active.Matheus

Bom dia Daniel. Concordo sobre o A3, mas infelizmente isso não é algo que possamos ignorar, sendo que é uma opção disponível no mercado e nossos clientes escolhem o certificado que acham mais conveniente. Sobre atualização do software do certificado, já foi feito e não resolveu. Sobre atualização do windows, também concordo com você, mas infelizmente isso é algo que não podemos fazer, dependemos da TI do cliente, e não temos um bom motivo para solicitar isso, sendo que o nosso software, numa versão mais antiga, compilada com Delphi XE8 e o ACBr um pouco mais antigo, funciona normalmente no mesmo ambiente. E também o Demo do ACBR, compilado com o mesmo Delphi atualizado (Delphi Rio) e o ACBr atualizado, funciona normalmente com o mesmo ambiente. Acredito que temos algo no nosso sistema, que talvez tenha mudado entre uma versão e outra, que possa estar conflitando, ou até mesmo o fato da versão do Delphi e o ACBr ser mais recente, estar exigindo algo a mais ou alguma atualização a mais que não conseguimos identificar. Se você ou mais alguém tiver outras sugestões, agradecemos, pois já estamos ficando sem opções para testar, e estamos em vias de ter um grande problema com relação a isso, pois por exemplo, a MDFe está com novas obrigações que já estão implementadas na versão atual de nosso sistema, que não funciona com A3, e a versão antiga que está funcionando, não possui estas implementações, e não gostaríamos de ter que alterar os fontes da versão antiga para implementar as obrigações (retrabalho) Muito obrigado pela atenção de todos, e continuaremos tentando aqui. Em tempo, fiz uma solicitação de uma consultoria mais pessoal em uma das mensagens anteriores nessa thread, não tivemos uma resposta sobre isso. Se for possível, vamos conversar sobre isso.

Dlls do openssl e libxml2 atualizadas estão na pasta do exe, e a capicom instalada normalmente pra ser usada tb, nas pastas corretas. O erro ocorre na seguinte linha do ACBr, unit: ACBrWinHTTPReqResp: if not WinHttpSendRequest( fRequest, LPCWSTR(wHeader), Length(wHeader), WINHTTP_NO_REQUEST_DATA, 0, Length(Self.Data), 0) then begin UpdateErrorCodes(fRequest); raise EACBrWinReqResp.Create('Falha no Envio da Requisição.'+sLineBreak+ GetWinInetError(FpInternalErrorCode)); end; Na ACBrWinINetReqResp, o erro ocorre aqui: if HttpSendRequest(fRequest, nil, 0, Pointer(Data), Length(Data)) then não retorna True, e cai nessa condição: if not OK then begin //DEBUG //WriteToTXT('c:\temp\httpreqresp.log', FormatDateTime('hh:nn:ss:zzz', Now)+ // ' - Erro WinNetAPI: '+IntToStr(InternalErrorCode)+' HTTP: '+IntToStr(HTTPResultCode)); raise EACBrWinReqResp.Create('Erro: Requisição não enviada.' + sLineBreak + GetWinInetError(InternalErrorCode)); end;

Boa tarde Juliomar, tudo bem? Bom, já revisamos tudo, comparamos os métodos que configuram o componente ACbrCTe, entre o Demo e o nosso sistema, e estão iguais, mas nosso sistema ainda não consegue completar a comunicação com a Sefaz, tanto na Capicom, quanto na Wincrypt. E o nosso mesmo sistema, que foi compilado com Delphi XE8, e um ACbr mais antigo, funciona sem nenhum problema. Gostaria de saber se você da algum tipo de consultoria para nos ajudar a identificar onde está o problema, ou se você indica alguém que possa fazer esse serviço, analisar o código do nosso sistema, ambiente, o próprio ACBr, etc. Estamos em Guarulhos. No aguardo Obrigado.

Não, usando o nosso sistema, tivemos essas duas situações... conseguimos assinar o XML usando o A3, e conseguimos enviar um Cte, mas no meio do processo, apos o erro, tive que entrar no Internet Explorer, forçar um acesso ao site da Sefaz para solicitar o certificado e o PIN, e apos isso, o envio foi concluído. Com o exemplo não tivemos nenhum problema, ele sempre comunica.

Atualização: Conseguimos testar o A3 pra assinar, e deu certo, ele solicita o PIN qdo necessário de boa. Só ocorre erro quando tenta se comunicar com a Sefaz.

Bom dia Juliomar, td bem? O que vc disse faz sentido sim, nosso sistema tem muitas funções, é bem complexo, acredito que possa ter algo que se enquadre nessa situação que vc comentou... o problema é que a causa for essa, não podemos mudar isso. Nosso maior problema é que temos uma versão deste sistema, que foi compilada em Delphi XE8, ano passado, ela funciona bem com o A3.. depois que migramos para o Delphi RIO 10.3, começaram a surgir esses conflitos. E agora chegamos num ponto onde precisamos atualizar os envios de CTe e MDFe com novas regras do governo, e a versão do ano passado não contempla essas regras, e não podemos simplesmente voltar para o Delphi XE8, pois teriamos outros transtornos. A nossa esperança era que outros usuários que tb usam o ACBr pudessem ter tido algum problema semelhante, para compatilharmos informações e achar essa solução. Em um dos ultimos testes q fiz, segui uma dica baseada neste link: Onde o cara comenta que qdo da o erro, abre outro programa que peça o PIN, e depois disso tudo funciona. FIz o mesmo teste abrindo o Internet Explorer, entrando no site da sefaz para solicitar o certificado e o PIN, e após isso, o sistema envia o CTe. Pelo jeito tem algo (provavelmente o bradesco), que ta impedindo o sistema de se comunicar com o software do A3. O software do A3 está atualizado, com a ultima versão baixada do site do Serasa.

Então, como disse, os parâmetros estão idênticos nos dois projetos... no Demo do ACBr funciona com Capicom e Wincrypt de boa, mas no software não... e quando removemos o componente de segurança Bradesco, funciona também no software. Porque que o Bradesco travaria meu software, e não trava o demo do Acbr, se ambos estão tentando fazer a mesma coisa?

Boa tarde Juliomar, Fiz o teste, usando um certificado de SPC criado aqui por nós usando as ferramentas de SDK do Windows, apenas para testar antes de comprar um certificado, porem o resultado ainda continua o mesmo. Executei o Demo do ACBr para CTe, e funciona, nos deixando ainda mais intrigados. Conferimos os parâmetros do objeto ACBRCte em ambos os projetos e estão idênticos. E o Demo nem é assinado. Estamos deixando o campo de senha em branco, pra forçar que o software do certificado peça o PIN, porem nem ocorre isso, ele fica um tempo aguardando e depois retorna o erro 12186. Quando escolhemos um certificado A1 que esteja instalado na maquina (pra ter o mesmo comportamento do A3, usando pelo numero de série, ao invés do PFX), funciona normalmente. Alguma outra sugestão?

Mais uma duvida, posso usar um Certificado eCNPJ pra fazer essa assinatura? Ou existe um específico?

boa tarde Não é assinado, mas é uma boa sugestão... vamos fazer o teste com isso Assim que testar posto aqui o resultado Obrigado.

Bom dia, estou tendo esse erro ao tentar enviar CTe ou MDFe para a Sefaz, somente usando certificado A3: Verifique suas configurações de internet WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 12186 Erro HTTP: 0 URL: https://nfe.fazenda.sp.gov.br/cteWEB/services/cteStatusServico.asmx Falha no Envio da Requisição. Erro: 12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura Fizemos vários testes, seguimos as recomendações deste link, sem sucesso: Ai depois de pesquisarmos alguns sites no google, encontramos um que estava comentando sobre um possível problema com o componente de segurança WARSAW, ou DIEBOLD... ai começamos a investigar por essa linha, e descobrimos que os nossos clientes que estão tendo este problema coincidentemente usam o navegador Bradesco Exclusivo, que instala um componente de segurança parecido com esse WARSAW. Fizemos um teste removendo o navegador e o componente de segurança, e passou a funcionar. Alguém por acaso sabe se existe uma forma em que poderíamos manter o componente de segurança (pois o cliente precisa usar o Bradesco), e ainda sim obter sucesso com a utilização do A3? Obrigado.

Italo, obrigado pela ajuda! Sempre trabalhamos com nossos clientes a possibilidade de comprar o certificado A1, mas grande parte de nossos clientes são pequenos transportadores, as vezes tem só o proprio dono na empresa, e acaba ficando inviável pra ele comprar o certificado A1, pois ele já tem o A3, devido sugestão do contaodor dele. De qualquer forma, ontem conseguimos resolver o problema, e pior que foi com uma solução muito simples. Simplesmente fomos no Delphi 10.3.2 que a versão que migramos nossos produtos, e criamos um projeto novo, adicionei as units nesse novo projeto e pronto, problema resolvido. No processo de migração, nós apenas abrirmos o DPR da versão antiga na versão nova e mandamos compilar. Confesso que não sei exatamente o que solucionou o problema, mas acredito que fazendo isso, novos pacotes foram incluidos no binários do executável, pois ele ficou maior. De qualquer forma obrigado pela atenção.

Acredito que não seja no certificado, porque está funcionando o DEMO na maquina do usuário. A minha aplicação que não funciona. Dá o erro "12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura". Porém infelizmente não identifiquei o que tem na minha aplicação que está causando isso. Só por curiosidade, atualizei recentemente minha aplicação para o delphi 10.3.3(o demo que testei está compilado nessa versão tb), porém a aplicação antiga que é compilado no delphi XE8 está funcionando normalmente no cliente, a nova q não está.(A antiga está utilizando CAPICOM).

Configurei o SSLType como LT_TLSv1_2 e no demo do ACBr funcionou corretamente. Porém na minha aplicação, deu o erro "12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura". Entendo deve ser algo que tem na minha aplicação, porém estou com dificuldades para encontrar, pois como eu disse, é um erro que só acontece no computador do cliente que usa Certificado A3. Vocês tem alguma idea de como posso identificado o problema? Obrigado

Pessoal, desculpe a demora, pois só consigo simular o problema no ambiente do cliente. Ao mudar para WinCrypt, dentro do prórpio demo do ACBR, tive a mensagem abaixo:

Bom dia, atualizei recentemente a versão do delphi para a 10.3.2 e estou tento um problema com meus clientes que usam certificado A3 para enviar CTe. Ao tentar fazer o envio, tenho o seguinte erro: 12157 - Erro relacionado ao Canal seguro Uso o CAPICOM Porém, no Demo do ACBr, a com a mesma configuração, o certificado funciona normalmente. Acredito que deve ser alguma unit ou DLL que estamos colocando no nosso executável que está gerando esso problema, só que já estamos com mais de um mês com esse problema e ainda não conseguimos resolver. Vocês tem alguma idela ou sugestão de ação que podemos fazer. Obrigado