Exporter certificat VBA avec clef privée [Résolu/Fermé]

Signaler
Messages postés
393
Date d'inscription
mercredi 7 mai 2008
Statut
Contributeur
Dernière intervention
14 février 2020
-
Messages postés
393
Date d'inscription
mercredi 7 mai 2008
Statut
Contributeur
Dernière intervention
14 février 2020
-
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

2 réponses

Messages postés
17380
Date d'inscription
dimanche 8 avril 2007
Statut
Contributeur
Dernière intervention
22 janvier 2020
1 090
Bonjour,
Eventuellement mettre tes macros en "Macros complémentaires" (.xla)
A+
Messages postés
393
Date d'inscription
mercredi 7 mai 2008
Statut
Contributeur
Dernière intervention
14 février 2020
41
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