Comment utiliser signtool.exe correctement dans hudson courir comme un service?
je viens d'acheter un code signing cert (MS authenticode) de THAWTE et je l'ai installé apparemment sur ma machine de construction. Je suis connecté en tant qu'utilisateur et lorsque j'ouvre une invite cmd, je peux signer EXEs en utilisant le cert avec signtool.EXE.
malheureusement, cette même ligne de commande ne fonctionne pas dans le processus hudson qui fonctionne sur la machine.
le message d'erreur que je reçois est:
erreur de SignTool: aucun certificat n'a été trouvé qui répond à toutes les donné critère.
je présume que c'est parce que le service de hudson fonctionne sous un compte différent que le compte que j'ai lancé signtool.exe de et du compte que j'ai utilisé pour obtenir le cert de thawte.
Donc, ma question est: Comment puis-je résoudre ce problème? Je pensais que j'allais télécharger un fichier à partir de thawte, mais à la place, il a juste utilisé IE d'une façon ou d'une autre pour installer le cert dans le cache de l'utilisateur par magie. Je veux probablement exporter (ou quel que soit le terme exact) vers un fichier que je peux stocker / sauvegarder ou utiliser sur n'importe quelle autre machine.
Comment puis-je faire cela et comment puis-je appeler signtool correctement avec le fichier ou le certificat d'un autre utilisateur dans le compte système/services?
4 réponses
Pris signtool sign -h sortie:
/s <name> Specify the Store to open when searching for the cert. The default
is the "MY" Store.
/sm Open a Machine store instead of a User store.
obtenir cela pour travailler est un peu d'une douleur... J'ai pu le faire fonctionner en ajoutant les certificats au magasin de machines local et en utilisant le commutateur /sm.
le commutateur /s vous permet de sélectionner le magasin prédéfini à utiliser. Malheureusement, je ne trouve aucune documentation qui liste les options disponibles (@Microsoft signtool maintainer: veuillez documenter cela!). Une complication supplémentaire est qu'il est difficile de déterminer à quel magasin Hudson donne accès - ce n'est pas le compte de sécurité locale de hudson comme vous pourriez vous attendre.
Note: le magasin "personnel" indiqué dans mmc views est le magasin "MY" lorsqu'on y accède à partir de signtool.
heureusement, le commutateur / sm nous fournit une carte "Sortie de prison". Malheureusement, ce serait un risque de sécurité si votre serveur build exécutait des tâches pour plusieurs organisations ou départements. Dans mon cas, il n'est utilisé que par mon groupe, dérange.
à titre de référence, je vais ajouter nos expériences ici. Nous utilisons TeamCity pour construire une application signée ClickOnce. Il m'a fallu plusieurs heures pour faire ça bien, donc j'espère que ça fera gagner du temps à quelqu'un d'autre.
Note: je l'exécute sur un serveur Windows 2k3 qui est aussi un serveur de domaine (Ouais, je sais).
Nous utilisons un certificat de signature de code de GoDaddy. Le CSR était généré avec Internet Explorer. Si en terminant la publication avec Internet Explorer, j'ai essentiellement fini avec le certificat de signature de Code installé sous mon propre compte.
parce que j'avais besoin du certificat sur le serveur de compilation, J'ai choisi IE:
[Extra] > [Options Internet] > [Contenu] > [Certificats]
Puis j'ai cliqué avec le bouton droit le certificat et [Exporter] ' ed. J'ai coché [Exporter clé personnelle] et choisir le format PFX avec [Exporter tous les certificats] et [Exporter toutes les propriétés] (pas sûr si c'est vraiment nécessaire). Finalement, après avoir spécifié l'emplacement, j'ai eu mon précieux.
maintenant j'étais prêt pour un peu de vraie douleur, mais pour vous épargner les détails, je vais sauter les Gros plans. Comme TeamCity fonctionnait sous le compte système, j'avais besoin d'avoir ce certificat sur notre serveur de construction sous ce même compte. Donc sur le serveur de build, je invoquée:
C:\> psexec-i-s cmd
qui m'a lancé une ligne de commande, en tant qu'utilisateur du système. Maintenant j'ai encore appelé mon Rusty IE:
C:\> C:\Program fichiers (x86)\Internet Explorer\iexplore.exe
j'ai navigué jusqu'aux certificats, et au lieu d'exporter, j'ai choisi importer et sélectionné le certificat que j'ai précédemment exporté. J' laissez Windows choose où les stocker.
maintenant tout était en place pour que ClickOnce utilise le certificat pour signer notre application. On devait s'assurer que ClickOnce était au courant. Je ne voulais pas mettre notre fichier clé dans un dépôt de code, donc dans mon Studio visuel local sur le [la Signature] onglet des propriétés du Projet, j'ai coché [ClickOnce manifests] et utilisé [sélectionner dans Store...] au lieu de [sélectionner dans le fichier...]. Cela m'a permis de choisir mon certificat installé localement. À ce moment précis, VS a créé une propriété
qui est la chose la plus importante pour faire tourner cette propriété sur le serveur de compilation. Notez que j'ai aussi ajouté un serveur d'Horodatage qui n'est pas obligatoire, mais fortement conseillé pour les logiciels de signature. Autrement, votre logiciel pourrait cesser de valider lorsque votre certificat expire. Pour GoDaddy, le serveur de temps est http://tsa.starfieldtech.com.
notez aussi que je n'ai pas signé l'Assemblée (encore). Je dis juste pour que tu saches que c'est possible.
maintenant le serveur de compilation récupérerait le fichier de projet et la propriété Fresh ManifestCertificateThumbprint, et l'alimenterait à la tâche SignTool. Pour que celle-ci fonctionne, j'ai dû copier sur signtool.exe à partir de C:\Program fichiers (x86)\Microsoft SDKs\Windows\v7.0a \ Bin to the same emplacement sur le serveur de construction.
le débogage sérieux et méchant a commencé à comprendre pourquoi le signtool ne fonctionnait pas. J'ai sorti des outils comme ProcMon et Explorateur De Processus pour savoir quelles clés de registre étaient demandées par quelles lignes de commande. J'ai recréé la ligne de commande invoquée par le SignTool, et j'ai regardé les effets avec ces outils.
Enfin, après beaucoup de développement intense et sysadmin douleur, J'ai pu déployer notre appli signée ClickOnce. Acclamations!
C'est un peu vieux maintenant mais je viens d'avoir un problème similaire qui mérite d'être documenté je pensais.
J'ai un serveur CI Jenkins tournant sur Win2008R2 comme service qui ne pouvait pas trouver un certificat lors de l'exécution d'un travail, mais manuellement je pouvais signer n'importe quoi sur la même machine.
signtool sign /sha1 ### file.dll
SignTool Error: No certificates were found that met all the given criteria.
le problème était que le service de Jenkins fonctionnait comme une Machine locale - donc j'ai pensé que l'utilisation de la réponse ci-dessus fonctionnerait.
signtool sign /sm /sha1 ### file.dll
Même message d'erreur. /a n'a pas tout faire non plus.
j'ai réussi à le faire fonctionner en créant un utilisateur 'Jenkins 'en tant que membre du groupe des administrateurs, en lançant le service en tant qu'utilisateur' Jenkins', en me connectant en tant qu'utilisateur Jenkins et en installant le certificat dans le magasin utilisateur.
Oui, j'ai fait installer le certificat pour le magasin de l'ordinateur local. J'ai même confirmé que le magasin de service avait le certificat en utilisant mmc et en ajoutant le compte de Service-Jenkins store.
j'ai pensé que ce serait un problème simple à résoudre. Au lieu de cela, cela devient une tragédie grecque.
Le fournisseur, Thawte, apparemment pense qu'il est utile d'exiger que tous les certificats d'actions à se produire sur la même machine et le navigateur que la demande a été initiée à partir d'. Malheureusement dans mon cas, je l'ai fait à partir d'une machine Windows7. En raison de quelques non-sens de MS qui signifie que lorsque j'ai obtenu le certificat, Je ne peux pas l'exporter avec la clé privée. Cela n'est possible que sur Win2000 et XP. Donc j'ai besoin d'utiliser un OS de 7 ans pour faire quelque chose de fondamental pour mon entreprise. C'est hallucinant.
il s'avère que maintenant j'attends que la troisième requête du certificat soit satisfaite.