Utiliser un certificat pour signer son code

[30/12/2014]L’utilisation des certificats est une chose un peu confidentielle, cela parait compliqué, cher et nébuleux. Pourtant c’est très simple à condition de bien comprendre comment se servir du fichier fourni par l’autorité de certification…

Pourquoi des certificats ?

Les certificats sont les descendants modernes des sceaux que les autorités gardaient jalousement et dont elles se servaient pour authentifier des documents. Ces sceaux pouvaient être des timbres pour créer une empreinte dans de la cire chaude ou des tampons encreurs ou gaufreurs  comme l’administration en utilise encore aujourd’hui. Ces sceaux permettaient de valider l’identité du signataire d’un document. De l’édit royal au passeport en passant par le décret ministériel ou le permis de conduire, l’extrait K-Bis du registre du commerce, l’extrait de casier judiciaire du ministère de la justice, … l’Etat a utilisé et utilise encore des sceaux pour certifier des documents et en prouver l’authenticité.

Il n’est pas possible de “gaufré” un mail, pas plus qu’il n’est possible de mettre une empreinte de cire sur un logiciel ou d’encrer un setup…

De là est né l’idée de fabriquer des sceaux électroniques basés sur la cryptographie pour garantir l’identité de la source d’un logiciel ou celle d’un serveur Web.

Puisque ces sceaux électroniques permettent de garantir l’identité d’une personne (morale le plus souvent) il en découle plusieurs utilisations qui bien évidemment n’existaient pas pour la version physique. Par exemple un certificat électronique peut être utilisé pour garantir et sécuriser une connexion entre un poste client et un serveur sur Internet. C’est le fameux petit verrou ou cadenas affiché par la plupart des browsers lorsque la connexion est ainsi validée.

SSL est une utilisation parmi d’autres et il est aussi possible de certifier une identité dans d’autres contextes. C’est le cas des logiciels.

Code ou installeur ?

Une application c’est d’abord du code puis cela devient un exécutable. Ce dernier est généralement déployé au travers d’un installeur (setup).

Ces deux facettes donnent lieu à deux types de certification : la signature du code et la signature de l’installation.

Signer un installeur (setup) dans le monde Microsoft se fait en utilisant un certificat lorsqu’on créé un déploiement Click-Once.

Le fichier fourni par l’autorité de certification est utilisable directement pour peu qu’on ait acquit un certificat de signature de code, ce qui diffère des certificats pour SSL par exemple.

L’intérêt est évident, un installeur signé pourra être déployé chez des tiers qui, s’ils font confiance à l’émetteur, auront la certitude grâce à la signature que le setup provient bien de ce dernier. Si vous faites confiance à Microsoft et si un fichier d’installation est signé par un certificat vous assurant que ce setup provient bien de chez Microsoft et qu’il n’a pas été modifié par un tiers alors vous pouvez installer le logiciel en toute confiance. Si l’installeur n’est pas signé ou bien si la signature n’est plus valable, vous aurez raison de vous méfier.

Les certificats pouvant être installés dans un “magasin” sous Windows, il est ainsi possible de se créer une bibliothèque de certificats auxquels ont fait confiance systématiquement. Dès lors les logiciels provenant des sources utilisant ces certificats s’installeront facilement et sans question ni validation spéciale.

Il y a donc un grand intérêt pour une entreprise à signer ces installeurs car cela permet aux clients d’être certains de la source. Il y a aussi une question d’image de marque : si un hacker peut glisser un virus ou autre ver dans un module d’installation qui ressemble à l’un de vos logiciels c’est votre image de marque qui sera tâchée parfois pour toujours. Un installeur signé ne peut pas être bricolé et votre image de marque sera préservée.

Pour le code les raisons et l’utilisation même de la signature sont très différentes.

Signer du code

Signer du code est une autre utilisation des certificats. Ici les raisons sont différentes, plus techniques. Notamment la signature d’un code .NET permet de créer des “noms forts” (strong names) pour les espaces de noms.

Visual Studio permet de signer un code en fabricant un fichier “pfx” automatiquement. Ce dernier est protégé par un mot de passe. Alors pourquoi passer par un certificat ?

La différence se joue dans la “qualité de l’authentification”. N’importe qui peut avec Visual Studio signer un code avec un “pfx”. De l’éditeur de logiciels très sérieux au bricoleur, de l’entreprise la plus sérieuse au premier margoulin venu..

En utilisant un certificat émis par une autorité de certification pour signer un code .NET on offre quelque chose de plus : l’assurance que l’identité de l’émetteur est validée. Et cela fait toute la différence.

