Hello experts,
We have a driver which was WHQL signed for an older release of the product.
We are to ship a new version of the same product, but there were no changes
in the Driver at all. So we packaged the same WHQLed drivers in the
installer.
However, when we sent the product for WinLogo testing to LionBridge we found
out that the cert for the driver has *expired* in December 2010.
So, do we need to re-WHQL the driver? Or can we get the cert extended? Is an
expired cert still a valid cert?
Thanks in advance.
–
On 03/16/2011 02:14 PM, amitr0 wrote:
Is an expired cert still a valid cert?
If it has a cryptographic timestamp from before it expired, yes.
amitr0 wrote:
We have a driver which was WHQL signed for an older release of the
product. We are to ship a new version of the same product, but there
were no changes in the Driver at all. So we packaged the same WHQLed
drivers in the installer.
However, when we sent the product for WinLogo testing to LionBridge we
found out that the cert for the driver has *expired* in December 2010.
So, do we need to re-WHQL the driver? Or can we get the cert extended?
Is an expired cert still a valid cert?
Are you going to submit to WHQL again? If so, why? If not, what’s the
point of paying for WinLogo testing?
Driver packages that were signed by you before the expiration will
continue to be valid. The signing process embeds a timestamp, which
tells the system “the certificate was valid at the time it was signed”.
However, you cannot use your certificate to sign anything new. You
probably can’t even use your expired certificate to log on to Winqual to
submit the package.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
All,
thanks for the answers.Though I am not sure we are all on the same page. I
will try to explain my process, I apologise if you guys already understood
the scenario, in that case this email is redundant.
The WinLogo testing I am talking about is the one that lets you put the
‘Certified for WindowsXXX’ on your product package(box, CD cover etc).
So lets say I had three components in my product:
drv.sys
service.exe
app.exe
of which drv.sys was WHQL qualified before and there were no bugs and hence
no change in this release. So that component is pristine.
Service.exe and app.exe had bugs, and enhancements (say GUI changes) and
after building the new binaries, we authenticode sign them. The cert used is
our cert, where as drv.sys has MSFT WHQL certs. So no co-relation.
Now we send this whole package for WinLogo testing.
Anywho, so in this testing, we got back logs to check the cert on the driver
too. Which I think they interpreted as expired. Hence my original question.
Best regards
amit
On Wed, Mar 16, 2011 at 10:18 PM, Tim Roberts wrote:
> amitr0 wrote:
> >
> > We have a driver which was WHQL signed for an older release of the
> > product. We are to ship a new version of the same product, but there
> > were no changes in the Driver at all. So we packaged the same WHQLed
> > drivers in the installer.
> >
> > However, when we sent the product for WinLogo testing to LionBridge we
> > found out that the cert for the driver has expired in December 2010.
> >
> > So, do we need to re-WHQL the driver? Or can we get the cert extended?
> > Is an expired cert still a valid cert?
>
> Are you going to submit to WHQL again? If so, why? If not, what’s the
> point of paying for WinLogo testing?
>
> Driver packages that were signed by you before the expiration will
> continue to be valid. The signing process embeds a timestamp, which
> tells the system “the certificate was valid at the time it was signed”.
> However, you cannot use your certificate to sign anything new. You
> probably can’t even use your expired certificate to log on to Winqual to
> submit the package.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
–
- amitr0
amitr0 wrote:
thanks for the answers.Though I am not sure we are all on the same
page. I will try to explain my process, I apologise if you guys
already understood the scenario, in that case this email is redundant.
The WinLogo testing I am talking about is the one that lets you put
the ‘Certified for WindowsXXX’ on your product package(box, CD cover etc).
Right. Same thing. When you pass WHQL testing in one of the defined
device categories, you get the right to use the logo. When you pass
WHQL testing as an unclassified device, you don’t. Both get you the
WHQL signature on your cat file.
So lets say I had three components in my product:
drv.sys
service.exe
app.exe
of which drv.sys was WHQL qualified before and there were no bugs and
hence no change in this release. So that component is pristine.
Service.exe and app.exe had bugs, and enhancements (say GUI changes)
and after building the new binaries, we authenticode sign them. The
cert used is our cert, where as drv.sys has MSFT WHQL certs. So no
co-relation.
Now we send this whole package for WinLogo testing.
Unless you are in a device class I’m not familiar with (which is quite
possible), the logo testing doesn’t come anywhere near the service and
the application. All it tests is the driver.
Anywho, so in this testing, we got back logs to check the cert on the
driver too. Which I think they interpreted as expired. Hence my
original question.
If your driver package (meaning the sys, the inf, and the cat) has no
changes, then you don’t need to resubmit it. Just ship it with the old
package. I believe you are even entitled to continue using the logo on
your new box. If your application and your service are part of the
package, and hence part of the cat file, then you will have to resubmit
the whole package to WHQL, and that means you will need to renew your
certificate.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
kindly go through these links…
http://en-us.lionbridge.com/product-engineering/product-certification/microsoft/default.htm
http:
http://en-us.lionbridge.com/ProductEngg.aspx?pageid=1312&LangType=1033
thanks again
Amit
http:
On Wed, Mar 16, 2011 at 11:38 PM, Tim Roberts wrote:
> amitr0 wrote:
> >
> > thanks for the answers.Though I am not sure we are all on the same
> > page. I will try to explain my process, I apologise if you guys
> > already understood the scenario, in that case this email is redundant.
> >
> > The WinLogo testing I am talking about is the one that lets you put
> > the ‘Certified for WindowsXXX’ on your product package(box, CD cover
> etc).
>
> Right. Same thing. When you pass WHQL testing in one of the defined
> device categories, you get the right to use the logo. When you pass
> WHQL testing as an unclassified device, you don’t. Both get you the
> WHQL signature on your cat file.
>
> > So lets say I had three components in my product:
> > drv.sys
> > service.exe
> > app.exe
> >
> > of which drv.sys was WHQL qualified before and there were no bugs and
> > hence no change in this release. So that component is pristine.
> > Service.exe and app.exe had bugs, and enhancements (say GUI changes)
> > and after building the new binaries, we authenticode sign them. The
> > cert used is our cert, where as drv.sys has MSFT WHQL certs. So no
> > co-relation.
> >
> > Now we send this whole package for WinLogo testing.
>
> Unless you are in a device class I’m not familiar with (which is quite
> possible), the logo testing doesn’t come anywhere near the service and
> the application. All it tests is the driver.
>
> > Anywho, so in this testing, we got back logs to check the cert on the
> > driver too. Which I think they interpreted as expired. Hence my
> > original question.
>
> If your driver package (meaning the sys, the inf, and the cat) has no
> changes, then you don’t need to resubmit it. Just ship it with the old
> package. I believe you are even entitled to continue using the logo on
> your new box. If your application and your service are part of the
> package, and hence part of the cat file, then you will have to resubmit
> the whole package to WHQL, and that means you will need to renew your
> certificate.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
–
- amitr0</http:></http:>
Once your driver package is signed by WHQL, you’re good to go unless you modify the package binaries or the .inf file. Driver’s signed with expired certs remain valid as long as there is a cryptographic timestamp with the signature showing that the signature was applied when it was valid unless one of the CA’s revokes one of the certs in the chain.
Perhaps, you accidentally resigned the driver binaries or cat files when you packaged them up in our installer as part of an automated build.
The other possibility is that Lionsbridge has a bug in their verification software where they are only looking at the cert and not the cryptographic timestamp.
After you verify that the signature and timestamp are valid on the binaries you gave them, you need to ask them exactly why they think the signature isn’t valid.
> However, they are not the ones that issue the Windows logo.
correct, they send all test results to MSFT.
What I didn’t know(and thanks for the tip) was that msft only checks for the
drivers being signed and nothing else. not that is is going to make any
difference to the management, it is ‘standard procedure’ is what I will get
if I tell them this.
just out of curiosity, which date do they cross ref the date in the cert
with? Date modified?
thanks
amit
On Thu, Mar 17, 2011 at 12:29 AM, Tim Roberts wrote:
> amitr0 wrote:
> > kindly go through these links…
> >
> >
> http://en-us.lionbridge.com/product-engineering/product-certification/microsoft/default.htm
> > http://en-us.lionbridge.com/ProductEngg.aspx?pageid=1312&LangType=1033
> > http:
>
> That’s irrelevant. I do not doubt that Lionbridge offers valuable
> testing services, and perhaps it is worth your money to run the new
> product through their testing. However, they are not the ones that
> issue the Windows logo. That’s done by Microsoft. I’ve told you what
> Microsoft requires. If there is no change to your driver or your driver
> package, then you do not need to retest and resubmit.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
–
- amitr0</http:>
amitr0 wrote:
just out of curiosity, which date do they cross ref the date in the
cert with? Date modified?
I’m not sure what you mean. When you buy certificate, it has an
expiration date. Once it has expired, you can no longer sign anything
new with that certificate, nor can you use it to log in to the Winqual
site. I assume that’s what they were warning you about – you need to
renew the certificate before they can do anything NEW with it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> just out of curiosity, which date do they cross ref the date in the cert with? Date modified?
I’m not sure who “they” is. If they is Lionsbridge, we don’t know what they’re doing which was my point about checking with them to find out what date they’re using to determine that the cert is expired.
If they is MS, then Microsoft is checking the signatures on signed files. In the case of a WHQL signed catalog file, there will be a signature from MS there will be a signature from “Microsoft Windows Hardware Compatibility Publisher” and a counter signature from “Microsoft Timestamping Service”. The date of the countersignature is checked against the expiration date of the main signature to verify that the signature on the file is valid. This is the way it should be done.
The Lionsbridge verification tool may just be checking the expiration date of the signature against the current date or some other file date.