Exporter certificat VBA avec clef privée

Résolu/Fermé
lenainjaune Messages postés 615 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 22 avril 2024 - 30 sept. 2010 à 18:55
lenainjaune Messages postés 615 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 22 avril 2024 - 1 oct. 2010 à 22:59
Bonjour à tous,

Je souhaite développer des petites macros sous Word 2003 pour les élèves de l'établissement.
Je veux que ces macros soient certifiées, déployables et je ne souhaite pas baisser le niveau de sécurité de Word.

J'ai réussi à créer un certificat VBA local au poste, et ça marche bien même avec un niveau de sécurité élevé (juste accepter à la 1ere ouverture et éventuellement cocher de ne plus demander à l'avenir).

Vient la phase de déploiement, et là je ne sais pas comment exporter ...

J'ai glané qu'on pouvait le faire depuis Internet Explorer ( https://certification.lcl.fr/configuration/sauvegarde/export-ie/ )
Mais quand j'exporte le certificat la clef privée ne l'est pas ...
Le radio bouton "Oui, exporter la clef privée" est grisé et en dessous est indiqué:
"La clef privée associée est marquée comme non exportable. Seul le certificat peut être exporté."

J'ai aussi essayé par la console de gestion des certificats (sont-ce les mêmes ???)
certmgr.msc mais le même problème se pose.

Bref ... je pédale un peu dans la choucroute ...

J'ai lu sur les liens suivants, que d'une part il est possible de partager un certificat entre plusieurs PC et que d'autre part on peut le gérer sous domaine Active Directory (je suis sous domaines AD):
http://office.microsoft.com/fr-ca/word-help/creer-votre-propre-certificat-numerique-HP005249558.aspx
https://docs.microsoft.com/en-us/previous-versions/office/developer/office2000/aa141471(v=office.10)?redirectedfrom=MSDN

Quelqu'un aurait il une idée pour exporter le certificat avec sa clef privée ?
Ou bien s'il existe la possibilité de modifier un certificat pour que son export de clef privée soit possible ?
Ou bien si c'est possible sans trop de manipulations de centraliser sous AD ?
Ou bien s'il y a une autre solution (sans toucher à la sécurité toutefois) ?

Désolé, si je ne suis pas clair ... mais là j'ai de la purée à la place du cerveau ...

cordialement
lnj
A voir également:

2 réponses

lermite222 Messages postés 8702 Date d'inscription dimanche 8 avril 2007 Statut Contributeur Dernière intervention 22 janvier 2020 1 190
30 sept. 2010 à 20:04
Bonjour,
Eventuellement mettre tes macros en "Macros complémentaires" (.xla)
A+
0
lenainjaune Messages postés 615 Date d'inscription mercredi 7 mai 2008 Statut Contributeur Dernière intervention 22 avril 2024 47
1 oct. 2010 à 22:59
Bonjour lermite222 et merci pour ta réponse,

Les fichiers *.xla c'est pour Excel, non ? Moi c'est pour Word que je cherche ...

Néanmoins ton idée m'a bien inspiré ...

J'ai repensé au fait qu'en aidant mes élèves, j'ai constaté qu'ils avaient dans leur boite Enregistrer sous... un lien pour aller sur mon lecteur réseau alors qu'ils n'en n'avaient pas l'utilité, puisqu'ils n'avaient pas les droits d'accès ...

Je me suis souvenu que je l'avais créé un jour pour mes besoins et que plus tard je m'étais servi de mon paramétrage afin de déployer mon profil Office ... et que ce raccourci avait subsisté !
Et du coup je me suis demandé si le Normal.dot ne serait pas suffisant !
Et bingo ... il l'est !!!
Donc en définitive, il suffit de remplacer le Normal.dot de l'utilisateur pour lui donner accès aux nouvelles macros et ce sans besoins de certificats et sans besoin non plus de baisser la sécurité !

Pour info sous Office 2003, Normal.dot se trouve généralement ici:
C:\Documents and Settings\<nom_utilisateur>\Application Data\Microsoft\Modèles

Pour ce qui est du déploiement sous domaine Active Directory pour des profils itinérants, il suffit d'ouvrir la session du profil par défaut, de s'assurer que le profil Office existe déjà (ouvrir Word et enregistrer son document est suffisant pour le créer), pour enfin remplacer le Normal.dot créé par celui que l'on veut déployer. Ne reste plus qu'à remplacer l'ancien profil par défaut par le nouveau (avec le nouveau Normal.dot). Il faut enfin supprimer les anciens profils utilisateurs (sur les clients et le serveur) pour que le nouveau profil soit pris en compte à la première ouverture de session de l'utilisateur.

Autre piste : dans le script d'ouverture de session, faire un bête copier/remplacer du Normal.dot, mais bon la synchronisation aura lieue à toute les ouvertures de session de profil itinérant.

Problème résolu !

Je me demande toutefois, si le simple fait de remplacer le Normal.dot n'est pas une faille de sécurité, puisque non soumis à des certificats ...

merci encore pour ton aide !
lnj
0