Digital Certificate Expires Problem

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

A year ago I deployed some Access 2003 applications with a Verisign digital
certificate. Some were MDB and some were MDE. Users have high security
setting as required by their security group. Alas, when the certificate
expired the apps would no longer run until they changed Access security to
medium while I rushed them updates with my new digital certificate. Customer
will not tolerate this next year. Any suggestions?
 
It is a "by design" problem. Microsoft seems to think people want to be
bothered with and incur expenses related to renewal of digital certificates.
I think Microsoft has exaggerated the security risk in respect to allowing a
certificate to remain vaild for a longer period of time. IMO, security
would be just as effective if they were to allow the owner of the
certificate power to revoke if it were compromised.

If you're going to use a certificate, you're stuck with this behavior for
now.
 
To the best of my knowledge, the only way to avoid this is to send the
updates before the old certificate expires.

You could try explaining to your customer, as diplomatically as possible,
that it was *they* who decided this should happen, the day they decided to
set 'macro' security to 'high'.
 
Not sure whether your comments on user security apply to Access-level
security or the PC's general macro security.

If your apps /do not/ have access user-level security, the
AutomationSecurity property is your new friend. Problem over! No
certificate required, at all. Google this group for posts from me (TC)
for more information.

If you apps /do/ have access user-level security, you can still use
that property, but it isharder to code a 100% acceptable
general-purpose solution. Again, googling this group for that term will
find more information on what you need to do if your app is secured.

HTH,
TC
 
TC said:
Not sure whether your comments on user security apply to Access-level
security or the PC's general macro security.

If your apps /do not/ have access user-level security, the
AutomationSecurity property is your new friend. Problem over! No
certificate required, at all. Google this group for posts from me (TC)
for more information.
Click to expand...


If their Macro security is set to high (not a default setting), I'd also bet
that they're not allowed to run scripts, but...
 
According to VeriSign's knowledge base (vs5069) all I need to do is make some
registry entries and Office 2003 will time stamp the Digital ID and users can
use the database for ever. Now I'm attempting to verify the time stamp was
is working. Don't want to wait until next year to see. Microsoft sure has a
lot of secrets.
 
Just to clarify a bit more...you can set the registry settings indicated in
the Verisign article and IF the user is connected to the internet and can
connect to the Verisign timestamping service, the certificate would be
validated whether it expired or not. However, you'd be relying on the user
having an internet connection. Also, the validation process could cause
some delay in the startup of your application.

Yet another, bigger issue...the settings specified in the article are under
CURRENT_USER. You would need to change or set these registry keys from
within your installer. HOWEVER, the user installing your app may not be the
same user (make that probably will not be the same user) that uses the app.
So, you're back to square one...unless by chance the same registry keys can
be set under LOCAL_MACHINE so that they apply to all users. You'd have to
test this by:

1. creating the keys under LOCAL_MACHINE
2. Opening your app and monitoring network traffic to see if a connection
attempt is made to the timestamp service

I know that setting the macro security level to low under LOCAL_MACHINE
works as a setting for all users. I've never looked into whether the same
is true for settings related to a timestamp service and would be interested
in your findings. Nevertheless, if the same settings work under
LOCAL_MACHINE but those settings also exist under CURRENT_USER, I'm pretty
sure the entries under CURRENT_USER would take precedence.

In any case, this may not be as simple as the Verisign article suggests.
 
Others have also said this, but so far, I have not had any problems.

Just approaching a new rollout of my main product, though. This is the
first time it has been deployed for a2k3. My installer program is using
the property trick to set it all up. So, fingers crossed .....

TC
 
Back
Top