Search code examples
windowserror-reportingwinqualbumptop

WinQual: Why would WER not accept code-signing certificates?

Edit as of 1/24/2015: It is not possible to use other trusted certificate authorities now. Question and answer is not obsolete:

WinQual still rejects the signature:

enter image description here

when we've already established that it is a valid digital signature:

enter image description here

For completeness, i will leave the edit below that someone else did; just to point out how wrong he was. And he can live with that shame:

Edit as of 2014: it is possible to use other trusted certificate authorities now. Question and answer is obsolete.

In 2005 i tried to establish a WinQual account with Microsoft, so i could pick up our (if any) crash dump files submitted automatically through Windows Error Reporting (WER). i was not allowed to have my crash dumps, because i don't have a Verisign certificate. Instead i have a cheaper one, generated by a Verisign subsidiary: Thawte.

The method in which you join is: you digitally sign a sample exe they provide. This proves that you are the same signer that signed apps that they got crash dumps from in the wild.

Cryptographically, the private key is needed to generate a digital signature on an executable. Only the holder of that private key can create a signature with for the matching public key. It doesn't matter who generated that private key. That includes certificates that are generated from:

Yet Microsof's WinQual only accepts digital certificates generated by Verisign. Not even Verisign's subsidiaries are good enough (Thawte).

Can anyone think of any technical, legal or ethical reason why Microsoft doesn't want to accept code-signing certificates? The WinQual site says:

Why Is a Digital Certificate Required for Winqual Membership?

A digital certificate helps protect your company from individuals who seek to impersonate members of your staff or who would otherwise commit acts of fraud against your company. Using a digital certificate enables proof of an identity for a user or an organization.

Is somehow a Thawte digital certificate not secure?

Two years later, i sent a reminder notice to WinQual that i've been waiting to be able to get at my crash dumps. The response from WinQual team was:

Hello,

Thanks for the reminder. We have notified the appropriate people that this is still a request.

In 2008 i asked this question in a Microsoft support forum, and the response was:

We are only setup to accept VeriSign Certificates at this point. We have not had an overwhelming demand to support other types of certificates.

What can it possibly mean to not be "setup" to accept other kinds of certificates?

If the thumbprint of the key that signed the WinQual.exe test app is the same as the thumbprint that signed the executable who's crash dump you got in the wild: it is proven - they are my crash dumps, give them to me.

And it's not like there's a special API to check if a Verisign digital signature is valid, as opposed to all other digital signatures. A valid signature is valid no matter who generated the key.

Microsoft is free to not trust the signer, but that's not the same as identity.

So that is my question, can anyone think of any practical reason why WinQual isn't setup to support digital signatures?

One person theorized that the answer is that they're just lazy:

Not that I know but I would assume that the team running the winQual system is a live team and not a dev team - as in, personality and skillset geared towards maintenance of existing systems. I could be wrong though.

They don't want to do work to change it. But can anyone think of anything that would need to be changed? It's the same logic no matter what generated the key: "does the thumbprint match".

What am i missing?

Update

It is nice to hear the stories of other developers. This way i know that i'm not alone, and the question can serve as a vehicle for change on Microsoft's part. And even if my original intent was a complaining rant, in order to keep this a valid StackOverflow question i'm looking for a technical reason why Microsoft could only accept Verisign certificates.

The crypto API doesn't care what the name of the company that issued a certificate is: it only cares that the chain of signers leads back to a trusted root.

What could possibly be going on that Microsoft specifically isn't using the established crypto infrastructure, but instead is limited itself to Verisign?

If anyone could point to any blog entry, where a program manager or developer explains why, i would, perhaps, be satisfied.

Update Two

People seem to be missing the point of my question. Windows already has the code infrastructure to ensure that a digital signing certificate is trusted by a root authority. Here's a screenshot of a digital signature on one of our signed executables.

You can see our certificate was signed by Thawte's Code-Signing authority certificate, which in turn is signed by Thawte:

alt text

And the "thawte" certificate ships by default with Windows:

alt text

The Thawte Premium Server CA is good enough that every copy of Windows and Internet Explorer already trust it. And there already is an established API to check if a certificate is valid (i.e. trusted).

When WinQual guys came along, they would have had to have gone out of their way to avoid checking the correct way, and instead rolled their own solution, hard-coding only Verisign as a trusted root. Why would they go out of their way to ignore the other trusted root authorities, authorities that ship on the Windows machine that their code is running on, and instead hard-code Verisign?

Rather than do it the way everyone else does (Windows Explorer, Firefox, Chrome, Internet Explorer, Opera, CertMgr, etc), they specifically only allow Verisign. And my question is why.

Why would WER not accept code-signing certificates?

If it was simply:

  • because the guy who initally wrote it didn't know the proper way off the top of his head
  • and rather than spend a whole lot of time investigating the proper way
  • he just threw something together
  • and just for testing he hard-coded just the one signer
  • with the full intention of coming back later and fixing it
  • but the code is now working
  • and it went live without being fixed
  • and nobody wants to take responsibility for breaking it
  • and nobody wants to spend money to fix it
  • and not enough customers are complaining to make it a high priority
  • and even if there was a lot of people complaining, it's only $99 to buy a Verisign one
  • so can't you just let it go and buy a Verisign one?

...that would be fine. Except i don't believe it. i don't believe that it was test code that made into production. i get the sense that it is a conscious, specific, decision that made them ignore other signers. And that they do, and will continue to, only honor Verisign.

But for the life of me i can't think of the reason.

Solution

  • I just signed up to WinQual, and I've been contemplating this question; I think I now have the answer.

    In short: They aren't using VeriSign as a certificate at all: They are just outsourcing the task of verifying your identity.

    Microsoft doesn't want you to have access to the WinQual site without first verifying your identity. So they need an identification verification process.

    They could have a department that charges you $99, and does the verification. But they already have significant holdings in VeriSign, which already has staff that can do that. So they use the process of signing up for the certificate to verify your identity. It's not using the certificate at all, it's just entrusting VeriSign with the task of verifying you.

    Note that they don't require you to continue to maintain a VeriSign certificate to keep your account: it's just a once off fee for joining the site.

    Because this is a case of Microsoft verifying your identity, and they trust VeriSign because they have their fingers in that pie, and they don't trust Comodo so much, they want you to use VeriSign for this purpose, not any other certificate. It seems a bit silly from the developer's point of view, but I can understand it from their perspective.