Résumé

  • Renouveler ou remplacer un certificat de signature modifie la clé des futures versions, mais n'annule pas automatiquement les binaires correctement signés et horodatés avant son expiration.
  • La bascule doit être suivie artefact par artefact : empreinte, certificat, jeton RFC 3161, date effective de révocation, lieu de distribution et décision observée du vérificateur.

À midi, un éditeur fait passer sa chaîne de publication sur un nouveau certificat. La première compilation est correctement signée et le tableau de bord devient vert. Pourtant, un exécutable produit la veille reste sur un miroir régional, porte un horodatage valide et continue d'être accepté chez les clients.

Cette situation n'est pas nécessairement une anomalie. L'erreur consiste à confondre la rotation du certificat avec l'achèvement de la transition de confiance.

La signature relie des octets à une identité de signature. L'horodatage ajoute une affirmation différente : une autorité de temps atteste qu'une empreinte existait à un moment déterminé. Cette combinaison peut permettre au vérificateur d'accepter une signature après l'expiration normale du certificat. Elle peut aussi séparer les logiciels signés avant et après la date effective de révocation d'une clé compromise.

Le certificat possède donc deux fins opérationnelles. La première est son expiration, au-delà de laquelle il ne devrait plus servir à produire une nouvelle signature valide. La seconde est le moment à partir duquel le vérificateur ne doit plus reconnaître son autorité. Ces dates peuvent coïncider, mais ce n'est pas une propriété automatique du système.

Ce que prouve réellement l'horodatage

La RFC 3161 construit le protocole autour d'un MessageImprint, composé de l'identifiant de l'algorithme de hachage et de la valeur hachée. L'autorité vérifie l'algorithme et la longueur, sans examiner le programme sous-jacent. Son jeton contient une politique, un numéro de série unique et genTime, puis il est signé avec une clé réservée à cet usage.

Le jeton ne déclare donc pas qu'un logiciel est sûr. Il prouve qu'une empreinte précise a été présentée selon une politique donnée. Il ne prouve ni la maîtrise de tous les chemins de signature, ni la disparition d'une ancienne version sur les miroirs.

La vérification reste une opération active. La RFC demande de contrôler la réponse, le certificat de l'autorité d'horodatage, l'empreinte, l'algorithme, la signature et la cohérence temporelle. Microsoft matérialise cette séparation dans SignTool : sign, timestamp et verify sont des commandes distinctes. Le mode RFC 3161 utilise /tr pour l'adresse du service et /td pour l'algorithme d'empreinte temporelle.

La documentation ClickOnce donne l'effet concret : avec un horodatage valide, une application peut continuer d'être acceptée après l'expiration de son certificat. C'est utile, car un éditeur ne devrait pas devoir signer de nouveau chaque ancien paquet sain. Mais cette persistance rend insuffisante toute mesure limitée au prochain build.

La révocation trace une frontière temporelle

Les exigences de base du CA/Browser Forum pour la signature publique de code imposent aux autorités concernées d'exploiter un service conforme à la RFC 3161, de recommander son usage et de refuser les empreintes SHA-1 pour les demandes d'horodatage.

Elles expliquent aussi pourquoi la révocation n'est pas un simple effacement. Un certificat peut couvrir un objet ou des milliers ; sa révocation peut invalider du code sain autant que du code suspect. L'autorité doit commencer l'enquête sur un signalement plausible sous vingt-quatre heures. En cas de compromission, la date devrait correspondre au premier moment suspect étayé.

Cette date peut délimiter les logiciels touchés. Les exigences indiquent que les objets horodatés avant la date de révocation devraient continuer d'être traités comme valides. Il s'agit d'une règle de programme, pas de la preuve que toutes les plates-formes appliquent exactement le même résultat.

L'autorité d'horodatage possède sa propre frontière de défaillance. La RFC distingue une cessation normale d'une compromission de clé. Lors d'un retrait sans compromission correctement signalé, les anciens jetons peuvent rester valides. Si la clé d'horodatage est compromise, ils ne peuvent plus être acceptés sans autre preuve ; le journal d'audit ou un second horodatage indépendant peut devenir décisif.

Le bon dénominateur est l'ensemble des artefacts distribués

L'inventaire des certificats ne suffit pas. Il faut savoir quel artefact a été signé, quel jeton lui est attaché, où il demeure disponible et comment les vérificateurs cibles le traitent.

Ce périmètre inclut le téléchargement principal, les dépôts de paquets, les caches, les magasins logiciels d'entreprise, les canaux de mise à jour, les installateurs hors ligne et les supports de restauration. Retirer un fichier de la page la plus récente ne le retire pas de ces autres surfaces. À l'inverse, révoquer sans localiser les anciens paquets sains peut transformer une mesure de sécurité en panne évitable.

Le contrôle minimal est un registre de bascule d'autorité des artefacts. Pour chaque empreinte, il associe build et version, certificat et numéro de série, algorithme de signature, jeton et autorité d'horodatage, genTime, expiration, statut et date de révocation. Il relie ensuite ces données aux lieux de distribution, à l'état de retrait ou de remplacement, à la politique du vérificateur et au résultat observé.

La clôture devient alors falsifiable : la production future utilise le signataire voulu ; chaque ancien artefact conservé possède une décision explicite ; chaque artefact retiré est absent des surfaces maîtrisées ; des vérificateurs représentatifs donnent le résultat attendu.

Limites de la preuve

La RFC 3161 décrit le jeton et sa vérification, sans certifier un prestataire précis. Les exigences du CA/Browser Forum ne rendent pas identiques tous les systèmes d'exploitation et gestionnaires de paquets. La documentation Microsoft établit le comportement documenté de SignTool, Authenticode et ClickOnce, pas celui de tout l'écosystème logiciel.

Aucune compromission n'est alléguée ici. L'expiration, la rotation, la révocation du certificat et la défaillance de l'autorité d'horodatage sont quatre événements différents ; une transition défendable les conserve séparés.

Sources