Références

Cette page regroupe les informations de référence communes aux différentes méthodes d’intégration du service de signature de code à distance sslTrus, notamment :

• Règles de calcul du nombre de signatures de code.
• Protocoles d’horodatage Authenticode et RFC 3161.
• Serveurs d’horodatage couramment utilisés pour la signature de code.
• Points d’attention lors du choix d’un service d’horodatage en environnement de production.

Calcul du nombre de signatures

Le nombre de signatures est calculé en fonction des actions de signature réellement effectuées.

En résumé :

一个文件成功完成一次签名 = 一次签名次数

Le nombre de signatures n'est pas calculé en fonction du nombre de fichiers de code source, ni d'une seule compilation, d'un seul empaquetage ou d'un seul pipeline CI/CD.

Par exemple :

100 个源代码文件
        ↓
编译生成 1 个 app.exe
        ↓
app.exe 成功签名一次
        ↓
1 次签名

Si une seule construction produit :

app.exe
helper.dll
installer.msi

Et une fois que les trois fichiers sont respectivement signés, alors :

签名次数 = 3 次

Règles de base

Le nombre de signatures dépend principalement de :

1. Les fichiers ou objets finalement signés.
2. Le nombre réel de signatures effectuées sur chaque objet.
3. L’utilisation d’une signature client standard ou d’appels de signature de bas niveau tels que KSP, Jarsigner, etc.
4. La signature automatique par l’outil de build d’EXE, DLL, programmes de désinstallation ou paquets d’installation supplémentaires.

Les objets couramment signés incluent :

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• le programme de désinstallation, par exemple uninstall.exe

Dès qu’un objet est signé avec succès une fois, il est comptabilisé selon la règle de décompte correspondante.

La signature n’est comptée qu’en cas de succès

Le nombre de signatures n’est comptabilisé que si le service de signature de code à distance réussit la signature.

Les situations suivantes ne sont généralement pas comptabilisées :

• Échec d’authentification.
• Erreur de paramètre.
• Certificat indisponible.
• Échec de la requête réseau.
• Absence de retour réussi du résultat de signature par le serveur.
• Consultation du certificat.
• Consultation des enregistrements de signature.
• Vérification de la signature.
• Suppression d’une signature existante.
• Génération du fichier de vérification.

Si le service distant a déjà renvoyé avec succès le résultat de la signature, mais que le client échoue ensuite lors de l’écriture locale du fichier, de l’ajout de l’horodatage ou du traitement ultérieur, la signature distante déjà réalisée est tout de même comptée comme une signature réussie.

L’horodatage n’est pas compté séparément

L’horodatage sert à prouver qu’une signature existait déjà à un moment donné ; il ne constitue pas une nouvelle opération de signature de code.

Par conséquent :

Signature de code       → nombre de signatures générées
Ajout d’horodatage      → aucune signature supplémentaire générée
Vérification de la signature → aucune signature générée

La réussite du service d’horodatage affecte uniquement le résultat d’horodatage du fichier signé final et ne signifie pas qu’une signature de code supplémentaire a été exécutée.

SignTool CLI

Utilisez l’interface en ligne de commande sslTrus SignTool :

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe

Si la signature réussit :

1 个文件 × 1 次成功签名 = 1 次

Par exemple :

signtool sign --cert-code CERT_CODE --file app.exe
signtool sign --cert-code CERT_CODE --file helper.dll
signtool sign --cert-code CERT_CODE --file installer.msi

Les trois fichiers ont tous été créés avec succès :

合计 = 3 次

Signature double avec SignTool CLI

Si vous utilisez SignTool CLI standard tout en activant à la fois SHA-1 et SHA-2 :

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --sha1=true \
  --sha2=true

Signature CLI double standard calculée comme une tâche de signature client :

GUI / SignTool CLI 双签 = 1 次

C'est l'endroit le plus susceptible d'être confondu entre le processus de signature des clients ordinaires et les appels de signature sous-jacents de KSP.