Dans certains contexte les noms forts sont obligatoires, sur certaines machines seuls du code signé peut être autorisé à effectuer certaines opérations. Si la clé de signature n’a pas de certification le code même signé ne sera pas autorisé à s’exécuter. Seul du code signé par un certificat émis par une autorité valide le pourra.

Typiquement il faut savoir qu’on signe avec un nom fort ce qui doit être partagé, donc des DLL et non un EXE. Et cela n’a d’intérêt principalement que si les DLL en question doivent être déployées dans le GAC ou bien s’il s’agit de ressources partagées entre plusieurs logiciels.

La signature d’un code .NET, la création de noms forts n’est pas le sujet de cet article je n’irais pas plus loin sur ce sujet ici. Ce qui compte c’est de comprendre la différence qui peut exister entre un nom fort créé avec une clé “pfx” générée sous VS et un nom fort signé par un certificat émis par une autorité de certification.

Est-ce cher ?

Prenons l’autorité Digicert, pour un certificat de signature de code le prix est de $223/an pour une année et de $178.33/an si on achète un certificat valable 3 ans.

Est-ce cher ? Oui et non. Si vous êtes juste un développeur amateur ou un prestataire faisant de la sous-traitance cela ne vous servira pas à grand chose et donc oui c’est cher jusque pour s’amuser chez soi…

Si vous éditez des logiciels, si vous créez des logiciels au sein d’une grande entreprise, d’un groupe, certifier les applications et les installations pour moins de 200 euros par an devient réellement un investissement ridicule au regard du service rendu. Donc non, ce n’est pas cher.

Donc acheter un certificat n’est pas cher et devrait être systématique pour protéger les applications qu’on distribue.

Est-ce compliqué ?

Chaque autorité de certification possède ses propres méthodes d’enquête pour valider l’identité d’un demandeur de certificat. Dans certains cas l’opération peut être longue, tout dépend des preuves que le demandeur peut amener.

J’ai testé le processus avec Digicert qui offre aux MVP la possibilité d’obtenir gratuitement un certificat. Ils sont intelligents car sans ce geste j’avoue que je n’aurais pas investi 200€ juste pour écrire un article ici, même si j’aime mes lecteurs .

Disposant d’une société (e-naxos) et ayant une présence officielle attestée évidente, le processus de certification a été très rapide, en moins de 48h après quelques échanges de mails et d’informations le certificat était disponible et utilisable. Il faut dire que le profil MVP géré par Microsoft additionné au site e-naxos et ses informations liées au nom de domaine via le registrar et tout le reste me permettent de facilement prouver mon identité. Mais comme on suppose qu’un certificat n’a d’intérêt que pour une entreprise ou un éditeur de logiciels, on peut affirmer que tous ces utilisateurs potentiels de certificat n’ont aucune difficulté à prouver leur identité.

Donc ce n’est pas compliqué d’obtenir un certificat, c’est même plus rapide que je ne le pensais. En tout cas chez Digicert que j’ai pu tester.

Est-ce vraiment utile ?

Est-ce cher ? non. Est-ce compliqué ? non. Est-ce vraiment utile ? Poser la question ici ne sert qu’à compléter logique la progression induite par les deux premières mais en réalité toute l’introduction de cet article y répond et la réponse est évidente, oui c’est vraiment utile.

Il est utile de pouvoir créer des noms forts .NET signés par une clé issue d’un vrai certificat, il est tout aussi utile de signer un installeur ClickOnce pour prouver qu’un logiciel est sain, d’origine, non bricolé, et que son créateur est bien identifié.

Est-ce pérenne ?

Autre question intéressante. Puisque les certificats s’achètent à l’année, comment la pérennité fonctionne-t-telle dans ce contexte ? Est-il nécessaire de re-signer tous les setups chaque année ?

Il y a deux points de vue à considérer : le premier concerne l’image de marque de l’émetteur. Si l’utilisateur installe un logiciel dont le certificat n’est plus valable ce n’est pas un bon signal, l’émetteur existe-t-il toujours, a-t-il encore une activité ? Installer un logiciel d’une société qui n’a pas les moyens de renouveler son certificat n’est pas une bonne UX. Donc de ce point de vue là il faut renouveler le certificat pour que d’année en année il reste valide. Mais attention, renouveler le certificat ne signifie pas signer à nouveau les setups, c’est juste un acte auprès de l’autorité de certification.

