Digital Signature for WORD macros

[oscarmok]

We are planning to install Office XP Pro to all our users in the
company. We noticed that be default, macro security set to high.
(and we like that idea). Our developer requires to have digitally
sign all their macro codes so that all users can use the macros. We
don't want to pay $500USD for verisign per code, I was told that
Microsoft W2K comes with certificate service. I have been looking
everywhere to get step by step instruction and couldn't find any. I
know selfcert.exe will do the trick but not for 1200 users. Can
someone list out the instruction how it works. Is there a way that
developers can obtain the certificate without going thru the
administrator.

Please HELP!!!

 

[dz]

I think selfcert is the only thing you can do on the fly.
And, I agree - even 10 computers is too many to use it
with.

However, as far as macro security, my clients have all had
to place it to low anyway, as many third party software
apps won't run if it isn't (i.e., Adobe, document
management programs, etc.) As long as the server has
virus protection, and the individual computers all have
proper virus dat updating, it's okay to leave it at low.
My clients haven't had any problems doing so.

dz

 

[Steve Lang]

It's my experience that the if you use the self cert for your code, your
users will always get the message box about the file containing macros; the
"always trust macros from this source" checkbox is dimmed. Only the computer
that created the selfcert can "trust" a self cert certification.

Steve

 

[Lars-Eric Gisslén]

Oscar,

I posted this message on microsoft.public.office.developer.vba a while back

You can download the files from this location:
http://msdn.microsoft.com/library/d...n-us/security/security/cryptography_tools.asp

Regards,
Lars-Eric

------------------------------------------------------------
Wes,

Below is a reply in a private email to another guy in the news group. The
files mentioned should be included in the Authenticode SDK. You should me
able to download all files you need from msdn.microsoft.com

-------------------------------------------------------
Ok, I'll try to straighten all this out. I understand that all about
certificates can raise a lot of questions.

First of all, there are a number of certificte issuers (also called
Certificate Authorities, CA) that are trusted as issuers. That means in
general that they don't issue certificates to people that can't be traced
back to the issuer (for verification of the certificate, it might be
revoked). If it's a class 3 certificate they take neccessary measurements to
assure the person/company they issue the certificate to really are who they
clain to be. To get a class 3 certificate as a private person you usually
have to indentify yourself with an ID card before you get your certificate,
or are know to the issuer by other means.

Microsoft has picked a number of issuers (CA) as trusted and installed their
root certificates with Windows. To take a look at those root certificates
you (I assume you have the IE icon on your desktop) can right click on the
IE icon on the desktop. Choose properties in the popup menu. Select the
Content tab (I think as I have the Swedish version) and on that page you
should have a button marked Certificates... Click on that button. In the
dialog you get you should select the rightmost tab, marked something like
Trusted Root Certificates. There you have a list trusted root certificates
installed on your computer. Those root certificates are mandatory for
verifying your personal certificates. I'll explain why. When a CA issue a
certificate to you, your certificate will be signed by the CA's root
certificate. If you get a certificate from Verisign it will for sure be
signed by one of the root certificates from Verisign installed on your
computer. We use certificates from Verisign as we know that the root
certificate from Verisign is on all Windows computers.

So, when you have signed something with your client certificate and when
Windows will try verify your certificate it can see which root certificate
your certificate was signed with and tries to verify your certificate
against the root certificate. If your certificates checksum will still match
a new calculated checksum using the root certificate your certificate will
be accepted by windows. That's why you need a root certificate on the
computer so your certificate used for signing can be validated. If the root
certificate is missing your certificate can't be trusted as it can't be
verified against a trusted source. Otherwise you could issue a certificate
to Donald Duck and who would trust that?

To get all working you should create your own root certificate. Create a
folder where you keep your cert util files which will also contain your root
certificate. DON'T forget the passwords you enter during the process!!!!

