La signature de Code avec signtool échoue à cause d'un filtre à clé privé

en essayant de signer un installateur créé par la société pour laquelle je travaille, j'ai rencontré une erreur que je n'ai pas pu résoudre. J'utilise le même certificat qui a été utilisé sur une autre machine (Win7) avec succès de la même manière pour signer quasi le même installateur. Quoi qu'il en soit, sur notre serveur Windows 2008 qui est en cours d'exécution CruiseControl.net j'ai essayé de signer un installateur avec signtool.exe et il échoue avec l'erreur suivante:

The following certificates were considered:
    Issued to: <our company>
    Issued by: <some ca>
    Expires:   <is valid>
    SHA1 hash: <...>

    Issued to: <...>
    Issued by: <...>
    Expires:   <...>
    SHA1 hash: <...>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Subject Name filter, 1 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.

j'ai essayé d'installer le certificat à différents magasins de certificat, essayé différentes versions de signtool.exe et essayé d'utiliser l' .le fichier cer directement, mais cela n'a fait aucune différence. Je reçois l'erreur mentionnée ci-dessus dans tous les cas. J'ai essayé les commandes en ligne de commande suivantes

signtool.exe sign /debug /n "MyCompany" C:myinstaller.exe
signtool.exe sign /debug /f C:pathtomycertificate.cer C:myinstaller.exe

mais j'ai laissé le / debug de côté dans certains cas. Est-ce que je fais de mal ou manquant?

11
demandé sur Adi Lester 2015-02-24 11:19:14

4 réponses

pour signer un fichier, vous devez avoir la clé privée du certificat, ce qui n'est pas inclus dans le *.fichier cer que vous avez copié depuis la machine Windows 7. Pour exporter le certificat avec sa clé privée, vous pouvez suivre l' instructions fournies ici.

notez que vous ne pourrez exporter la clé privée que si le certificat a été défini pour permettre son exportation lors de sa création (en passant -pemakecert)

4
répondu Adi Lester 2017-02-09 15:06:01

j'ai eu l' même problème, mais un tout autre raison. Comme beaucoup de développeurs, j'ai un tas de chaînes d'outils différentes installées sur mon système. Je viens de les sonder pour voir à quoi cela peut ressembler; faites défiler vers le bas de cette réponse pour la liste complète.

j'avais installé mon certificat de signature de code de VeriSign à la réserve de certificats système (nécessite /smsigntool.exe) comme d'habitude, en utilisant certutil -importPFX cert.pfx d'un commandement élevé invite.

Premiers essais prometteurs, mais soudain, la signature a commencé à échouer.

Pour déboguer le problème j'ai commencé à utiliser signtool.exe sign /debug /v /a /sm ... pour voir ce qui ne va pas. La sortie ressemble à ceci (voir aussi la question):

The following certificates were considered:
    Issued to: localhost
    Issued by: localhost
    Expires:   Tue Dec 26 00:00:00 2017
    SHA1 hash: <...>

    Issued to: <...>
    Issued by: Symantec Class 3 SHA256 Code Signing CA
    Expires:   <...>
    SHA1 hash: <...>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Root Name filter, 1 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.

j'ai pu écarter le manque de la clé privée, comme le magasin de certificats clairement indiqué j'ai un correspondance clé privée:

Property dialog for certificate

Maintenant, Je rappelez-vous qu'il y avait certains récents patchs qui permettent à Windows 7 d'accepter les signatures faites avec un certificat qui a un hachage SHA256. Bien que, bien sûr, la plupart des articles plus anciens indiqueront que Windows 7 ne peut pas gérer SHA-2 hash à tous.

donc cela m'a déjà donné un coup de pouce dans la direction de "ça doit être une ancienne version de quelque chose impliqué dans la signature".

I a décidé de retirer la clé de certificat plus et de la réimporter à l'aide de l'invocation montré avant.

puis, après avoir examiné mon système (voir au bas de la réponse), j'ai trouvé un whopping cinq différentes versions de signtool.exe. J'ai donc commencé par essayer le plus récent (6.3.9600.17298, à partir du SDK Windows 8.1) et cela a fonctionné immédiatement:

signtool.exe sign /debug /v /a /sm /r VeriSign /ac MSCV-VSClass3.cer /ph  /t "http://timestamp.verisign.com/scripts/timstamp.dll" *.exe

The following certificates were considered:
    Issued to: localhost
    Issued by: localhost
    Expires:   Tue Dec 26 00:00:00 2017
    SHA1 hash: <...>

    Issued to: <...>
    Issued by: Symantec Class 3 SHA256 Code Signing CA
    Expires:   <...>
    SHA1 hash: <...>

After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Root Name filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
    Issued to: <...>
    Issued by: Symantec Class 3 SHA256 Code Signing CA
    Expires:   <...>
    SHA1 hash: <...>

