STATUS_NOT_FOUND como "Um erro interno inesperado" no signtool.exe

Minha pergunta está relacionada a esta . Infelizmente, essa pergunta é sobre uma CA diferente (Symantec) e usa um token de hardware diferente (da Safenet) e, embora as soluções fornecidas correspondam ao código de erro, as circunstâncias do meu caso não coincidem (entre outras coisas, o cartão inteligente) Fui informado que não parece registrar seu próprio provedor em HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers).

Estou usando um certificado de assinatura de código-fonte aberto do certum.pl. Estou usando o signtool.exeSDK do Windows 10.0.18362.0e estou vendo o seguinte erro (com signtool sign /v /debug):

signtool.exe sign /v /debug /a /i Certum /ph /du "https://my.url" /d "short description" /fd sha256 /tr "http://timestamp.digicert.com" /td sha256 "mysoftware.exe"
The following certificates were considered:
    Issued to: Open Source Developer, ...
    Issued by: Certum Code Signing CA SHA2
    Expires:   ...
    SHA1 hash: ...
    Issued to: Open Source Developer, ...
    Issued by: Certum Code Signing CA SHA2
    Expires:   ...
    SHA1 hash: ...
After EKU filter, 2 certs were left.
After expiry filter, 1 certs were left.
After Issuer Name filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
    Issued to: Open Source Developer, ...
    Issued by: Certum Code Signing CA SHA2
    Expires:   ...
    SHA1 hash: ...
Done Adding Additional Store
Error information: "Error: SignerSign() failed." (-1073741275/0xc0000225)
SignTool Error: An unexpected internal error has occurred.

O código de erro 0xC0000225corresponde exatamente ao seguinte NTSTATUS:

//
// MessageId: STATUS_NOT_FOUND
//
// MessageText:
//
// The object was not found.
//
#define STATUS_NOT_FOUND                 ((NTSTATUS)0xC0000225L)

... o que faz todo sentido, dados os HRESULTcódigos usados signtool.exee o mapa de infraestrutura subjacente 1: 1 para NTSTATUS(é claro que, se um código de instalação for fornecido, HRESULTexistem códigos que não têm nome ntstatus.h... o que quero dizer é o layout HRESULTe NTSTATUS)

Infelizmente, isso não me diz nada, já que muitas coisas podem não ser encontradas em um determinado momento ... Até o momento, ainda estou tentando reduzi-lo por conta própria usando o ProcMon. Para a tentativa falha, estou vendo 592 NAME NOT FOUNDresultados no ProcMon, que devem corresponder ao NTSTATUScódigo acima ; a maioria deles para chaves e valores do registro.

Aqui está a signtoollinha de comando completa novamente:

"C: \ Arquivos de programas (x86) \ Windows Kits \ 10 \ bin \ 10.0.18362.0 \ x64 \ signtool.exe" assina / v / debug / a / i Certum / ph / du " https: //my.url " / d "descrição curta" / fd sha256 / tr " http://timestamp.digicert.com " / td sha256 "mysoftware.exe"

... e sim, verifiquei que ele realmente está usando isso signtool.exe... na verdade, tentei com x86 e x64 com caminhos completos para uma boa medida (meu script atual aborda algumas das complexidades e prepara o ambiente para se ajustar PATHpara poder chamar signtool.exesem o caminho completo).

Curiosamente, ele funciona ao assinar com resumos SHA1 da seguinte forma:

"C: \ Arquivos de programas (x86) \ Windows Kits \ 10 \ bin \ 10.0.18362.0 \ x64 \ signtool.exe" assina / v / debug / a / i Certum / ph / du " https: //my.url " / d "descrição curta" / t " http://timestamp.digicert.com " "mysoftware.exe"

(as diferenças estão ausentes /fd sha256e /td sha256, em /tvez do /trURL do serviço de carimbo de data e hora, ou seja, protocolo diferente)

A versão do software proCertum CardManager é 3.2.0.156, detalhes conforme a seguinte captura de tela:

(É a versão mais recente disponível no site da Certum no momento da redação deste documento.)

Enquanto isso, tentei também com o signtool.exe(x86 e 64 respectivamente) de:

• SDK do Windows 8.1
• Windows 10.0.17763.0 SDK

... mesmos resultados e estou confuso sobre como posso resolver isso.

Acontece que o problema era uma opção que não foi definida corretamente por padrão (o nome sugeria que ele se aplica apenas aos certificados EV, mas parece que também se aplica aos que digerem SHA2). Graças ao pessoal de suporte da Certum!

Eu destaquei a opção relevante.

Observe também que eu tive que

1. saia do aplicativo (do TNA, também conhecido como "bandeja do sistema")
2. inicie o aplicativo elevado a partir da pasta do programa
3. marque a caixa de seleção
4. aperte o botão OK
5. descartar a caixa de mensagem (êxito)
6. reiniciar

... quando eu já havia tentado sem elevação, o processo falhou. E sim, vi o ícone "blindagem", mas supus que o aplicativo contenha a lógica para realizar a elevação (não).

Quando tentei novamente a assinatura após uma reinicialização, não era mais o proCertum CardManager solicitando o PIN do cartão, mas o Windows. E assinar funcionou como um encanto.

NB: ainda não havia entradas por baixo HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providersapós estas etapas.