Warning on 2010 - 2011 VeriSign Code Signing Certificate Renewal

OSR_Community_User · January 13, 2011, 12:05pm

The short story is recent VeriSign code signing cert renewals (late 2010 ? 2011) have an invalid certificate chain when used with the Microsoft Cross cert.

In 2010 VeriSign sent several emails warning about their upgrade to 2048-bit keys. 2048 bit keys will not be enforced until 2013, and there was not supposed to be any impact. As part of this change, VeriSign updated several certs in the signing certificate chain. This may cause problems for anyone that signs a 64 bit driver.
In late December 2010 I renewed my company’s code signing certificate with VeriSign. I downloaded the new cert, and exported the pfx file per the instructions on VeriSign’s website:

https://knowledge.verisign.com/support/code-signing-support/index?page=content&id=SO1572&actp=search&viewlocale=en_US&searchid=1294781317250

I deleted the old cert from our signing system and installed the new cert by double clicking on the pfx file and taking the defaults. This is the same process we have used every year after renewing our cert. Imagine my surprise when drivers from the first build we signed with the new cert would not load under W2k8 x64.

It required several support calls and an escalation with VeriSign to figure out what happened. It turns out the dates in the Cross Certificate Chain are in the wrong order, with the Microsoft cross cert expiring in 2016, which is before the new VeriSign intermediate cert that expires in 2020.

To resolve this problem VeriSign released an ?alternative? intermediate cert. There is a rather poorly written Knowledge base article that explains the black magic procedure to fix your certificate store:

Solution ID: SO16565
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=SO16565&actp=search&viewlocale=en_US

The alternative cert can be downloaded from:

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=AR1575

Solution SO16565 omits a lot of steps, and contains a major error in step 3. To verify embedded kernel mode driver signatures you must use the ?/kp? option for ?signtool verify?, not the ?/pa? option as documented in the solution. If you use ‘/pa’ as documented, verify succeeds even though your 64 bit driver will not load.

Note that VeriSign blames this problem on Microsoft because Microsoft did not release a new cross cert. The VeriSign alternative intermediate cert has an expiration date of 2014, which comes after Microsoft?s expiration date of 2016. This fixes the cross certificate chain.
I hope this post saves others some time an pain.

David Schwartz

Peter_Viscarola_OSR · January 13, 2011, 4:20pm

THANK YOU David. Not only on behalf of everyone who’ll read this, but on my own behalf.

I need to renew OSR’s code signing cert next week, and you’ve just certainly saved me a ton of time.

Thanks again,

Peter
OSR

OSR_Community_User · January 14, 2011, 2:29am

(a) You can use “certmgr driver.sys” to print the embedded certificate
chain of a driver binary. With this, you can verify/check these issues.

(b) GlobalSign has a slightly different, but similar problem
(stated in this group before):

There are new GlobalSign certificates, valid until 2028,
which have been rolled out as an update.
But there is (yet?) no new Microsoft KMCS cross-certificate
to match them.
If the new GlobalSign root certifictaes are installed
on your signing machine, Signtool.exe will use the longest
valid CA certs (instead of the 2014 ones),
but then is not able to embed the cross-certificate.
With the newest WDK, you at least get a warning message
(“not all certificates could be embedded” or something),
but with the older WDKs you do not get ANY message.
What makes matters worse, you can’t test this issue on your
development machine: normally you will have both sets of
root CA certificates installed, and the CAT file checks will
use the certs from the registry as well as the embedded ones,
so “Signtool verify /xx driver.sys” will report “Signature OK”.
HOWEVER, on a Windows 64 bit system without the GlobalSign 2014
Root CA cert and the matching MS cross-cert installed,
driver *installation* will work.
But driver *load* will fail (with something like “certificate
chain could does not end in a trusted root”).

Remedy: remove the 2028 GlobalSign RootCA certificates
from your signing machine. Now you have time until
2014 for MS to issue a new KMCS cross-certificate.

BR-Hagen

Adrien_de_Croy · January 14, 2011, 7:05am

Hi

I must be missing something, because I don’t know how the certificate
chain would be able to include a root cert that wasn’t the one used to
sign the one below it in the chain.

So if you get a new GlobalSign signing cert, based on their new root
certificate, then how could you possibly include a different root in
your certificate chain? The thumbprints (used to verify parent cert)
wouldn’t match?