From the command promt you can type this command:
makecert -n "CN=Your company name" -r -sk mykeystore -ss root rootcert.cer

('-sk mykeystore' will store a private key in your computer for the root
certificate)
You will be asked to install the certificate, you need to accept that to be
able to create the client certificate!

Now you will create your client certificate that will be signed by your root
certificate.
makecert -is root -ic rootcert.cer -sv privatecert.pvk -n "CN=Your Name" -m
24 privatecert.cer

('-m 24' means the certificate will expire after 24 month, industry default
is 12 month and privatecert.pvk will be your private key file)

Now you should have three files; rootcert.cer, privatecert.cer and
privatecert.pvk. The rootcert.cer is the rootcertificate that needs to
installed on all client machines to verify your certificate used when
signing. That's simple, just copy the certificate to each machine and then
just double click on the file and follow the wizard.

Now it's time to create the PFX file that will combine privatecert.cer and
privatecert.pvk into one file so it can be imported to your computers
certificate store and be used for VBA signing. (privatecert.cer and
privatecert.pvk can now be used to sign exe, com, dll, ... files using
signcode.exe)

Use this command at the command promp:
pvkimprt -PFX privatecert.cer privatecert.pvk

Choose to export your private key and a PFX will be the default format. Just
follow the wizard for each step. After the wizard has finnished you should
have your PFX file. Double click on the PFX file to import the certificate.
Choose strong protection in the wizard and not to export the private key.

Now, backup rootcert.cer, privatecert.cer and privatecert.pvk rootcert.cer
will be needed if you want to create a new certificate signed by your root
certificate/key. You can not move the root certificate to another computer
and sign another certificate as the private key is on your computer where
you created the root certificate.

Now you should be ready to sign your VBA projects.

Good luck!
------------------------------------------

Regards,
Lars-Eric

This may not be the correct place to post this, if not
could you point me to where I would ask such questions?
Thanks

My question is this, and forgive me for being so ignorant,
how do I make a certificate that will be valid throughout
our company. So far I only know how to make a certificate
that works on a single computer. We have computers on a
network, as well as standalone. Shouldn't people who open
my file on different computer be asked if they wish to
trust my certificate?

Thanks in advance for helping me out.

 

[JGM]

Hi Steve,

Actually, unless it was a fluke, I installed a certificate I had created
with Selfcert on another machine (through Internet Explorer) and it worked
well, then "signed" my code with the certificate and sent it to the other
user, and it worked fine... So what did I do wrong? Why is it that it didn't
work for you? Again, I must say that I tried it only once, so... it might
have been a fluke!

Cheers!

 

[Steve Lang]

Hi Jean-Guy,