Windows KSP

KSP est le mode d'intégration du fournisseur CNG de Windows.

Lorsque Microsoft SignTool, MSBuild, Visual Studio, les outils d'empaquetage Electron ou d'autres logiciels Windows appellent la signature de code distante via KSP, le comptage est plus proche de :

底层远程私钥签名调用次数

Par exemple :

Opération	Nombre de signatures
Effectuer une signature SHA256 pour app.exe	1 fois
Effectuer d’abord SHA256, puis ajouter SHA1	2 fois
Signer séparément app.exe, helper.dll, uninstall.exe	3 fois

Par conséquent :

SignTool CLI 双签 = 1 次
KSP 双签          = 2 次

Si l’outil effectue plusieurs opérations de signature sous-jacentes sur le même fichier, chaque signature à distance réussie est comptée séparément.

CSP

CSP est un fournisseur CryptoAPI Windows classique.

CSP est également appelé par Microsoft SignTool ou d’autres applications Windows via le fournisseur pour utiliser le service de signature à distance.

Pour déterminer le nombre de signatures, il convient de se baser sur les opérations réelles de signature à distance avec la clé privée.

Si l’outil signe plusieurs fichiers ou signe plusieurs fois le même fichier, chaque opération doit être comptée séparément.

Jarsigner

Lorsque vous utilisez le fournisseur sslTrusJarsigner, la commande standard jarsigner appelle le service de signature de code à distance pendant le processus de signature.

En général :

Opération	Nombre de signatures
Signature de app.jar	1 fois
Signature séparée de 3 JAR	3 fois
Nouvelle signature du même JAR	1 fois supplémentaire
jarsigner -verify	0 fois
Génération du keystore de vérification	0 fois

Par conséquent :

每个 JAR 每次成功完成签名 = 1 次

Package d'installation

Le package d'installation doit distinguer :

1. Le fichier exécutable à l'intérieur du package d'installation.
2. Le package d'installation lui-même.

Par exemple :

app.exe       → signé 1 fois
installer.msi → signé 1 fois

alors :

合计 = 2 次

S’il existe d’autres fichiers :

Fichier	Signé	Nombre de signatures
app.exe	Oui	1
helper.dll	Oui	1
driver.sys	Oui	1
installer.msi	Oui	1
Total		4

Le nombre de fichiers de code source, de fichiers de ressources, d’images ou de fichiers de configuration contenus dans le paquet d’installation n’a pas d’impact direct sur le nombre de signatures.

L’essentiel est le suivant :

最终到底有哪些产物被实际签名

Electron

Les outils de génération d’applications de bureau tels qu’Electron Builder et Electron Forge peuvent signer automatiquement plusieurs fichiers au cours d’un même processus de packaging.

Les objets courants incluent :

• Programme principal .exe
• DLL
• Programme de mise à jour
• Programme de désinstallation
• Package d’installation .exe
• MSI
• Autres fichiers exécutables auxiliaires

Par exemple :

Artefact	Nombre de signatures
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
Total	5

Par conséquent :

一次 Electron Build ≠ 一次签名

Il faut le calculer en fonction du nombre réel d’artefacts signés et du nombre de signatures exécutées pour chaque artefact.

Si Electron utilise un KSP et effectue une double signature sur le même fichier, ce fichier peut également générer deux signatures à distance.

Jugement rapide

Lorsque vous ne savez pas combien de signatures seront générées lors d’une compilation, vous pouvez vérifier dans l’ordre suivant :

1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？

On peut le comprendre simplement comme suit :

签名次数 = 成功完成的签名动作数量之和

Attention particulière :

GUI / SignTool CLI 双签                = 1 次
KSP 对同一个文件执行两次底层签名       = 2 次
Jarsigner 每个 JAR 每次成功签名         = 1 次
时间戳                               = 0 次
验证签名                             = 0 次