the only solution I see working is getting a cert from GlobalSign based
on their old root cert which has a cross cert.

I must be missing something surely?

Adrien

On 14/01/2011 8:28 p.m., Hagen Patzke wrote:

(a) You can use “certmgr driver.sys” to print the embedded certificate
chain of a driver binary. With this, you can verify/check these issues.

(b) GlobalSign has a slightly different, but similar problem
(stated in this group before):

There are new GlobalSign certificates, valid until 2028,
which have been rolled out as an update.
But there is (yet?) no new Microsoft KMCS cross-certificate
to match them.

If the new GlobalSign root certifictaes are installed
on your signing machine, Signtool.exe will use the longest
valid CA certs (instead of the 2014 ones),
but then is not able to embed the cross-certificate.

With the newest WDK, you at least get a warning message
(“not all certificates could be embedded” or something),
but with the older WDKs you do not get ANY message.

What makes matters worse, you can’t test this issue on your
development machine: normally you will have both sets of
root CA certificates installed, and the CAT file checks will
use the certs from the registry as well as the embedded ones,
so “Signtool verify /xx driver.sys” will report “Signature OK”.

HOWEVER, on a Windows 64 bit system without the GlobalSign 2014
Root CA cert and the matching MS cross-cert installed,
driver *installation* will work.
But driver *load* will fail (with something like “certificate
chain could does not end in a trusted root”).

Remedy: remove the 2028 GlobalSign RootCA certificates
from your signing machine. Now you have time until
2014 for MS to issue a new KMCS cross-certificate.

BR-Hagen

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Volodymyr_M_Shcherbyna-2 · January 14, 2011, 7:27am

Yes, I also went thru this.

It was a mess to find a solution as their web site does not contain easy paths to needed kbs.

OSR_Community_User · January 14, 2011, 7:58am

On 01/14/2011 01:04 PM, Adrien de Croy wrote:

I must be missing something, because I don’t know how the certificate
chain would be able to include a root cert that wasn’t the one used to
sign the one below it in the chain.

This is exactly why the MSCV Root cross-cert is NOT embedded in the
signature chain – because the “newer” GlobalSign_Root-Cert_[valid until
2028] does not have the same thumbprint as the
GlobalSign_Root-Cert_[valid until 2014] the cross-cert was made for.

This is an abbreviated picture of the signature chain:

good case

a) MSCV Root(public key embedded in Windows kernel)

—driver binary starts here—

b) (Cross-)Certificate
MSCV_Root->GlobalSign_Root[valid_until_2014]

c) Certificate
GlobalSign_Root[valid_until_2014]->GlobalSign_Object_Sign

d) Certificate
GlobalSign_Object_Sign->Your_Company_Certificate

e) Your_Company_Certificate->Your_Company_Certificate (self signed)

bad case

—driver binary starts here—

a) Certificate
GlobalSign_Root[valid_until_2028]->GlobalSign_Object_Sign

b) Certificate
GlobalSign_Object_Sign->Your_Company_Certificate

c) Your_Company_Certificate->Your_Company_Certificate (self signed)

Problem:

Starting at the bottom, Signtool.exe finds these two certificates:

GlobalSign_Root[valid_until_2014]->GlobalSign_Object_Sign
GlobalSign_Root[valid_until_2028]->GlobalSign_Object_Sign

…and it uses the one with the longer validity!

But it does not check if BOTH of them can be certified by the
cross-certificate or not.

As you don’t have a cross-certificate
MSCV_Root->GlobalSign_Root[valid_until_2028]
… it just does not embed anything above GlobalSign_Root.

Since the Win7 WDK, Signtool at least prints a warning message about not
being able to embed something, but you could easily overlook this message.

Further problematic is that your driver package will still INSTALL
correctly, and it will WORK on e.g. Win7/32bit. But not on Win7/64bit.

So if you get a new GlobalSign signing cert, based on their new root
certificate, then how could you possibly include a different root in
your certificate chain? The thumbprints (used to verify parent cert)
wouldn’t match?

You got the certification chain mechanism in the wrong order, the
thumbprint is not for the parent cert, but for the child cert:

