Références
Cette page répertorie 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.
- Protocole d’horodatage Authenticode et RFC 3161.
- Serveurs d’horodatage de signature de code couramment utilisés.
- Points à prendre en compte lors du choix d’un service d’horodatage dans un environnement de production.
Calcul du nombre de signatures
Le nombre de signatures est calculé en fonction des actions de signature réellement effectuées.
Compréhension simple :
一个文件成功完成一次签名 = 一次签名次数
Le nombre de signatures n'est pas calculé en fonction du nombre de fichiers de code source, ni en fonction 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 construction produit :
app.exe
helper.dll
installer.msi
et les trois fichiers sont signés séparément, alors :
签名次数 = 3 次
Règles de base
Nombre de signatures principalement dépend de :
- Quels fichiers ou objets ont finalement été signés.
- Combien de signatures ont réellement été effectuées sur chaque objet.
- S’il s’agit d’une signature client ordinaire ou d’appels de signature de bas niveau tels que KSP, Jarsigner, etc.
- Si l’outil de build a automatiquement signé des EXE, DLL, programmes de désinstallation ou packages d’installation supplémentaires.
Objets de signature courants :
.exe.dll.msi.msp.sys.cat.jar- Désinstaller le programme, par exemple
uninstall.exe
Dès qu’un objet réussit effectivement une signature, celle-ci est comptabilisée selon la règle de décompte correspondante.
Comptabilisé uniquement en cas de succès
Les frais de signature ne sont facturés que lorsque le service de signature de code à distance a effectué la signature avec succès.
Les situations suivantes ne sont généralement pas comptabilisées :
- Échec de l'authentification.
- Erreur de paramètre.
- Certificat indisponible.
- Échec de la requête réseau.
- Le serveur n'a pas renvoyé le résultat de signature avec succès.
- Interroger le certificat.
- Interroger l'historique des signatures.
- Vérifier la signature.
- Supprimer la signature existante.
- Générer le 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 de l’exécution du traitement ultérieur, la signature distante déjà effectuée est toujours comptabilisée comme une signature réussie.
L'horodatage ne compte pas séparément
L'horodatage sert à prouver que la signature existait déjà à un moment donné ; il ne s'agit pas d'une nouvelle opération de signature de code.
Par conséquent :
Signature de code → génère des signatures
Horodatage → ne génère pas de signatures supplémentaires
Vérification de signature → ne génère pas de signatures
La réussite du service d’horodatage n’affecte que le résultat de l’horodatage du fichier de signature final ; cela ne signifie pas qu’une signature de code supplémentaire a été exécutée.
SignTool CLI
Utilisez sslTrus SignTool CLI :
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 réussi :
合计 = 3 次
Double signature avec SignTool CLI
Si vous utilisez la CLI standard de SignTool avec SHA-1 et SHA-2 activés en même temps :
signtool sign \
--cert-code CERT_CODE \
--file app.exe \
--sha1=true \
--sha2=true
Signature CLI double ordinaire est calculée comme une tâche de signature client unique :
GUI / SignTool CLI 双签 = 1 次
C'est l'endroit le plus facile à confondre entre le processus de signature client ordinaire et l'appel de signature sous-jacent de KSP.
Windows KSP
KSP est le mode d'intégration du fournisseur CNG Windows.
Lorsque Microsoft SignTool, MSBuild, Visual Studio, les outils de packaging Electron ou d'autres logiciels Windows appellent la signature de code à distance via KSP, le décompte est plus proche de :
底层远程私钥签名调用次数
Par exemple :
| Opération | Nombre de signatures |
|---|---|
Effectuer une signature SHA256 sur app.exe | 1 fois |
| Effectuer d’abord SHA256, puis ajouter SHA1 | 2 fois |
Signer respectivement 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 le fournisseur CryptoAPI Windows traditionnel.
Le CSP est également appelé par Microsoft SignTool ou d’autres applications Windows via le fournisseur pour le service de signature à distance.
Pour déterminer le nombre de signatures, il convient de se baser sur les opérations de signature à clé privée à distance réellement effectuées.
Si l'outil signe plusieurs fichiers séparément ou signe plusieurs fois le même fichier, chaque opération doit être calculée séparément.
Jarsigner
Lors de l’utilisation du fournisseur sslTrusJarsigner, la norme jarsigner appelle le service distant de signature de code pendant le processus de signature.
Généralement :
| Opération | Nombre de signatures |
|---|---|
Signature de app.jar | 1 fois |
| Signature de 3 JAR séparément | 3 fois |
| Exécuter une nouvelle signature sur le même JAR | Ajouter 1 fois de plus |
jarsigner -verify | 0 fois |
| Génération du keystore de validation | 0 fois |
Par conséquent :
每个 JAR 每次成功完成签名 = 1 次
Paquet d’installation
Le package d’installation doit être distingué selon :
- Les fichiers exécutables contenus dans le paquet d’installation.
- Le paquet d’installation lui-même.
Par exemple :
app.exe → signature 1 fois
installer.msi → signature 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 codes sources, de fichiers de ressources, d’images ou de fichiers de configuration contenus dans le paquet d’installation n’affecte pas directement le nombre de signatures.
Le point clé est :
最终到底有哪些产物被实际签名
Electron
Les outils de construction d’applications de bureau tels qu’Electron Builder et Electron Forge peuvent signer automatiquement plusieurs fichiers au cours d’un seul processus d’empaquetage.
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 :
| Produit | 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 convient de calculer en fonction du nombre réel de produits signés et du nombre de signatures exécutées pour chaque produit.
Si Electron utilise KSP et effectue une double signature sur le même fichier, celui-ci peut également générer deux signatures à distance.
Diagnostic rapide
Lorsque vous ne savez pas combien de signatures une seule construction va générer, vous pouvez vérifier dans l'ordre suivant :
1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？
Cela peut être simplement compris comme suit :
签名次数 = 成功完成的签名动作数量之和
Attention particulière :
GUI / SignTool CLI 双签 = 1 次
KSP 对同一个文件执行两次底层签名 = 2 次
Jarsigner 每个 JAR 每次成功签名 = 1 次
时间戳 = 0 次
验证签名 = 0 次
Serveur d'horodatage
Le signature de code utilise généralement aussi un service d’horodatage.
L’horodatage peut prouver qu’une signature numérique existait déjà à un moment donné, ce qui permet 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.
Les deux protocoles d’horodatage couramment utilisés pour la signature de code :
| Protocole | Description |
|---|---|
| Authenticode | Protocole d’horodatage hérité 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 |
Les scénarios modernes de signature de code privilégient généralement RFC 3161.
RFC 3161
La demande de certificat d'horodatage RFC 3161 envoie le condensé des données à horodater, et non le fichier original.
Flux de base :
代码签名
↓
计算待时间戳数据摘要
↓
发送摘要到 TSA
↓
TSA 返回时间戳令牌
↓
写入最终签名
Le jeton d’horodatage comprend généralement :
- Résumé des données.
- Horodatage de l’émission.
- Politique TSA.
- Signature numérique TSA.
Le serveur d'horodatage ne consomme pas de nombre de signatures de code sslTrus supplémentaire en raison de l'ajout d'un horodatage.
Serveurs d'horodatage couramment utilisés
Les points de terminaison suivants s’appliquent aux scénarios courants de signature de code.
Avant la mise en production, il convient de revérifier la documentation officielle la plus récente, 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 pour les scénarios modernes de signature de code Windows.
Voici un exemple de configuration Apache pour SSL.
--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
Peut être utilisé pour 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 par lots. Les systèmes de production doivent contrôler la fréquence des appels conformément à leur politique officielle actuelle.
DigiCert
http://timestamp.digicert.com
Prend en charge RFC 3161, peut être utilisé dans des scénarios de signature de code tels que Microsoft Authenticode.
Certum
http://time.certum.pl
Prise en charge :
- Authenticode
- RFC 3161
Les documents officiels de signature de code Certum couvrent les scénarios de signature Windows et Java JAR.
GlobalSign
http://timestamp.globalsign.com/tsa/r45standard
Le profil de signature de code GlobalSign actuel utilise cette adresse d’horodatage RFC 3161.
Il est déconseillé de continuer à utiliser les anciennes adresses GlobalSign qui ne figurent plus dans la documentation officielle actuelle de signature de code.
SSL.com
http://ts.ssl.com
Prise en charge de RFC 3161, pas de prise en charge du protocole d'horodatage Authenticode traditionnel.
Si l’outil de signature cible ou le système existant présente des restrictions de compatibilité avec l’algorithme de clé utilisé par la TSA, une validation réelle 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 |
Le « Support » dans le tableau décrit les capacités de protocole confirmées par les informations publiques du fournisseur correspondant.
Les politiques des services d'horodatage peuvent évoluer ; avant toute configuration en production, il convient de vérifier à nouveau la documentation officielle actuelle du fournisseur.
Service d'horodatage restreint
Certains serveurs d’horodatage fournissent bien un service RFC 3161, mais ils 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 un enregistrement préalable de l’adresse IP de sortie de l’appelant ; l’autorisation correspondante doit donc être effectuée avant l’intégration.
Apple
http://timestamp.apple.com/ts01
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 type test
Certains services publics RFC 3161 sont plus adaptés aux tests de protocole qu’à une utilisation directe comme TSA pour la signature de code en production.
Par exemple :
https://freetsa.org/tsr
Ces services peuvent utiliser leurs propres certificats CA et TSA.
Par conséquent, il ne faut pas présumer :
Windows
macOS
Java
其他代码签名验证器
Par défaut, sa chaîne de certificats est toujours approuvée.
L'environnement de production doit utiliser la plateforme cible pour valider réellement les artefacts signés.
Vérification de l’environnement de production
Avant d’ajouter un serveur d’horodatage à la configuration de production, il est recommandé de confirmer au minimum :
- La documentation officielle du fournisseur de services publie clairement ce point de terminaison.
- Le fournisseur de services prend explicitement en charge le protocole d'horodatage requis.
- Utilisez SHA-256 ou un algorithme de résumé d'horodatage plus fort.
- Le système cible peut vérifier la chaîne de certificats complète de la TSA.
- Le DNS, le proxy, le pare-feu et le réseau de sortie peuvent accéder de manière stable à la TSA.
- Le mode d'authentification, les limites de débit, les restrictions régionales et les conditions de service ont été confirmés.
- Utilisez les artefacts de signature réels pour terminer le test de vérification de signature.
Ne vous fiez pas uniquement à :
浏览器可以打开
HTTP 返回 200
Déterminer si le serveur d’horodatage est adapté à la signature de code.
Vous devez utiliser un véritable outil de signature pour envoyer la requête d’horodatage, puis effectuer une validation sur le produit final.
Conseils pour le choix de l’horodatage
Pour la signature de code SHA-2 sous Windows moderne, les services d’horodatage compatibles RFC 3161 sont généralement privilégiés.
Par exemple :
Microsoft
Sectigo
DigiCert
Certum
GlobalSign
Le choix final doit être considéré de manière globale :
- Système d’exploitation cible.
- Outil de signature.
- Chaîne de certificats TSA.
- Accessibilité réseau.
- Restrictions régionales.
- Limite de fréquence d’appel.
- Conditions de service.
- Accord de niveau de service.
- Résultat de vérification réel du produit signé.
Si le fournisseur de certificats a des exigences explicites concernant le service d'horodatage, vous devez suivre en priorité la politique de certificat correspondante et les exigences du fournisseur de services.
Modes d’intégration associés
Les différentes méthodes d'intégration utilisent les règles de nombre de signatures et d'horodatage présentées sur cette page :
| Scénario d’utilisation | Document |
|---|---|
| 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 |