Serveur d'horodatage

La signature de code utilise généralement en parallèle un service d'horodatage.

L'horodatage permet de prouver que la signature numérique existait déjà à un moment donné, permettant ainsi au vérificateur de juger la validité de la signature en combinant le certificat de signature, le certificat d'horodatage, l'état de révocation et la politique de validation.

Deux protocoles d'horodatage sont couramment utilisés pour la signature de code :

Protocole	Description
Authenticode	Protocole d'horodatage traditionnel de Microsoft, principalement utilisé pour la compatibilité avec les anciens flux de signature de code Windows
RFC 3161	Protocole d'horodatage universel, adapté aux scénarios modernes de signature de code

Dans les scénarios modernes de signature de code, RFC 3161 est généralement privilégié.

RFC 3161

La requête d'horodatage RFC 3161 envoie le condensé des données à horodater, et non le fichier original.

Processus de base :

代码签名
   ↓
计算待时间戳数据摘要
   ↓
发送摘要到 TSA
   ↓
TSA 返回时间戳令牌
   ↓
写入最终签名

Jetons d’horodatage incluent généralement :

• Empreinte des données.
• Heure d’émission de l’horodatage.
• Politique TSA.
• Signature numérique TSA.

Le serveur d’horodatage n’entraîne pas de consommation supplémentaire du quota de signature de code sslTrus lors de l’ajout de l’horodatage.

Serveurs d’horodatage courants

Les points de terminaison suivants s’appliquent aux scénarios courants de signature de code.

Avant toute utilisation en production, vous devez reconfirmer la dernière documentation officielle, les politiques de service et la disponibilité du fournisseur correspondant.

Microsoft

http://timestamp.acs.microsoft.com

Principalement utilisé pour l'horodatage RFC 3161.

Convient comme candidat d'horodatage dans les scénarios modernes de signature de code sous Windows.

Exemple :

--timestamp-rfc3161=http://timestamp.acs.microsoft.com

Microsoft SignTool :

/tr http://timestamp.acs.microsoft.com
/td SHA256

Sectigo

http://timestamp.sectigo.com

Prise en charge：

• Authenticode
• RFC 3161

Utilisable avec Windows et d'autres outils de signature de code prenant en charge les protocoles correspondants.

Sectigo impose des exigences d'utilisation côté service pour les appels en masse. Les systèmes de production doivent contrôler la fréquence des appels conformément à sa politique officielle actuelle.

DigiCert

http://timestamp.digicert.com

Prise en charge de la RFC 3161, utilisable pour des scénarios de signature de code tels que Microsoft Authenticode.

Certum

http://time.certum.pl

Pris en charge :

• Authenticode
• RFC 3161

La documentation officielle de Certum sur la signature de code couvre les scénarios de signature Windows et Java JAR.

GlobalSign

http://timestamp.globalsign.com/tsa/r45standard

Actuellement, les profils de signature de code GlobalSign utilisent cette adresse d’horodatage RFC 3161.

Il n’est pas recommandé de continuer à utiliser les anciennes adresses GlobalSign qui ne figurent plus dans la documentation officielle actuelle sur la signature de code.

SSL.com

http://ts.ssl.com

RFC 3161 est pris en charge, contrairement au protocole d’horodatage Authenticode traditionnel.

Si l’outil de signature cible ou un ancien système impose des restrictions de compatibilité sur l’algorithme de clé utilisé par l’autorité d’horodatage (TSA), une validation concrète doit être effectuée avant la mise en production.

Comparaison des serveurs d’horodatage

Fournisseur	Adresse	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	Non confirmé	Pris en charge
Sectigo	http://timestamp.sectigo.com	Pris en charge	Pris en charge
DigiCert	http://timestamp.digicert.com	Non confirmé	Pris en charge
Certum	http://time.certum.pl	Pris en charge	Pris en charge
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	Non confirmé	Pris en charge
SSL.com	http://ts.ssl.com	Non pris en charge	Pris en charge