in a certificate, the higher-level CA validates the lower-level CA
e.g. GS_Root_CA[valid until 2014)->GS_ObjectSign_CA
you can re-issue a ‘new’ (longer valid) certificate for a new
“higher-up” CA key that still validates an older lower-level
certificate
e.g. GS_Root_CA[valid until 2028] -> ObjectSign_Root_CA)

(Yes, the new GS_Root_CA[valid until 2028] base cert must be in the
“Trusted Root” storage, but in my case an MS update did exactly that-)

=> So this (the newer Root_CA cert) is not a problem.

The problem comes in at the next step “higher up”, with the “Microsoft
Code Verification Root” cross-certificate:

The MSCV_Root public key itself is embedded in some
kernel-loader component (it is not in the registry).
But the cross-certificate (that links MSCVR to the GlobalSign Root CA)
will not match the “newer” GlobalSign Root CA key.

HTH-H

Adrien_de_Croy · January 14, 2011, 8:11am

I must have it backwards then, since I thought that

a. you use signtool to sign your driver with your issued cert (the
child), not the head of the tree cert.

b. how can a parent cert have a child’s thumbprint in it? It can’t
since that would violate time.

I think that the child cert has the parent’s signature on it, which
verifies the child cert was validly issued by the parent.

Surely therefore SignTool must work backwards from the cert you sign
with, back up the tree, picking the cert that signed at each stage, and
therefore if you signed your driver with a cert derived from the new
GlobalSign cert you are screwed end of story.

I say this because empirically we have both root certs installed, but no
signing issues. When we sign our driver with our code signing cert
which was issued by GlobalSign from their old root, it all works fine,
whether or not we have 2 GlobalSign roots installed on the signing computer.

It doesn’t pick (to my mind) the different GlobalSign root to add to the
chain because that would make no sense at all (it doesn’t compare name
just thumbprints - so to SignTool the other GlobalSign root may as well
be MyDogName root).

On 15/01/2011 1:57 a.m., Hagen Patzke wrote:

On 01/14/2011 01:04 PM, Adrien de Croy wrote:
> I must be missing something, because I don’t know how the certificate
> chain would be able to include a root cert that wasn’t the one used to
> sign the one below it in the chain.
This is exactly why the MSCV Root cross-cert is NOT embedded in the
signature chain – because the “newer” GlobalSign_Root-Cert_[valid until
2028] does not have the same thumbprint as the
GlobalSign_Root-Cert_[valid until 2014] the cross-cert was made for.

This is an abbreviated picture of the signature chain:

good case

a) MSCV Root(public key embedded in Windows kernel)

—driver binary starts here—

b) (Cross-)Certificate
MSCV_Root->GlobalSign_Root[valid_until_2014]

c) Certificate
GlobalSign_Root[valid_until_2014]->GlobalSign_Object_Sign

d) Certificate
GlobalSign_Object_Sign->Your_Company_Certificate

e) Your_Company_Certificate->Your_Company_Certificate (self signed)

bad case

—driver binary starts here—

a) Certificate
GlobalSign_Root[valid_until_2028]->GlobalSign_Object_Sign

b) Certificate
GlobalSign_Object_Sign->Your_Company_Certificate

c) Your_Company_Certificate->Your_Company_Certificate (self signed)

Problem:

Starting at the bottom, Signtool.exe finds these two certificates:

GlobalSign_Root[valid_until_2014]->GlobalSign_Object_Sign
GlobalSign_Root[valid_until_2028]->GlobalSign_Object_Sign

…and it uses the one with the longer validity!

But it does not check if BOTH of them can be certified by the
cross-certificate or not.

As you don’t have a cross-certificate
MSCV_Root->GlobalSign_Root[valid_until_2028]
… it just does not embed anything above GlobalSign_Root.

Since the Win7 WDK, Signtool at least prints a warning message about not
being able to embed something, but you could easily overlook this message.

Further problematic is that your driver package will still INSTALL
correctly, and it will WORK on e.g. Win7/32bit. But not on Win7/64bit.

> So if you get a new GlobalSign signing cert, based on their new root
> certificate, then how could you possibly include a different root in
> your certificate chain? The thumbprints (used to verify parent cert)
> wouldn’t match?
You got the certification chain mechanism in the wrong order, the
thumbprint is not for the parent cert, but for the child cert:

in a certificate, the higher-level CA validates the lower-level CA
e.g. GS_Root_CA[valid until 2014)->GS_ObjectSign_CA

