Resolvendo certificado

[JoséQuintas]

Continuo fazendo testes.
Resolvido timestamp.

1) Já que dá trabalho, gerando certificado com validade de 10 anos

2) Instalado em autoridades confiáveis, assim dá pra fazer timestamp

Resta confirmar no destinatário.
Tenho rotina de instalar certificado, fazer testes disso, talvez de instalar em autoridade confiável.

Sei lá....
Se conseguir, é o mesmo que transformar tudo sobre certificado em palhaçada.
Não sei se o pior vai ser se der certo ou se der errado kkkkk

[Itamar M. Lins Jr.]

Olá!
Tem um programa no Linux, que gera CERTIFICADOS, confiáveis para os sites. Tem que testar, mas o certificado é aceito pelos navegadores.
Tinha usado outros, mas como o navegador não ter como CHECAR, dizia que o certificado não podia ser aceito, por não ter um órgão(origem) que gerou.
Acredito que é isso. Esse programa gera certificado aceito -> O CADEADO que fica nos navegadores HTTPS.
Da forma antiga gera fica HTTPS mas tem que ficar mexendo nos navegadores para aceitar. Agora não precisa mais.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Explicando:

Pra fazer timestamp, o certificado é validado, mas não existe autoridade pra isso.
A saída é instalar como autoridade, em Root e não em My.

Se no cliente acontecer a mesma coisa, seria instalar em My ou em Root.
Mas em Root, só com direitos de administrador.

Dá pra fazer isso usando CAPICOM, e aonde emite NFE costuma ter CAPICOM.

No powershell não tem limite de validade, poderia ser acima de 10 anos.
Segundo a IA, por motivo de segurança a validade poderia ser limitada a menos tempo.

Não é pra site, é pra assinatura de código mesmo, pro antivírus não encher o saco.

[JoséQuintas]

Válido até 2035.

Não estou a fim de pagar centenas de dólares este ano pra fazer certificado.

[JoséQuintas]

Windows PowerShell, todo mundo tem

Código: Selecionar todos