Cross certificate chain (using machine store):
    Issued to: Microsoft Code Verification Root
    Issued by: Microsoft Code Verification Root
    Expires:   Sat Nov 01 13:54:03 2025
    SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

        Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
        Issued by: Microsoft Code Verification Root
        Expires:   Mon Feb 22 19:35:17 2021
        SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B

            Issued to: Symantec Class 3 SHA256 Code Signing CA
            Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
            Expires:   Sat Dec 09 23:59:59 2023
            SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5

                Issued to: <...>
                Issued by: Symantec Class 3 SHA256 Code Signing CA
                Expires:   <...>
                SHA1 hash: <...>


The following additional certificates will be attached:
    Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
    Issued by: Microsoft Code Verification Root
    Expires:   Mon Feb 22 19:35:17 2021
    SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B

    Issued to: Symantec Class 3 SHA256 Code Signing CA
    Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
    Expires:   Sat Dec 09 23:59:59 2023
    SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5

Done Adding Additional Store
Successfully signed: <...>.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

en cherchant plus loin, je pensais avoir trouvé le problème. Cependant, il s'est avéré que l'erreur que j'ai obtenu n'est pas ce que j'aurais appris à voir avec l'ancienne signtool.exe versions. Au lieu de cela, les versions plus anciennes se seraient plaintes de /ac,/fd et /ph étant des options de ligne de commande non reconnues, respectivement.

J'ai donc dû creuser un peu plus et il s'est avéré que mon gestionnaire de fichiers (alternatif) était le coupable. Je commence habituellement mes invites de commande dans le dossier respectif en utilisant ce gestionnaire de fichiers et un raccourci clavier pratique. Il s'avère que parfois il ne passe pas les variables d'environnement-essentiellement le gestionnaire de fichiers "oublie" les variables d'environnement. Cela s'est avéré être la cause profonde. Une invite de commande s'est ouverte en utilisant Win+ R et cmdEntrée n'exposerait pas ce comportement malgré l'exécution signtool.exe à partir du même dossier.

Ma meilleure supposition est que grâce à l'foiré PATH variable ou similaire,signtool.exe a fini par prendre la mauvaise DLL. Notamment mssign32.dll et wintrust.dllaccompagner signtool.exe dans le même dossier pour le SDK Windows 8.0 et 8.1, mais pas pour les versions antérieures de signtool.exe qui choisiront les DLLs" globales " à l'échelle du système, quelles qu'elles soient.


sur mon système j'avais cinq différentes versions de signtool.exe.

signtool.exe 5.2.3790.1830

ne comprend même pas le /ac et /ph arguments que j'utilisais (pas non plus /fd). Mais, curieusement, a travaillé sans ces deux argument.

  • C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\signtool.exe

signtool.exe 6.0.4002.0

ne comprend même pas le /ac et /ph arguments que j'utilisais (pas non plus /fd). Mais étrangement, ça a marché sans ces deux arguments.

  • C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\Bin\signtool.exe

signtool.exe de 6.1.7600.16385

première version à comprendre /fd sha256.

  • C:\WINDDK00.16385.1\bin\amd64\SignTool.exe
  • C:\WINDDK00.16385.1\bin\x86\SignTool.exe
  • C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe
  • C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe
  • C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe

signtool.exe 6.2.9200.20789

  • C:\Program Files (x86)\Windows Kits.0\bin\x64\signtool.exe
  • C:\Program Files (x86)\Windows Kits.0\bin\x86\signtool.exe

signtool.exe 6.3.9600.17298

  • C:\Program Files (x86)\Windows Kits.1\bin\arm\signtool.exe
  • C:\Program Files (x86)\Windows Kits.1\bin\x64\signtool.exe
  • C:\Program Files (x86)\Windows Kits.1\bin\x86\signtool.exe
11
répondu 0xC0000022L 2015-06-30 12:15:46

J'ai eu le même problème sur Win7 machine et j'ai essayé tout ce que les gens bien ont suggéré dans ce post sans chance. Puis, même ma machine n'a qu'un compte et des privilèges d'administrateur, j'ai ouvert la fenêtre d'invite de commande par "Exécuter en tant qu'administrateur" et puis toutes les versions de signtool.exe que j'ai installé commencer à travailler.

1
répondu Vadim Gorelik 2017-04-20 23:21:39

j'ai aussi dû signer un fichier, en utilisant un certificat que j'ai reçu d'une autre source (semblable à vous). Pour moi, le problème était que j'installais seulement le certificat sur mon PC avec l'option "Utilisateur courant". Une fois que je l'ai installé, en utilisant l'option "machine locale", ça a marché.

enter image description here

0
répondu Noceo 2018-02-22 06:59:39