It is possible to use Self-Cert in XP, but you cannot avoid the security
warnings, short of setting the security level to Low. (Not something I would
do.) To quote from Microsoft (This is from the help when I typed in "self
cert"):

"Because a digital certificate you create yourself isn't issued by a formal
certification authority, macro projects signed by using such a certificate
are referred to as self-signed projects. Certificates you create yourself
are considered unauthenticated and will generate a warning in the Security
Warning box if the security level is set to High or Medium."

In my environment, the constant security warnings were unacceptable, and as
a result, the use of Self-Cert signatures was now out the window. Looking at
the logic behind it, I can understand why. Most people would use a simple
signature (e.g. their name) as the certificate name (I did!). But consider
the following scenario:

You have self-certified your macros and your users have added your signature
to their list of trusted sources. Someone outside your organization (or
someone planning to leave) knows your signature and creates his own matching
yours. He then sends files signed with his self-cert (which matches yours)
to your user with malicious payloads. Since your users have trusted that
signature, the code will run as intended, with the user getting no warning.
Bad news.

That may be a far-fetched scenario, but that is the reasoning behind
Microsoft's actions.

Cheers yourself!

Steve

 

[JGM]

Hi Steve,

I knew Microsoft was kind lame...but this is unbelievable...

All SelfCert does is take the name we give to a certificate and uses that
public certificate name to check for security? This is beyond useless! I
thought that some encryption was happening behind the scene when the
certificate was being created (and when signing a project with that
certificate) so that if someone else creates a new certificate with the same
name, the actual key would have been different... so they could not run
their code against my certificate unless theirs was installed parallel to
mine...

I understand that certification by a third party is necessary when
distributing stuff over the Internet or when selling at large... But for
cases of in-house cetification purposes, SelfCert should be adequate. Now,
if I understand your explanation correctly, it cannot even be used in those
cases...
I'll be damned!

Then why the hell do they provide SelfCert...? It is absolutely useless and
dangerous to boot! I wonder what percentage $ Microsoft gets from Verisign
(or is Verisign run by Bill Gates' cousin?)!

Thanks for the info.

 

[oscarmok]

Thank you so much for all kinds of suggestions. Unfortunately, our
corporation policies require all Office XP macro security to set as
HIGH.

Isn't it true that Microsoft server comes with Certify Authority
Services? Am I in the right track to getting the certification? If
so, I am looking for step-by-step instruction on how it works.
Selfcert.exe really not a pleasent solution for 1200 users across East
to West coast. I can't imagine each time our developer create a new
macro and we have to let the user to perform selfcert for their
workstation.

Thanks

 

[Lars-Eric Gisslén]

Oscar,

Did you read my reply to you about using MakeCert instead of SelfCert?

Regards,
Lars-Eric

 

[Steve Lang]

Hi "oscarmok"

I broke down and contacted Verisign for a Code Signing authentication
certificate. That was by far the simplest solution. It costs $400 or so, but
compared to the labor costs of having users self-cert and any other weird
gyrations I would have had to go through, the cost was cheap.

Since I do have a couple of other developers that generate Word code, I have
them send me the code, then I sign it and send it out. That way we only
needed to buy the one certificate.

HTH and have a great spook day!

Steve

 

[Lars-Eric Gisslén]

Steve,

We are using the VBA signing certificate from Verisign on 5 computers.

Export the certificate and include the private key in the export and export
to a PFX file. Then you can import the certificate on every machine you need
to have the certificate on.

Don't forget to timestamp the signing! Otherwise Office will complain when
openening signed documents when the certificate has expired. I don't think
you want to resign every document each year

Regards,
Lars-Eric

 

[Steve Lang]

Hi Lars,

You are way ahead of me on this. Can you point me to some info on the
export/import and timestamping? I'm always looking to learn more!

Thanks and have a great day!

Steve

 

[Lars-Eric Gisslén]

Steve,

To enable timespamping from VBA no need to add this registry key:

HKEY_Current_User\Software\Microsoft\VBA\Security\TimeStampURL
and set it to: http://timestamp.verisign.com/scripts/timstamp.dll

When you use a Verisign certificate this timestamping service is free. Your
signing will then be timestamped by Verisign so you must have access to the
Internet when you sign your VBA projects. You should not sign any VBA
projects without timestamp you signing!

When you received you VBA certificate you were asked to import it to your
computer. Then you had the option to allow exporting the private key. If you
choosed No they I guess you can stop read now.

Ok, then I assume you allowed to export the private key. You need to open
the certificate manager by right clicking on the Internet Explorer icon on
the desktop. From the dropdown meny choose Properties. Choose the content
tab in the dialog. In the middle of that tab you should have a button
'Certificates'. Click on that button and that will take you to the
certificate manager. In the certificate manager you will see your
cartificate in the 'Private' tab. Select your Verisign certificate in the
list and click on the button marked 'Export', just below the list of
certificates. Follow the instructions in the Wizard and also choose to
export the private key. Have your password for the certificate handy as you
will need the password to be able to export the private key. Choose to
export to a PFX file. If the option to export the private key is dimmed you
have propably imported the certificate with the option to not allow
exporting the private key. So, if that option is dimmed you can cancel the
export operation and give up.

If you were able to export the certificate and your private key to a PFX
file you have all that's needed. Copy the PFX file to each computer that
needs the certificate and just doubleclick on it to import the certificate.
When importing the certificate on other computers be sure to select to NOT
allow to export the private key and enable strong protection. Then delete
all the PFX files because nobody else should get their hands on your
certificate.

That's it.

I may be a little bit ahead of you when it comes to digital certificates and
digital signing but that is mostly because it's a part my job.
(http://www.signon.se/signatures/en_index.asp)

Regards,
Lars-Eric

 

[Steve Lang]

Thanks Lars, your help is invaluable!

Steve

Steve,

To enable timespamping from VBA no need to add this registry key:

HKEY_Current_User\Software\Microsoft\VBA\Security\TimeStampURL
and set it to: http://timestamp.verisign.com/scripts/timstamp.dll

When you use a Verisign certificate this timestamping service is free. Your
signing will then be timestamped by Verisign so you must have access to the
Internet when you sign your VBA projects. You should not sign any VBA
projects without timestamp you signing!

When you received you VBA certificate you were asked to import it to your
computer. Then you had the option to allow exporting the private key. If you
choosed No they I guess you can stop read now.

Ok, then I assume you allowed to export the private key. You need to open
the certificate manager by right clicking on the Internet Explorer icon on
the desktop. From the dropdown meny choose Properties. Choose the content
tab in the dialog. In the middle of that tab you should have a button
'Certificates'. Click on that button and that will take you to the
certificate manager. In the certificate manager you will see your
cartificate in the 'Private' tab. Select your Verisign certificate in the
list and click on the button marked 'Export', just below the list of
certificates. Follow the instructions in the Wizard and also choose to
export the private key. Have your password for the certificate handy as you
will need the password to be able to export the private key. Choose to
export to a PFX file. If the option to export the private key is dimmed you
have propably imported the certificate with the option to not allow
exporting the private key. So, if that option is dimmed you can cancel the
export operation and give up.

If you were able to export the certificate and your private key to a PFX
file you have all that's needed. Copy the PFX file to each computer that
needs the certificate and just doubleclick on it to import the certificate.
When importing the certificate on other computers be sure to select to NOT
allow to export the private key and enable strong protection. Then delete
all the PFX files because nobody else should get their hands on your
certificate.

That's it.

I may be a little bit ahead of you when it comes to digital certificates and
digital signing but that is mostly because it's a part my job.
(http://www.signon.se/signatures/en_index.asp)

Regards,
Lars-Eric

code,

 

[oscarmok]

I did follow your instruction but now it's saying I have to install my
personal certificate on all client machines. There's got to be a
better way! It says I should copy the file over to the client machine,
double click it and follow the wizard. That's OK for the first build,
but when my machine goes haywire and is rebuilt, the file must be
lost. If you copy it to another machine it's not supposed to work
either. (I got 1200 machines to do across the country and I can't
reply on the user)

Did I miss some steps?

 

[Lars-Eric Gisslén]

Oscar,

This is the nature of trying to be a CA (Certificate Authority). This is not
a problem only for your own created certifictes but a general problem. I
have an ID card (which is also a SmartCard) which has a number certificates
on it. The manufacturer of the ID card is also a CA but their root
certificate is not installed by Windows. Then if I use my ID card for
signing for instance emails, the reciever gets a big fat warning telling
that the signing can't be verified, if the reciever does not the issuers
root certificate on the computer. As the issuers root certificate is not
installed by Windows this warning is most likely to pop up. That's why the
issuers root certificate has to be on each machine to be able to verify your
digital signature. If you want to issue your own certificates you should
assign a computer for this purpose and you will not replace that computer
for a long time.

It's the root certificate that you will have to install on every client
machine so your code signing can be verified. You would face the same
problem if you would buy a code signing certificate from a CA whos root
certificate is not installed by Windows. If the root certificate is not on
the computer the certificate used for signing can't be verified against a
trusted source (the root certificate). That's the way it works. These
problems are something we have to deal with often as we have server and
client software for digitally signed documents and then we must have all
possible root certificates on the server so all signatures can be verified
and also checked against the issuers revocation lists.

When the root certificate is installed on the clients you can issue several
code signing certificates for different people and verifying the code
signing on the clients will still work. I just made a test and created a
root certificate that I also installed on another computer. Then I created a
client certificate and signed a Word macro with it. Then I opened the
document on the computer I installed the root certificate on and Word could
verify my signing without any problems. What is important is that your
private certificate must be converted to PFX file and imported on the
machine that will be used for signing the VBA projects.

Or, you can take the most reliable and most problem free path and buy a
Verisign VBA certificate. Verisign's root certificates are on almost every
computer running Windows so your signing can be verified on all computers
without intstalling any root certificate. Then you can also timestamp your
signing which should allways be done never mind if you sign VBA projects,
EXE, DLL, CAB, XML files or what ever you sign.

I think buying a Verisign VBA certificate is well worth $400 per year to
avoid all the trouble you are facing. How much has all your troubles cost so
far? How much will the maintainencce cost be in the future with creating
your own certificate? How much time will you spend before all computers has
your root certificate installed? Each time someone get a new computer, or
get a new hard disk, your root certificate has to be installed on that
machine again. If you calculate on the total costs to use your own issued
certificates I think buying a Verisign certifiace will be well worth the
money.

After all, using digital certificates are all about security and there are
no shortcuts.

Regards,
Lars-Eric

I did follow your instruction but now it's saying I have to install my
personal certificate on all client machines. There's got to be a
better way! It says I should copy the file over to the client machine,
double click it and follow the wizard. That's OK for the first build,
but when my machine goes haywire and is rebuilt, the file must be
lost. If you copy it to another machine it's not supposed to work
either. (I got 1200 machines to do across the country and I can't
reply on the user)

Did I miss some steps?



"Lars-Eric Gisslén" <lars.gisslen@_DelUnderscoreAndBetween_chello.se>

 

[oscarmok]

Thanks for clearing that up. We have desktop refresh in the next 3
months. If we have a image with the own created root certificate, and
restore to 1200 pcs, will it work?

 

[Lars-Eric Gisslén]

Oscar,

If you create a complete drive image the root certificate should be in the
image. When you import a certificate it will be stored in the registry as a
blob, if I remember right. I have never been working with dristributing root
certificates from a central place before I'm not able to give you any true
answers.

If you follow my instructions in a previous mail and create a root
certificate you can install it (the *.cer file) on a test machine to verify
that you have got the certificates correct. Create a private certificate,
signed by the root certificate (according to my previous mail) and sign a
VBA project and test it on the test machine. What you have to keep in mind
when creating the client certificates is that you should set the expire date
to a few years forward as you will propably not be able to time stamp your
VBA signing.

When you have created working and tested certificates you should backup the
<rootcert.cer> and <private.pfx> files and store them in a safe place! (You
can also create several private certificates for different users but keep a
backup of all certificates.) The root certificate can later be installed on
any computer and the PFX file(s) can also be installed on any computer used
for signing. But you can only issue new private certificates (for creating
the PFX files) on the computer where you created the root certificate.
_Don't forget_ to keep the passwords you assigned during the creation of the
different certificates in a safe place! If you would loose them there is no
way to recover them and your backups will suddenly turn useless!

Good luck!

Regards,
Lars-Eric

Thanks for clearing that up. We have desktop refresh in the next 3
months. If we have a image with the own created root certificate, and
restore to 1200 pcs, will it work?


"Lars-Eric Gisslén" <lars.gisslen@_DelUnderscoreAndBetween_chello.se>