So I have successfully completed a Windows HLK Test process and got a hlkx package out of it. I had created it unsigned.
I tried uploading that package to the partner center but they wouldn’t accept it. Through further googling I found out it needs to be signed afterall.
We have a dedicated machine for signing in our company. On there we installed the Windows HLK Studio (Not the controller) and tried to sign it with the certification-dongle plugged in. But that got us the following error:
Hi Tim, hi Peter, thanks for the fast replies.
Well we have uploaded the drivers to the partnercenter in the past too, just not as a hlkx package. They were signed with the same cert, so I’d guess it is the same code-signing certificate on the dongle and in the partnercenter.
My general process is correct though? Just the HLK-Studio is sufficient for signing, no controller needed?
I really have no idea how to proceed here. As I said, there are no infos on this online
@David_Scheele
Not sure how HLK Studio signing works, but technically you should not need a controller for it. And if it was missing controller, it probably would not complain about the certificate OID. Where I work, we sign the packages on a separate machine which does not have any HLK tools installed at all, the signing is performed by a simple self-written program based on the code provided here, and it works fine.
I would recommend to check the certificate’s OID, just to be sure (previous accepting the signature might have been caused by less strict checks). In our certificates it’s 1.3.6.1.5.5.7.3.3; I don’t know if alternative code signig OIDs exist, but they can be checked in the databases online. If that’s definitely OK, you could try signing using the program code from the MS documentation, see whether it works, and if not, what error it returns.
The requirements for a WHQL submission are not so strict. You absolutely need an EV certificate to establish a dashboard account, but once you have that account, your submissions can be signed by any certificate registered with your account. It doesn’t need to be EV, it doesn’t even need to be a code-signing certificate.
Points to a general page with multiple blog posts… none of which actually contain more information on this topic. And, maybe it’s just me but (a) that first bullet point is ambiguous and horribly written, and I don’t trust MSFT when it comes to these rules anyways, I’ve seen them change WAAAAY too many times.
Thanks for the replies, very insightful and it’s nice to see some sympathy.
I guess I will look into signing the package without the studio. CaptainFlint already posted a link that looks promising. Does anyone know of any other ways or already useable programs for this?
Many much all the time. We have been submitting packages signed using our non-EV certificate for multiple years now. The last one I personally submitted and successfully signed was July 30, 2021.
The information in that page is simply out of date, and indeed what “what Microsoft originally said would be required.” Attested Signing, HLK and HCK package signing, and even UEFI signing have all worked successfully here using a normal non-EV code signing certificate we have associated to our Microsoft Partner Portal company account.
The only type of signing we currently see Microsoft direction of “still requires that the submission be signed with the EV certificate” is LSA Plug-In signing. But we have not yet had opportunity or need to sign an updated version of the LSA Plug-Ins we have, to actually test that requirement.
Mr @Alan_Adams … Thank you. EXACTLY why I asked, because it seems “unlikely” that this policy would change, but…
FWIW, I filed doc bug (that has yet to be acknowledged) on that page requesting clarification. If this is, in fact, NOT the policy then the doc bug should flush this fact out.
Note the 2nd bullet item in the blue box (sha256) is now being enforced. It might be wise to consider non-ev certs as unsupported / undefined behavior pending a clarification that states otherwise. Good companies don’t write their code based on what some guy on the internet says works or doesn’t work, but rather follows the spec.
Note the 2nd bullet item in the blue box (sha256) is now being enforced
This just means you need to use a specific switch on sign tool.
It might be wise to consider non-ev certs as unsupported
No. It might be wise to just try it and not take the word of some guy quoting some random MSFT doc page that is just as likely to be wrong and right. In fact, in my own humble experience, I’ve certainly found that MSFT doc pages can frequently be LESS likely to be correct than the lived experience of a competent practitioner. Take, for example, all the places that it says that Attestation Signing does not work for Windows Server.
I’m not saying to base a product decision on this. I’m saying, just take something like the Toaster sample, make a driver package, and sign it with one of your registered non-EV certs… and see if it works. Then you’ll know. And post the results here, and then we’ll all know.
@Rourke said:
Note the 2nd bullet item in the blue box (sha256) is now being enforced.
I would also say it’s not “now”… it’s been happening probably since the same year when that information was posted. The block you’re talking about presumably was correct on both counts, “at the time it was written.” But regarding the EV certificate signing requirement for submissions, the information had subsequently become incorrect.
Microsoft stated in October 2016 that after initially intending that EV signatures would be required for all submissions, partner feedback had caused them to change this stance. They now allow submissions to be signed with any certificate you have uploaded to your company account on Microsoft Partner Portal (former Windows Dev Center, former Windows SysDev).
Microsoft stated in November 2017 that starting the next year, SHA-1 digests would no longer be accepted as part of a valid signature on submissions.
Both of these developments were discussed here in this forum, if you search back to those time frames.
public static void Sign(string package, X509Certificate2 certificate)
{
// Open the package to sign it
Package packageToSign = Package.Open(package);
// Specify that the digital signature should exist
// embedded in the signature part
PackageDigitalSignatureManager signatureManager = new PackageDigitalSignatureManager(packageToSign);
signatureManager.CertificateOption = CertificateEmbeddingOption.InCertificatePart;
// We want to sign every part in the package
List<Uri> partsToSign = new List<Uri>();
foreach (PackagePart part in packageToSign.GetParts())
{
partsToSign.Add(part.Uri);
}
// We will sign every relationship by type
// This will mean the signature is invalidated if *anything* is modified in //the package post-signing
List<PackageRelationshipSelector> relationshipSelectors = new List<PackageRelationshipSelector>();
foreach (PackageRelationship relationship in packageToSign.GetRelationships())
{
relationshipSelectors.Add(new PackageRelationshipSelector(relationship.SourceUri, PackageRelationshipSelectorType.Type, relationship.RelationshipType));
}
try
{
signatureManager.Sign(partsToSign, certificate, relationshipSelectors);
}
finally
{
packageToSign.Close();
}
}
Took the thumbprint of our EV from the partner center page. Could then upload the package via the driver submission. After entering the relevant info i could submit it and it got approved all the way through. SUCCESS! But…
Select Request Signatures as applicable. This option allows you to specify which operating system signatures (including allowable downlevel operating systems) should be included with your driver. Available certifications vary depending on your driver submission package, so there may not be any certifications listed. Note If you are signing a driver package for a single architecture, only include logs for the intended architecture. For example, to sign for x64 only, submit only the x64 logs.
“May depend on you driver submission package”
I can’t find an option for that in the HLK. Did I miss something somewhere?
In case Microsoft decides to change it or delete the page or something, here is the code:
public static void Sign(string package, X509Certificate2 certificate)
{
// Open the package to sign it
Package packageToSign = Package.Open(package);
// Specify that the digital signature should exist
// embedded in the signature part
PackageDigitalSignatureManager signatureManager = new PackageDigitalSignatureManager(packageToSign);
signatureManager.CertificateOption = CertificateEmbeddingOption.InCertificatePart;
// We want to sign every part in the package
List<Uri> partsToSign = new List<Uri>();
foreach (PackagePart part in packageToSign.GetParts())
{
partsToSign.Add(part.Uri);
}
// We will sign every relationship by type
// This will mean the signature is invalidated if *anything* is modified in //the package post-signing
List<PackageRelationshipSelector> relationshipSelectors = new List<PackageRelationshipSelector>();
foreach (PackageRelationship relationship in packageToSign.GetRelationships())
{
relationshipSelectors.Add(new PackageRelationshipSelector(relationship.SourceUri, PackageRelationshipSelectorType.Type, relationship.RelationshipType));
}
try
{
signatureManager.Sign(partsToSign, certificate, relationshipSelectors);
}
finally
{
packageToSign.Close();
}
}
After that I was able to upload the package to the submitting dashboard. After entering a bit of information I could submit it and it got checked, approved and signed. SUCCESS!
But…
I was only able to select from the following Signature requests:
Select Request Signatures as applicable. This option allows you to specify which operating system signatures (including allowable downlevel operating systems) should be included with your driver. Available certifications vary depending on your driver submission package, so there may not be any certifications listed. Note If you are signing a driver package for a single architecture, only include logs for the intended architecture. For example, to sign for x64 only, submit only the x64 logs.
Available certifications vary depending on your driver submission package
Did I miss an option in HLK somewhere? I looked it over again and couldn’t find anything.
We already have a few drivers submitted there and they do have been submitted for Windows 10 versions, so again not exactly sure where the problem is now.
@David_Scheele
You are welcome, I’m glad you managed to get it working!
As for signing, the screenshot you gave it cut off too much. These are just the additional signatures. The main signature is listed below, in the Certification block: https://i.imgur.com/L9BHobw.png
Does your submission have anything like that?
Yeah but it only shows “Windows 10 19H1 Update”. There is that question again, will I have to test for all Win10 Versions currently out there? Because from this it sure looks like it.
