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

Question

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:

• self-signing
• Wells Fargo
• DigiCert
• SecureTrust
• Trustware
• QuoVadis
• GoDaddy
• Entrust
• Cybertrust
• GeoTrust
• GlobalSign
• Comodo
• Thawte
• Verisign

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:

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

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 on $99 to buy 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.

Answer 1

We had this same problem. They would not accept a Comodo code signing cert. In all likelihood it's to increase their group revenue (VeriSign/VeriTest which are owned by MS). I don't believe that they haven't had tons of requests to use non-VeriSign certs. However what choice do you have....?

Answer 2

Well, I just posted another request basically telling them we will not participate unless they accept Comodo Code Signing cert.

Microsoft contacted us to tell us we have reports on Windows 7 they want us to look at, but we can't sign in because we don't use Verisign. Ok, YOU contacted me... How much more authenticated do I need to be?

I have contacted the product manager, we'll see what happens.

And to answer your semi-rhetorical question above - there is NO reason why they can't authenticate other signed EXEs. Windows does it, IE does it, the code is already in there. They don't have to do anything special to support it.

UPDATE:

After speaking with the Microsoft rep I was told point blank that you must purchase at a minimum the $99 versign cert in order to "validate" and get your bug reports. Lame.

Answer 3

Ha! I have run into exactly the same scheme with our Comodo certificate. This is typical bully behaviour, their answers are complete nonsense. If anything, I distrust Verisign more than Comodo and Thawte etc. Let's not forget what they tried a while ago.

Answer 4

That is BS that they have not had requests to accept other authorities. Absolute BS.

Answer 5

The problem actually goes deeper.

For preserving a special status a recertification of one of our products had to happen. Of course that can only be done through VeriTest. To save money and be able to respond to problems before they notice them, we decided to choose the self-test option that allows us to test our software ourselves with so called "Works with" tools from Microsoft.

While the documentation says you need to have all your binaries code signed with an authenticode certificate to pass verification for Windows Server 2008 R2, nobody mentions that this is actually optional and won't have an impact on the test results (until you are actually on the report page saying that this step is optional and won't have an impact on the test results).

However, until then we already purchased a Comodo certificate, since it was only a quarter of the price of a VeriSign certificate and does the very same thing anyway.

Soon after a successfull recertification, we got notice about the current Virtual Launch Event from Microsoft and the possibility of being part of it (which is a great thing). However, to register we need to enter WinQual and guess what... for that of course we need a VeriSign WinQual company certificate (at least).

What's really funny now is that for at least two days, the corresponding VeriSign website was not available. For another three days now, it is not possible to obtain such a certificate and until now they didn't even respond to support requests.

Wouldn't it be great if some other company would start hosting a platform similar to WinQual except that it indeed DOES accept certificates from ALL serious publishers?

Joel... Jeff,... c'mon. That's something for you:

"[...] exhandler.com is like winqual,... but without the evil."

Answer 6

Same story here, I'm certifying application for Win7 Logo in order to get the points for MS Partnership program. I bought the Comodo code signing certificate. The application passed the test and now I'm trying to setup a Winqual account and after initially getting pissed off about having to buy another signing certificate I got into a 5 days delay trying to actually buy this "Organizational Certificate" for $99. No way, "VeriSign SSL Certificate Enrollment is temporarily unavailable. Please try again later.", and the support might as well be the worst I ever encountered. OMG ... please try at least to read the problem description or even try to reproduce the steps, don't just give me some stupid knowledge base solution for another problem. Or just say the service is unavailable, it will be available in 5 days. So frustrating ...

Just an update if anyone has the same problem, I finally got the answer to the enrollment problem and made the order. (I guess u need to get the right guy in tech support :)

"Our sincere apologies. This error occurs due to a bug in the Organizational Certificate enrollment. This error will occur if any country other than the US is entered into the "Certificate Info" (3rd step) section of the enrollment. This has been escalated to the engineers who are working on fixing it now. In the meantime you can do the following to get past the error and complete your enrollment: On the "Certificate Info" part of the enrollment, enter the country as "US" and the state as "California". All other information can be correct. Once the enrollment is complete go ahead and send us the order number for your certificate as well as the correct Country and State values for your company in reply to this email. We will edit the order in our system and enter the correct company and country values for you before we issue the certificate. The certificate that we issue to you will then contain the correct information."

Answer 7

Here is a place to support a change: https://connect.microsoft.com/site831/feedback/details/531903/allow-other-certificates-in-winqual-not-only-verisign

Answer 8

Though I've not done it myself, I have had several people tell me that they successfully used on of the Comodo certificates for WinQual. I have a standard price of $99 on Comodo certs at http://codesigning.ksoftware.net

Answer 9

Having done Code Signing and recently Winqual sign-up, here are some clarifications:

1. For Winqual sign-up (registration), your signature itself is not checked against the Winqual database. Winqual only checks the certificate from VeriSign that proves that VeriSign checked your identity. Then they get your company name from your signature.

2. In the next step, you have to create one or more "product mapping files" (using a tool from Microsoft) and upload these to Winqual. After that, the Winqual servers check several terabytes of crash database against all map files and provide you with a list of "events". (Which signature you used for code signing is therefore pretty irrelevant.)

3. There is no technical reason why Microsoft could not accept other Certification Authorities, too. But: how would they benefit from doing so? Also there is a special-offer programme to obtain a one-year code signing certificate from VeriSign for just $99, and if you compare this to the cost of a development tool chain or an MSDN/TechNet membership, it's not exactly expensive.

4. In our case, getting the certificate from VeriSign was straightforward and very fast - the whole process completed within two days. (We are not in the U.S., so I expected delays.) [Just for clarification: you generate your signature yourself, and it consists of a company_private_key (used for signing) and a company_public_key (for verifying your code signature). Any Certification Authority (like VeriSign) just counter-signs your company_public_key with their private key. This makes your certificate verifiable.]

5. We did not know that the VeriSign $99 certificate could be used for code signing, too (it is not only an organizational ID). So initially we went for another CA for Code Signing. Then we got a VeriSign cert for Winqual registration.

6. Microsoft publishes on WHDC and Winqual the information which signature providers are accepted for what type of signing. You can't really blame them for yourself not reading this before getting a certificate from another CA, can you?

Hope this may help to shed some light.

Answer 10

Well I just purchased a brand new “Code Signing (Class 3) Digital ID” from VeriSign specifically for Winqual (we normally use Comodo certificates), and we still receive the following error while uploading the signed Winqual.exe file: "The Winqual.exe file you uploaded is signed with an invalid digital certificate."

It really does not make any sense not to trust other root certificates like Comodo for Winqual, and really smells like protectionism. I’m sure that if VeriSign had a more neutral relationship with Microsoft this requirement would never have been imposed. This really is a great example of unhealthy mixed interests, and this could be a real treat for an institution like the European commission, if they would care to set their teeth into this. Maybe Microsoft will eventually come-up with Winqual N or K editions? God only knows why the Microsoft legal department is still not sensitive to these kind of issues.

Answer 11

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.