Menu
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:
when we've already established that it is a valid digital signature:
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?
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.
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:
...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.
537
In the Internet Options window, on the Content tab, click Certificates. In the Certificates window, on the Personal tab, double-click the code signing certificate that you just installed. If you have multiple code signing certificates, use the expiration date to determine which certificate is the correct one.
Timestamping ensures that code will not expire when the certificate expires because the system validates the timestamp. If you use the timestamping service when signing code, a hash of your code is sent to the timestamp server to record a timestamp for your code.
Code signing certificate is used for securing software while SSL certificate is used for securing internet communication. But the issuing authority of certificates can be same for both kinds. In both the cases, a pair of public and private keys are used to encrypt or hash the software or the communication path.
Code Signing Certificates are used by software developers to digitally sign applications, drivers, executables and software programs as a way for end-users to verify that the code they receive has not been altered or compromised by a third party.
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.
53
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.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
