Hi all! I have a package, which has an issue i can't fix. The package uses a DOT file, with a macro inside. The macro has a certificate. To install the certificate, i used the certmgr.exe as explained on the site (http://itninja.com/blog/view/autologon-during-unattended-nt-installation6). However, i'm still getting a messagebox that the publisher isn't trusted, and the certificate needs to be installed. Any way to fix this? I took the CER file from a machine where it was added to the trusted publishers, still, it's giving me those message boxes. The user still needs to install the certificate. It works when the certificate is installed, but it would be nice to have a package without user dependencies at all. Anyone know of a way to get rid of this? Macro security is set to medium by the way. TIA
0 Comments   [ + ] Show Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.



Unfortunately that tip will not put the certificate in the correct store for a trusted publisher.

I think the command line would be more like: Certmgr.exe -c YourCertificate -s TrustedPublishers -add

I cannot garuntee it because I don't have the documentation from the package that I did this in. You should double click the certificate and made sure it is valid before doing any further work on this. If that works then use the certmgr.msc to import the certificate into the trusted publishers store. Made sure you specify where to put the certificate. If the OS still does not trust the certificate maybe there is a policy that is causing interferance.
Answered 12/13/2005 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
This is from Office XP Enterprise Security and Security Settings and Related System Policies
The first one I think helps to describe the issue and the second one can walk you through how to fix that.
Let me know if this helps.

Applying Macro Security

Many organizations have come to depend heavily on macros. Unfortunately, macros present an attacker with a way to run malicious code on a user's desktop as soon as an Office file is opened. All the attacker needs to do is embed a malicious piece of code in the application and then e-mail it to people inside your organization. Because of this, macro security has become a serious issue for any enterprise.

Fortunately, Office XP applications are shipped with a default macro security setting of High. This setting enables only digitally signed macros from trusted sources that have valid certificates. Office XP disables all unsigned macros when a user opens a document.

If a user opens a document containing a signed macro from an unknown source that has a valid certificate, Office XP opens a dialog box containing information about the certificate. The user decides whether to accept the certificate and enable the macro. This is where a clear network security policy comes into play: Best practice is to define in advance the rules your users should follow when accepting certificates from unknown sources.

You can help maintain control over this process by locking the trusted source list and preventing a user from adding new certificates to the list. This will disable any macros associated with a document unless the digital signatures appear on the trusted source list. Additionally, if Office XP cannot validate a signed macro's certificate, or if the certificate is corrupted, revoked, or expired, Office XP will disable those macros in the document and warn the user.

By enabling you to determine how signed macros are handled, Office XP gives you greater security in your work environment. You can implement organization-wide macro security settings by using Custom Installation Wizard, Custom Maintenance Wizard, Office Profile Wizard, or the System Policy Editor (you'll need an enterprise edition of Office XP if you want to take advantage of the Custom Installation Wizard and Custom Maintenance Wizard).


Application Security key

Through the use of the application Security key, you can instruct Office to help set macro security for each application or for the trusting of all installed add-ins. The basic key consists of the following, where <APP> can be any or all of the listed applications (Word, Excel, Access, PowerPoint):


The parallel keys as specified through a policy setting are:



The Specify Office Security Settings page of both the Custom Installation Wizard or Custom Maintenance Wizard contain the check box Trust all installed add-ins and templates. When this check box is set to checked, it creates the non-policy version of this key and adds the value DontTrustInstalledFiles to the key. When this policy is set to 1, this registry value instructs the Office application listed in the <APP> portion of the key to trust all currently installed add-ins and templates (and their respective macros) within specific folders created by Office applications. It does not accept all currently installed add-ins and templates on the user's computer, only those installed by specific Microsoft applications. If you use either HKLM or HKCU when setting a registry entry for a policy, you will prevent users from changing the setting.

Value name: DontTrustInstalledFiles

Data type: REG_DWORD

Value data:

0 // Do not trust Installed Files

If you use the Specify Office Security Settings page of either the Custom Maintenance Wizard or the Custom Installation Wizard, and change the Default Security Level for an application, this process is the same as using the Security dialog available through the application's user interface. Use of this key sets the macro security level for each application specified in the <APP> portion of the key to the respective value data listed below.

<APP> = Word, Excel, Access, PowerPoint, Publisher, Outlook

Value name: Level

Data type: REG_DWORD

Value data:

1 // Low

2 // Medium

3 // High
Answered 12/13/2005 by: Foleymon
Orange Senior Belt

Please log in to comment
Answer this question or Comment on this question for clarity