Dans le tableau, « Pris en charge » décrit la capacité protocolaire confirmée par la documentation publique du fournisseur correspondant.

Les politiques des services d’horodatage peuvent évoluer ; avant la configuration en production, il convient de vérifier à nouveau les documents officiels actuels du fournisseur.

Services d’horodatage restreints

Certains serveurs d’horodatage fournissent bien un service RFC 3161, mais ne peuvent pas être utilisés directement comme TSA publique anonyme.

QuoVadis

Les adresses RFC 3161 publiques incluent :

http://ts.quovadisglobal.com/eu
http://ts.quovadisglobal.com/ch

Ce service exige que l’adresse IP de sortie de l’appelant soit enregistrée au préalable ; une autorisation correspondante doit donc être effectuée avant l’intégration.

Apple

http://timestamp.apple.com/ts01

Il appartient au service d’horodatage utilisé dans l’écosystème de signature de code Apple.

Il ne doit pas être utilisé directement comme serveur d’horodatage universel pour Windows Authenticode.

Service d’horodatage de test

Certains services publics RFC 3161 sont plus adaptés aux tests de protocole qu’à une utilisation directe comme TSA de signature de code en production.

Par exemple :

https://freetsa.org/tsr

Ces services peuvent utiliser leur propre autorité de certification (CA) et leurs certificats TSA.

Il ne faut donc pas supposer que :

Windows
macOS
Java
其他代码签名验证器

Par défaut, sa chaîne de certificats est considérée comme fiable.

En environnement de production, il convient d’utiliser la plateforme cible pour vérifier réellement les artefacts de signature.

Vérification en environnement de production

Avant d’ajouter un serveur d’horodatage à la configuration de production, il est recommandé de confirmer au moins les points suivants :

1. La documentation officielle du fournisseur de services indique clairement ce point de terminaison.
2. Le fournisseur de services prend explicitement en charge le protocole d’horodatage requis.
3. L’algorithme de résumé d’horodatage utilisé est SHA-256 ou plus fort.
4. Le système cible peut vérifier la chaîne de certificats complète de l’autorité d’horodatage (TSA).
5. Le DNS, le proxy, le pare-feu et le réseau de sortie permettent d’accéder de manière stable à la TSA.
6. La méthode d’authentification, les limites de débit, les restrictions régionales et les conditions d’utilisation ont été confirmées.
7. Les tests de vérification de signature ont été effectués à l’aide des artefacts de signature réels.

Ne vous contentez pas de :

浏览器可以打开
HTTP 返回 200

Déterminer si le serveur d’horodatage est adapté à la signature de code.

Il est impératif d’envoyer la requête d’horodatage avec l’outil de signature réellement utilisé, puis de valider le produit final.

Recommandations pour le choix de l’horodatage

Pour la signature de code Windows moderne en SHA-2, privilégiez en général un service d’horodatage compatible RFC 3161.

Par exemple :

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

Le choix final doit prendre en compte :

• Le système d’exploitation cible.
• L’outil de signature.
• La chaîne de certificats TSA.
• L’accessibilité réseau.
• Les restrictions régionales.
• Les limites de fréquence d’appel.
• Les conditions de service.
• Les accords de niveau de service.
• Les résultats réels de validation du produit signé.

Si le fournisseur de certificats impose des exigences explicites concernant le service d’horodatage, il convient de suivre en priorité la politique de certificat correspondante et les exigences du fournisseur de services.

Méthodes d’intégration associées

Les différentes méthodes d’intégration utilisent les règles de comptage des signatures et d’horodatage décrites sur cette page :

Scénario d’utilisation	Documentation
SignTool CLI	Outil client
Windows KSP / CSP	Windows Provider
Jarsigner	Intégration Java
GitHub Actions, Electron Builder, Advanced Installer	CI/CD et outils de build
Appel direct de l’interface de signature à distance	Intégration API