Digital code signing certificates a waste of money for Access 2007


D

dbguyatlanta

I bought a Comodo code signing certificate thinking it would rid me of
Microsoft's security message mess once and for all. It seems that in Access
2007 the certificate only applies to the intermediate file (.accdc) created
by the package and sign feature and not the actual database (.accdb) that
gets extracted from the accdc file.

When users open the accdc file, they get a chance to accept the certificate
but once the accdb file is extracted behavior returns to the usual flurry of
useless security messages. In other words, it seems like the database is
signed only for as long as its in the 'wrapper' (the accdc file) and its no
longer signed once its extracted.

Am I missing something?
 
Ad

Advertisements

D

dbguyatlanta

Thanks for taking the time to respond. The information in your link does work
for a certain user situation but there are many user situations involving the
Access 2007 runtime where the trust center is not an option. And sure, there
are yet other ways to manually disable the security warning mess Microsoft
has implemented but they all involve some analysis of the user's situation
(version of Office installed, the user's ability to edit the registry, etc.).
I was hoping to avoid all this.

The whole point of paying for my code signing certificate (I thought) was to
get rid of Microsoft's security warning mess entirely. It appears to me the
code signing certificate does accomplish this goal in Excel 2007. In Access
2007 however, the code signing feature seems to be a slapdash feature thrown
in at the last minute so they can claim that we have not gone backwards once
again as we did with the ribbon (offering no tools to easily create custom
ribbons or at least maintain existing tool/menu bars).

Again, if I've missed something and Access 2007 really can handle code
signing the same as Excel 2007 or Access 2003, I would greatly appreciate
info on how to sign the actual database, not just the accdc file.

Thanks
 
T

Tom van Stiphout

On Thu, 1 Apr 2010 12:59:02 -0700, dbguyatlanta

The way I read this article:
http://office.microsoft.com/en-us/access/HA101980471033.aspx#3
that is by design: the purpose seems to be to build a setup program
you can trust (note how the article is talking about a "signed
package"), not to build an app you can trust.

Did you try this: Code window > Tools > Digital Signature to sign the
VBA project?

-Tom.
Microsoft Access MVP
 
D

dbguyatlanta

The way I read this article:
http://office.microsoft.com/en-us/access/HA101980471033.aspx#3
that is by design: the purpose seems to be to build a setup program
you can trust (note how the article is talking about a "signed
package"), not to build an app you can trust.
Yes, that's exactly my understanding and all I would add is they have
removed the ability to sign code in the same way as the other 2007 apps do it
and previous versions of Office. Instead of really signing code, all they are
doing (essentially) in Access 2007 is signing a zip file (the accdc file)
that contains the database. Once the database is delivered and extracted from
the accdc file you no longer have a code signed file and you are subjected to
all of the usual security warnings unless you have prepared for the file with
trusted locations or other workarounds. And those workarounds are what one is
trying to avoid in the first place by purchasing a code signing certificate.
I suppose somebody that is offering Access databases for download off a
website might find the package and sign feature of minor interest but wow,
this is no step forward, lots of vendors offer better, more sophisticated web
delivery tools. In other words, in this instance Microsoft took away
something useful and replaced it with something of little value. The vast
majority of us doing Access development work don't need the package and sign
feature and those that need signed delivery/installation files are probably
all ready using better alternatives. What we need is the ability to sign the
database customers actually open and run to rid us of all the security
warning mess.
Did you try this: Code window > Tools > Digital Signature to sign the
VBA project?
Yes, its where I started actually, and this feature is interesting. They
sort of pretend it's going to do something, wasting your time as you choose
the certificate and go through the motions. Then at the last minute they
issue an error message saying that for various possible reasons the file
can't be signed. They specifically say in the error message that accdb and
accde files must use the package and sign feature, so when would this feature
ever be used???. I believe that in truth there is no scenario where the
Digital Signature feature on the VB editor toolbar ever works in 2007. You
can only use the Package and Sign feature. Unless I've missed something, this
feature seems kind of dishonest, or maybe meant to satisify some mindless
consistency with the VB editors in other Office 2007 products that actually
can sign code.
 
A

Arvin Meyer [MVP]

Have you tried signing the database first, then creating your install
package and signing that too?
 
D

dbguyatlanta

Arvin Meyer said:
Have you tried signing the database first, then creating your install
package and signing that too?
--
Yes, that's what got this thread started. Menu option Tools>Digital
Signature in the Access 2007 Visual Basic editor pretends like it is going to
work. You can select a certificate and so forth but at the last step Access
displays an error message saying that you cannot actually use this feature to
sign code in accdb and accde files, you have to use the package and sign
feature instead.
 
D

dbguyatlanta

Arvin Meyer said:
I'd say that your recourse now is with the certificate issuer. You should be
able to sign an application, that's the purpose of the cerificate in the
first place.
I think you missed a few things. My certificate works fine with the Access
2007 package and sign feature (the problem being this feature is useless),
and it works as expected with the code signing feature in Excel 2007. When I
try to use the Tools>Digital Signature menu option in the Access 2007 VB
editor, it does not complain about the certificate. The error message
displayed states that accdb and accde cannot be signed, we have to use the
package and sign feature instead.

Unless I've missed something or have done something wrong (which is what I
was looking for when I started this thread), the responsible party is
Microsoft not the certificate issuer. Microsoft appears to have yanked the
real code signing feature from Access 2007 and instead offers the nearly
useless package and sign feature ("useless" in the sense that it does not
stop security warning messages when users open your database and other
vendors offer far better tools for web distribution).

Thanks anyway for taking the time to respond.
 
D

dbguyatlanta

I should have added that the first thing I tried was to generate a
certificate with the Office 2007 "Digital Certificate for VBA Projects"
feature. The self-signed certificate had the same problems as the one I
purchased from Comodo.

Today I read some threads that seemed to indicate the code signing feature
in Access 2007 does work with ADP files. I have not tried that but threads I
found were discussing problems with the code signing being lost under certain
circumstances. So that makes the situation even more murky, why can ADP files
be signed in the VBA editor but not accdb or accde files?
 
D

dbguyatlanta

Sorry, one more thing: The Tools>Digital Signature feature in Access 2007 VB
editor DOES work with older MDB files. I did not try this initially since I
no longer use this format but I tested it this evening and it does work with
mdb files so the problems seem to be confined to accdb and accde files.
 
T

Tony Toews [MVP]

dbguyatlanta said:
Sorry, one more thing: The Tools>Digital Signature feature in Access 2007 VB
editor DOES work with older MDB files. I did not try this initially since I
no longer use this format but I tested it this evening and it does work with
mdb files so the problems seem to be confined to accdb and accde files.
I'm very late to this thread but family stuff.

I would agree with your steps. I repro'd your steps with my digital
signature I've purchased. Including the ability to sign an A2007 MDE
but not an A2007 ACCDE.

I have no idea why MS would remove this feature.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
T

Tony Toews [MVP]

dbguyatlanta said:
Sorry, one more thing: The Tools>Digital Signature feature in Access 2007 VB
editor DOES work with older MDB files. I did not try this initially since I
no longer use this format but I tested it this evening and it does work with
mdb files so the problems seem to be confined to accdb and accde files.
I've asked my fellow MVPs and MS for their comments and suggestions.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
T

Tony Toews [MVP]

dbguyatlanta said:
I bought a Comodo code signing certificate thinking it would rid me of
Microsoft's security message mess once and for all. It seems that in Access
2007 the certificate only applies to the intermediate file (.accdc) created
by the package and sign feature and not the actual database (.accdb) that
gets extracted from the accdc file.
The following page mentions the package signing, etc, that you mention
but doesn't specifically explain why you can no longer sign the
ACCDB/ACCDE.
http://office.microsoft.com/en-us/access/HA101980471033.ASPX

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
B

Banana

Thanks for taking the time to respond. The information in your link does work
for a certain user situation but there are many user situations involving the
Access 2007 runtime where the trust center is not an option. And sure, there
are yet other ways to manually disable the security warning mess Microsoft
has implemented but they all involve some analysis of the user's situation
(version of Office installed, the user's ability to edit the registry, etc.).
I was hoping to avoid all this.
I agree that this whole muck should be avoided but unfortunately, I
cannot find a good way to do just that. A possible workaround is to
write an installation script that will then add a Trusted Location at
installation time. Of course, it assumes that the users will have
administrative privilege to edit the Trusted Location and if there's a
group policy defined, then you may have no choice but to adhere to it.
At least what you could have the user choose the location and warn the
user if it's not a Trusted Location and try to add it for the user and
upon failure, warn the user again that it didn't work because of lack of
privilege, bla bla, and they'll get security dialogs. At least the user
will be informed and hopefully will get it corrected by the IT or
whoever's responsible.
The whole point of paying for my code signing certificate (I thought) was to
get rid of Microsoft's security warning mess entirely. It appears to me the
code signing certificate does accomplish this goal in Excel 2007. In Access
2007 however, the code signing feature seems to be a slapdash feature thrown
in at the last minute so they can claim that we have not gone backwards once
again as we did with the ribbon (offering no tools to easily create custom
ribbons or at least maintain existing tool/menu bars).
To be honest, I've always thought paying a CA to authenticate who you
are is a waste of money, and especially so for Access applications
except in very rare case where the application is marketed as a
shrink-wrapped applications. But most of Access applications out there
are used almost exclusively inhouse, either developed by an employee or
by a consultant whom the manager/owner knows/trust. Thus, SSL
certifications (which requires a CA authority to "work") makes no sense
in that context.
Again, if I've missed something and Access 2007 really can handle code
signing the same as Excel 2007 or Access 2003, I would greatly appreciate
info on how to sign the actual database, not just the accdc file.
As far as I can tell, it's not possible to sign accdb/accde in the same
sense as we could with mdb/mde. Trusted Location is only thing that
works reliably, hence my suggestion above. Not that I would think it
very secure, though.
 
T

Tony Toews [MVP]

Banana said:
I agree that this whole muck should be avoided but unfortunately, I
cannot find a good way to do just that. A possible workaround is to
write an installation script that will then add a Trusted Location at
installation time.
Note that the Auto FE Updater can do all this for a local app copied
from a LAN. It doesn't yet support updating an app via downloading
from the Internet. Although that's on the list of todo's.
Of course, it assumes that the users will have
administrative privilege to edit the Trusted Location
Users do not need admin privileges to add/update the Trusted Location.
Otherwise my Auto FE Updater wouldn't be able to do that.
Trusted Location is only thing that
works reliably, hence my suggestion above. Not that I would think it
very secure, though.
Agreed. Now in A2010 there's the concept of Trusted Documents.
http://blogs.technet.com/office2010/archive/2009/09/28/trusted-documents.aspx


However there's dearth of information on that topic. Yet. I would
assume there 'll be a page on the topic once Office 2010 is available.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
D

David W. Fenton

Banana said:
A possible workaround is to
write an installation script that will then add a Trusted Location
at installation time. Of course, it assumes that the users will
have administrative privilege to edit the Trusted Location and if
there's a group policy defined, then you may have no choice but to
adhere to it. At least what you could have the user choose the
location and warn the user if it's not a Trusted Location and try
to add it for the user and upon failure, warn the user again that
it didn't work because of lack of privilege, bla bla, and they'll
get security dialogs. At least the user will be informed and
hopefully will get it corrected by the IT or whoever's
responsible.
I could be wrong on this, but is it not the case that My Documents
is a trusted location by default? I set up a new Win7 PC the other
day with Access 2007, and put the front end in the Documents folder,
and the code ran just fine without having to mark that as a trusted
location.

Am I wrong on this?
 
B

Banana

I could be wrong on this, but is it not the case that My Documents
is a trusted location by default? I set up a new Win7 PC the other
day with Access 2007, and put the front end in the Documents folder,
and the code ran just fine without having to mark that as a trusted
location.

Am I wrong on this?
On my virtual machines, I've had to add My Documents (at least I'm
pretty sure I did but my memory could be lying) -- the only trusted
location installed by default is the path to the wizards. Now, this may
be a result of different OS, perhaps, as both machines run Windows
Server 2008 or Windows Server 2008 R2.

This link lists Predefined Trust Locations and My Documents isn't one of
them and the next paragraph recommends against using My Documents so I'm
not sure if this has chnaged somehow on Win7 in your case. Could it have
been picked up by a existing group policy?

http://office.microsoft.com/en-us/help/ha100319991033.aspx
 
B

Banana

Note that the Auto FE Updater can do all this for a local app copied
from a LAN. It doesn't yet support updating an app via downloading
from the Internet. Although that's on the list of todo's.
Cool. I knew solution existed but I've never had the need to implement
this myself. Good to know there's a proven solution out there, though.
Users do not need admin privileges to add/update the Trusted Location.
Otherwise my Auto FE Updater wouldn't be able to do that.
Okay, thanks for the correction. I assumed that TL required
administrative privileges -- they talked about having Trust Center being
centrally controlled by the IT so I assumed there existed a means to
prevent users from adding any new TLs or such. Seems to me it's pretty
thin if any Joe can waltz and add his own TLs...
Agreed. Now in A2010 there's the concept of Trusted Documents.
http://blogs.technet.com/office2010/archive/2009/09/28/trusted-documents.aspx


However there's dearth of information on that topic. Yet. I would
assume there 'll be a page on the topic once Office 2010 is available.
Thanks for pointing it out. I may toy with that when I have free time.
 
Ad

Advertisements

D

dbguyatlanta

Thanks for looking into it. I feel a little foolish for having bought the
digital certificate before verifying the feature actually works. I may still
get some use out of the certificate in other Office 2007 projects, it seems
to work the way we all would expect/want in the other products.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top