you can re-issue a ‘new’ (longer valid) certificate for a new
“higher-up” CA key that still validates an older lower-level
certificate
e.g. GS_Root_CA[valid until 2028] -> ObjectSign_Root_CA)

(Yes, the new GS_Root_CA[valid until 2028] base cert must be in the
“Trusted Root” storage, but in my case an MS update did exactly that-)

=> So this (the newer Root_CA cert) is not a problem.

The problem comes in at the next step “higher up”, with the “Microsoft
Code Verification Root” cross-certificate:

The MSCV_Root public key itself is embedded in some
kernel-loader component (it is not in the registry).

But the cross-certificate (that links MSCVR to the GlobalSign Root CA)
will not match the “newer” GlobalSign Root CA key.

HTH-H

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

OSR_Community_User · January 14, 2011, 8:26am

On 01/14/2011 02:11 PM, Adrien de Croy wrote:

I must have it backwards then, since I thought that

a. you use signtool to sign your driver with your issued cert (the
child), not the head of the tree cert.

This is correct - you use your private key to encrypt the hash of the
binary (=driver).

b. how can a parent cert have a child’s thumbprint in it? It can’t
since that would violate time.

Please don’t mix up the parent / child public key and the “certificate”
itself.

When you certify “something”, you encrypt (with your private key) a hash
of the “something”. Then normally you also add our public key (so the
encrypted hash can be easily decrypted).

So you have (shown bottom->up)

child public key

hash, of child public key, encrypted with certifier private key
certifier public key

I think that the child cert has the parent’s signature on it, which
verifies the child cert was validly issued by the parent.

No, the parent public key is used to decrypt (=>validate) the
child_public_key_encrypted_hash

Surely therefore SignTool must work backwards from the cert you sign
with, back up the tree, picking the cert that signed at each stage, and
therefore if you signed your driver with a cert derived from the new
GlobalSign cert you are screwed end of story.

Yes, Signtool must work “backwards” to encrypt and select the certificates.

But it stores (and certmgr displays) the keys from top to bottom.

You can see this if you kindly open an embed-signed driver binary in the
hex editor of your choice.

This also makes a lot of sense: for checking the signature for
validity, you want to start as far up in the tree as possible.

I say this because empirically we have both root certs installed, but no
signing issues. When we sign our driver with our code signing cert
which was issued by GlobalSign from their old root, it all works fine,
whether or not we have 2 GlobalSign roots installed on the signing
computer.

Please do a “certmgr driver.sys” check and look if your cross-cert is
part of the embedded signature.

If it is not, everything will work… until you load your driver on
Win7/64bit, on a machine which has the MSVC cross-cert and the older
RootCA cert NOT installed.

It doesn’t pick (to my mind) the different GlobalSign root to add to the
chain because that would make no sense at all (it doesn’t compare name
just thumbprints - so to SignTool the other GlobalSign root may as well
be MyDogName root).

Don’t believe me, try and check for yourself.

But you need to install and run (or attempt to run) the signed driver
on a Win7/64bit system WITHOUT the old GlobalSign Root CA cert and
without the MSVC cross-cert.

Luckily a colleague of mine - who had a fresh Win7/64bit installation -
ran into that problem (driver installed, but does not load), otherwise I
would never have been able to track this down.

On 32bit systems, everything “just works”, and on the Win7/64bit system
even driver install works. Only the actual driver load fails.

Well, we’ve got until 2014 for MS to provide a new cross-cert…

OSR_Community_User · January 14, 2011, 8:31am

>> b. how can a parent cert have a child’s thumbprint in it? It can’t

> since that would violate time.

One additional clarification:

When you register for a Software Publisher Certificate

(a) you create a self-signed certificate for your company

then

(b) the Certification Authority makes a (“cross-”)certificate for your
self-signed certificate.

=> for this, the CA (lowest level above you) signs your public_key with
their private key (and also adds their public key).

[The other certificates “higher up” are usually long “ready-made”.]

OSR_Community_User · January 14, 2011, 8:45am

> I think that the child cert has the parent’s signature on it, which

verifies the child cert was validly issued by the parent.

“the parent’s signature”
== child_public_key_encrypted_with_parent_private_key
plus parent_public_key

not “the child validates the parent”,
but “the parent validates the child”.