$cert = New-SelfSignedCertificate `
-KeyUsage DigitalSignature `
-KeySpec Signature `
-KeyAlgorithm RSA `
-KeyLength 2048 `
-DNSName “www.site.com.br” `
-CertStoreLocation Cert:\CurrentUser\My `
-Type Custom `
-Subject “CN=nome,E=email” `
-NotAfter (Get-Date).AddYears(10)

[JoséQuintas]

Então.....
Isso resolve a parte da "nossa" máquina.

Gera o certificado.
assina mas não deixa fazer o timestamp.

Exportei sem a chave particular, gera o .cer
Instalando em root
assina e faz time stamp.

Agora é testar no cliente.
Capicom vai deixar instalar automático.
Mas em root só administrador.

[JoséQuintas]

Tenho a signtool.exe da Microsoft, em todo caso, com CAPICOM, que usamos pra NFE.

testar

Código: Selecionar todos

STATIC FUNCTION TestSignedEXE( cFileName )

   LOCAL oSignedCode, lOk := .F.

   BEGIN SEQUENCE WITH __BreakBlock()
      oSignedCode := win_OleCreateObject( "CAPICOM.SignedCode" )
      oSignedCode:FileName := cFileName
      oSignedCode:Verify()
      lOk := .T.
   ENDSEQUENCE
   IF ! lOk
      ShowAlert( "Signature check fail. Trying to sign" )
      SignEXE( cFileName )
   ENDIF

   RETURN lOk

assinar

Código: Selecionar todos

STATIC FUNCTION SignEXE( cFileName )

   LOCAL oSignedCode, oSigner, nStatus := -1

   BEGIN SEQUENCE WITH __BreakBlock()
      oSignedCode := win_OleCreateObject( "CAPICOM.SignedCode" )
      oSignedCode:FileName := cFileName
      oSigner := win_OleCreateObject( "CAPICOM.Signer" )
      oSigner:Certificate := CAPICOMCertificado( "JPA TECNOLOGIA LTDA" )
      oSignedCode:Sign( oSigner )
      nStatus := 1
      oSignedCode:TimeStamp( "http://timestamp.digicert.com" )
      nStatus := 2
   ENDSEQUENCE
   IF nStatus < 1
      ShowAlert( "Can't sign. Not installed CAPICOM and/or EXE not signed" )
   ELSEIF nStatus < 2
      ShowAlert( "Signed, but can't time stamp" )
   ENDIF

   RETURN nStatus > 0

[JoséQuintas]

Primeira ocorrência referente ao certificado fabricado.
Vou pedir pro administrador instalar meu certificado em autoridades confiáveis.
Isso deve resolver o problema até 2035.

[JoséQuintas]

Acho que tem a ver com o anterior, apenas palpite.

Código: Selecionar todos

RUN ( "c:\pasta\arquivo.exe" )

Isso acima parou de funcionar
Troquei para

Código: Selecionar todos

ShellExecuteOpen( "c:\pasta\arquivo.exe",,"pasta" )

Passou a funcionar.

Minha suposição:
RUN () fica preso a um programa externo, da rede.
ShellExecute() é na própria máquina, aberto pelo Windows.
Minha suposição é a segurança do Windows não deixar um programa de fora chamar um programa da máquina.
Isso explicaria o alerta anterior também.
Apenas suposição, porque isso não seria segurança, já que o modo alternativo funciona.
Acaba não impedindo nada, ao mesmo tempo que impede kkkkk

Mistérios.....

[Itamar M. Lins Jr.]

Olá!
A função Run() chama o CMD. (novo prompt)
Enquanto a outra não precisa. Eu uso hb_processrun()

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

A coisa é pior do que pensei.

sjpatop.exe - usa ShellExecute() pra carregar topxxx.exe, o mais novo
topxxx.exe - usa ShellExecute() pra carregar sjpa.exe
sjpa.exe - usa ShellExecute() pra carregar jpa_xxx.exe, o mais novo

topxxx.exe é o aplicativo específico da empresa
O jpaxxx.exe é o meu aplicativo, que autoriza nota eletrônica.
sjpatop.exe e sjpa.exe são cópia um do outro, é meu programa de start, que pega a versão mais nova, ou de topxx.exe ou de jpaxx.exe

Tá tudo certo, porque funciona.

Mas no dia seguinte deixa de funcionar.

Coincide que estou usando o certificado fake.
stop.exe tá na rede
sjpa.exe tá local
Path indicado corretamente.

[JoséQuintas]

Esquece a última parte.
O problema de hoje não é o mesmo de ontem.

Começou as 9 da manhã

Num teste isolado: a comunicação da Fazenda pra autorizar NFE mudou HOJE pra síncrono.
O programa chamado é quem trata disso, e o usuário comunicou como sendo o mesmo problema de ontem.

[JoséQuintas]

Na verdade se juntaram algumas coisas:

1. Fazenda mudou pra síncrono, por isso a tela acabou não tendo mensagem
Na sefazclass, eu coloquei uma prevençào quando falha o envio, e já consulta o protocolo.
Porque poderia ser falha no envio, sem poder consultar recibo, então consultava protocolo.
O fato de mostrar mensagem ou não, não vém ao caso agora.

2. Ao chamar o programa diretamente (sem o ShellExecute()), aparecia o alerta do windows.
Aquele de programa pouco usado.
Em ShellExecute() o programa era boloqueado.

3. Tem a atualização, aqui é por internet.
Tem aquela coisa do windows marcar e semi-bloquear programa baixado da internet.
Quem não viu isso ainda, é só ver propriedades do programa

No outro cliente, a atualização é pelo MySQL.
Isso não vai causar a marca de ter sido baixado da internet.

No final de tudo, não sei se o certificado fake fez diferença.
Não sei se é igual sem certificado, ou com certificado fake.

Com certeza o certificado normal seria melhor.

Por exemplo: a Microsoft coleta EXE pra análise.
Na máquina, com certificado em autoridade ok, pode ser validado.
Lá na Microsoft acusaria inválido, porque lá não tem certificado.

Também tem o detalhe de multithread.
Qual a diferença ?
A thread normal é bloqueada, a multithread continua. (não cheguei a confirmar desta vez).
Em multithread o programa faz muita coisa antes de parar.

Sei lá....
Quanto mais entendo.... menos entendo...

É só comparar isso com a ação de um hacker.
Se eu posso, um hacker também pode.

Isso lembra muito as leis do Brasil.
As leis são pra quem cumpre a lei.
Pra quem não cumpre lei, pode encher de leis, que não faz diferença.
O resultado é só atrapalhar quem cumpre a lei.

As proteções do Windows parecem só mais trabalho pra quem trabalha.

Eu tô dizendo....
Esse negócio de UTF-8 pra reconhecer mundial, pra quem não trabalha para o mundo.....
HD com problema de data hora, por causa do fuso horário....
Vírgula e ponto decimal, pra atrapalhar teclado/digitação....
E por aí vai.

Até o certificado... que custa caro.... só trabalho.

A propósito: meu certificado venceu.
Por isso estou tratando disso agora, porque se não der certo, vou ter que comprar outro certificado, alguns milhares de reais estão em jogo.

[JoséQuintas]

Atualizando pelo MySQL não fica assim:

Isso causa limitação.

Ainda tentando entender essas coisas....
Nem tudo é problema de certificado.

Talvez salvar local por outros meios, e um ShellExecute() ao EXE local indicando a pasta do servidor pra acesso.
De repente um MemoRead() e hb_MemoWrit().
De repente fazer isso em multithread que não é bloqueado pela checagem do windows.
Qualquer que seja a solução.... lá se vai a segurança do windows pro espaço.... kkkkk

[JoséQuintas]

Ainda não fiz mais testes sobre isso.
Mas é interessante.

Se o arquivo está em sua máquina, a segurança é uma.
Se o arquivo vém de outra máquina, a segurança é outra.
Parece que uma das seguranças do Windows é identificar a origem do arquivo.

Então temos:

1. A segurança de pouco uso do EXE
2. A segurança da origem do EXE
3. O certificado de autoridade local
4. O certificado de autoridade mundial, em qualquer lugar

É só considerar que nessa empresa em questão o aplicativo podia ser trocado normalmente, e sem ter certificado.
Estava rodando sempre local, em todas as estações.

Agora estou rodando instalado no servidor, e é onde a coisa começou a pegar.

Talvez a solução mais simples seja mesmo copiar pra máquina e rodar com ShellExecute( "aplicativo",,"pasta da rede" ).
E isso acaba com a exigência de certificado especial.

Restaria melhorar a parte de atualização.

É aí que lettodb, hbnetio, mysql ou outro podem fazer diferença, porque dispensam o compartilhamento de pasta com EXE.
Em breve fazer mais testes, porque obrigatoriamente vou estar atualizando esse aplicativo.
Não vou querer bloqueio toda vez que atualizar.
A simples existência de um EXE na pasta compartilhada pode causar diferença/bloqueio da pasta.