Mais il existe un autre point de vue : signer un setup n’a rien à voir avec certifier une identité SSL pour un site Web. Un site Web dont le certificat n’est plus valide c’est problématique car c’est toute la sécurisation de la connexion qui peut être mise en doute. Avec un setup les choses sont différentes, ce qui compte c’est de pouvoir prouver que ce setup là a bien été émis par la société X. Il s’agit d’une vérité intemporelle : si le setup a bien émis par X, alors même dans 10 ans, et même si le certificat n’a pas été renouvelé, la signature dira que c’est bien X qui a émis le setup à l’époque et qu’il s’agit donc bien d’un setup légitime et intact.

Donc du point de vue technique un certificat de signature de code est toujours valide car ce qu’il prouve est intemporel, il constate un acte historique qui ne peut changer avec le temps. Du point de vue de l’image de marque un certificat non renouvelé ne donne pas une excellente impression et il faut en tenir compte selon comment le logiciel doit être exploité (vendu à des clients ou utiliser en interne d’un groupe ou d’une entreprise).

Un peu de lecture

Il existe un bon article sur MSDN qui précise comment et pourquoi signer un code ou un installeur avec un certificat, le lecteur intéressé par le sujet y trouvera donc une information fort utile : 

ClickOnce Manifest Signing and Strong-Name Assembly Signing Using Visual Studio Project Designer's Signing Page

Un autre article du blog de Michael Johnson explique de façon rapide comment signer un logiciel WPF avec un certificat : Signing WPF software with an Authenticode Certificate

Astuces pratiques

il pourrait s’agir ici de répondre à la question “est-ce facile ?”…

La réponse est oui et non à la fois. Oui une fois qu’on sait comment se servir du fichier fourni, non quand on patauge avec VS qui refuse le fichier original !

Ayant testé le processus je peux vous livrer quelques informations qui vous feront peut-être gagner du temps…

Une fois le certificat obtenu Digicert vous envoie une confirmation et une page de téléchargement. On peut y récupérer le fameux certificat.

On cherche partout sur son disque, mais aucun fichier n’a été téléchargé… Qu’est-ce-qui c’est passé ? Le certificat est perdu ? … Tant de questions angoissantes !

En réalité le certificat téléchargé est installé par le browser dans le magasin de certificats. On n’a donc rien récupéré, c’est juste du vent, pas de fichier… rien de “palpable” si tant est qu’un fichier informatique soit palpable !

En bricolant on arrive à extraire un fichier mais ce dernier n’est pas reconnu par Visual Studio pour signer un code. La clé du certificat peut être exportée, détruite ou réimportée grâce à “certmngr.msc”, c’est déjà ça, mais pourquoi VS refuse-t-il de s’en servir pour signer le code ?

Le message d’erreur est “Impossible de trouver le certificat et la clé privée pour le déchiffrement”.

Avec ça on est bien avancé. j’adore ce genre de message d’erreur. C’est du français, on comprend chaque mot, mais la phrase… ne dit rien du tout car elle ne correspond pas réellement à ce qu’on vit ! Ici on a bien le certificat et on vient juste de le sélectionner dans le disque dur donc on sait que VS peut le trouver. Donc il faut tel le saumon qui remonte la rivière péniblement tenter de remonter à la source de l’erreur pour en comprendre la nature.

Je vous ferai grâce de mes recherches sur le Web souvent infructueuses (peu de gens visiblement signent avec des certificats et encore moins en parle !).

La version courte consiste à exporter la clé en pfx mais SANS la chaîne de certificats. Juste une case à cocher convenablement donc. Une fois une telle clé exportée VS peut s’en servir pour signer un code (nom fort).

Si on exporte avec la chaîne de certificats le fichier obtenu peut être utilisé avec ClickOnce mais pas pour signer du code.

Dernière astuce, Digicert met à disposition une application de gestion des certificats “DigiCertUtil.exe” qu’il faut récupérer sur leur site. C’est plus agréable à utiliser que l’usine à gaz de Windows, et on peut ici aussi exporter les clés ce qui rend l’opération plus ‘user friendly’.

Conclusion

Un certificat de signature de code c’est utile, ce n’est pas cher, pas compliqué à obtenir et une fois quelques astuces connues c’est très facile à utiliser.

Si on est dans une position où on distribue du code, qu’il s’agisse de composants sous forme de DLL, de fichiers à installer dans le GAC ou bien s’il s’agit de certifier un setup, il n’y a aucune raison de ne pas utiliser un certificat. Cela concerne donc principalement les éditeurs de logiciel mais aussi les entreprises ou les groupes au sein desquels on est amené à déployer DLL ou applications.

Si c’est juste pour faire joujou tout seul dans son coin, cela n’a aucun intérêt. Mais ce n’est pas conçu pour ça, ça tombe bien !