Therefore you can have two different “parents” validating the same
“child”, i.e.
e.g. two different GlobalSign Root CA certificates
(with different validity. 2014 and 2028)
both validating
e.g. the same “GlobalSign Object Publishing Root”
(quoted from memory, I’m currently not on Windows).

Unfortunately “one level up”, the MSCV Root certificate is only valid
for the 2014-expiring GlobalSign Root CA key.

Thus using the 2028-expiring certificate breaks the “embed signing”
chain - and Win7/64bit will install, but NOT load the driver.

Adrien_de_Croy · January 14, 2011, 9:03am

thanks for all your answers.

when I say the parent’s signature - it’s like when you are sick and you
take a note to school with your parent’s signature on it - the parents’s
signature means that the parent vouches for the authenticity of the note.

So when I wrote the parent signs the child cert, as you say the parent
cert private key is used to encrypt a hash of the child certificate content.

I always presumed that there was some sort of back-pointer embedded into
the cert being signed by the parent at that point, and the obvious
back-pointer to embed is the parent cert thumbprint. That way you could
tell which cert was used to sign another cert.

In order for an intermediate certificate to be vouched for by 2 parent
certs, then the intermediate cert would need to have appended 2
signatures (a hash of the child separately encrypted by each of the 2
parent cert private keys). I didn’t think that the GlobalSign Primary
Object Publishing CA (which expires in 2014 as well) had been signed by
both, but time-wise it could have been since the 2028 expiring root was
issued in 1998.

So I guess I’m asking can a cert have 2 immediate parent certs? Seems
like a bad idea to me.

As for my driver, when I look at it (can’t launch certmgr with a command
argument) on windows 7 x64, it looks like it only shows up to the 2028
GlobalSign root.

I wonder therefore whether a NDIS LWF driver does not really require to
be embed signed then or theoretically it shouldn’t be working. It’s
certainly loading and running.

thanks

Adrien

On 15/01/2011 2:44 a.m., Hagen Patzke wrote:

> I think that the child cert has the parent’s signature on it, which
> verifies the child cert was validly issued by the parent.

“the parent’s signature”
== child_public_key_encrypted_with_parent_private_key
plus parent_public_key

not “the child validates the parent”,
but “the parent validates the child”.

Therefore you can have two different “parents” validating the same
“child”, i.e.
e.g. two different GlobalSign Root CA certificates
(with different validity. 2014 and 2028)
both validating
e.g. the same “GlobalSign Object Publishing Root”
(quoted from memory, I’m currently not on Windows).

Unfortunately “one level up”, the MSCV Root certificate is only valid
for the 2014-expiring GlobalSign Root CA key.

Thus using the 2028-expiring certificate breaks the “embed signing”
chain - and Win7/64bit will install, but NOT load the driver.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

OSR_Community_User · January 14, 2011, 10:20am

On 01/14/2011 03:02 PM, Adrien de Croy wrote:

So I guess I’m asking can a cert have 2 immediate parent certs? Seems
like a bad idea to me.

No. Two certs from two different parents for the same “child”.

As for my driver, when I look at it (can’t launch certmgr with a command
argument) on windows 7 x64, it looks like it only shows up to the 2028
GlobalSign root.

To launch certmgr with a command line argument
(a) open a WDK “build environment” command line
(b) enter “certmgr your_driver.sys”
With the 2028 GlobalSign RootCA certificate only, I’d advise you to
try it on a freshly installed Win7/64bit box (NOT!!! any PC used for
signing!).

I wonder therefore whether a NDIS LWF driver does not really require to
be embed signed then or theoretically it shouldn’t be working.

My experience is from USB drivers (ours is WDM / BulkUSB-derived), and
for this to run on Win7/64bit you DO need an embed-signed driver.

It’s certainly loading and running.

On which platforms?

Win/32bit platforms are no problem (no embed-sign requirement).

Win[7]/64bit platforms also work if this is your development / signing
PC. It will NOT work on a “clean install” customer PC with Win7/64bit.

The reason why I take the time to post this is that you can’t detect the
issue using the normal WDK toolchain + Singtool.exe. There is no error
reported. You can only check for the issue manually.

You only discover it if you try to use the driver on a “clean” PC.
Which might be too late.

Adrien_de_Croy · January 14, 2011, 4:53pm

On 15/01/2011 4:19 a.m., Hagen Patzke wrote:

On 01/14/2011 03:02 PM, Adrien de Croy wrote:
> So I guess I’m asking can a cert have 2 immediate parent certs? Seems
> like a bad idea to me.
No. Two certs from two different parents for the same “child”.

so both these parents vouch for the same child?

> As for my driver, when I look at it (can’t launch certmgr with a command
> argument) on windows 7 x64, it looks like it only shows up to the 2028
> GlobalSign root.

To launch certmgr with a command line argument
(a) open a WDK “build environment” command line
(b) enter “certmgr your_driver.sys”

With the 2028 GlobalSign RootCA certificate only, I’d advise you to
try it on a freshly installed Win7/64bit box (NOT!!! any PC used for
signing!).

we’ve done a lot of testing on fresh installs.

in fact this driver is already deployed in thousands of systems, Vista,
2008 and Windows 7 both 32 and 64 bit.

so we know it’s loading fine on all these OSes.

we do ship a couple of certs as well which we install before installing
our driver (to stop warnings).

those certs are just our cert up to the GlobalSign 2028 root (4 in
total). not any cross certs.

Regards

Adrien

> I wonder therefore whether a NDIS LWF driver does not really require to
> be embed signed then or theoretically it shouldn’t be working.
My experience is from USB drivers (ours is WDM / BulkUSB-derived), and
for this to run on Win7/64bit you DO need an embed-signed driver.

> It’s certainly loading and running.
On which platforms?

Win/32bit platforms are no problem (no embed-sign requirement).

Win[7]/64bit platforms also work if this is your development / signing
PC. It will NOT work on a “clean install” customer PC with Win

7/64bit.

The reason why I take the time to post this is that you can’t detect the
issue using the normal WDK toolchain + Singtool.exe. There is no error
reported. You can only check for the issue manually.

You only discover it if you try to use the driver on a “clean” PC.
Which might be too late.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

OSR_Community_User · January 17, 2011, 2:02am

On 1/14/2011 10:52 PM, Adrien de Croy wrote:

we’ve done a lot of testing on fresh installs.

in fact this driver is already deployed in thousands of systems,
Vista, 2008 and Windows 7 both 32 and 64 bit.

so we know it’s loading fine on all these OSes.

we do ship a couple of certs as well which we install before
installing our driver (to stop warnings).

those certs are just our cert up to the GlobalSign 2028 root (4 in
total). not any cross certs.

Well, good luck then.

Adrien_de_Croy · February 4, 2011, 3:22am

Just to revive and keep flogging this dead horse.

Both the old and new GlobalSign Root CA certificates have the same
Subject Key Identifier field value.

60 7b 66 1a 45 0d 97 ca 89 50 2f 7d 04 cd 34 a8 ff fc fd 4b

Does this make any difference?

Just trying to figure out why it works, especially as
http://www.microsoft.com/whdc/driver/install/drvsign/crosscert.mspx is
quite clear that Vista / Windows 7 X64 needs all kernel code to be
signed, and our driver is working, and we have the new root cert on our
signing machine, and when we view the certificate chain on the driver
(in explorer), it goes up to the new root cert (exp 2028).

Regards

Adrien

On 17/01/2011 8:02 p.m., Hagen Patzke wrote:

On 1/14/2011 10:52 PM, Adrien de Croy wrote:
> we’ve done a lot of testing on fresh installs.
>
> in fact this driver is already deployed in thousands of systems,
> Vista, 2008 and Windows 7 both 32 and 64 bit.
>
> so we know it’s loading fine on all these OSes.
>
> we do ship a couple of certs as well which we install before
> installing our driver (to stop warnings).
>
> those certs are just our cert up to the GlobalSign 2028 root (4 in
> total). not any cross certs.
Well, good luck then.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Volodymyr_M_Shcherbyna-2 · February 7, 2011, 10:11am

I guess this upgrade is going to continue cause some troubles

This is screenshot from Fr Windows 2000 SP4 (all patches on): http://shcherbyna.com/files/windows/verisign%20upgrade.png taken when looking at properties of file, signed with the recent verisign certificate. There were no such problems with the previous one.

Well, it basically says that it cannot verify the certificate. WinVerifyTrust(…) fails with 0x800B010A (0x800b010a - A certificate chain could not be built to a trusted root authority).

Awesome.