RSA Key Blocking is Here!
Hello everyone. Jonathan here again with another Public Service Announcement post.
Today, Microsoft has published a new Security Advisory:
Microsoft Security Advisory (2661254): Update For Minimum Certificate Key Length
The Security Advisory and the accompanying KB article have complete information about the software update, but the key takeaway is that this update is now available on the Download Center and the Microsoft Update Catalog. In addition, Microsoft will release this software update through Microsoft Update (aka Windows Update) in October 2012. So all of you enterprise customers have two months to start testing this update to see what impact it has in your environments.
If you want information on finding weak keys in your environment then review the KB article. It describes several methods you can use. Microsoft Support has also created a PowerShell script that has been posted to the the TechNet Script Center.
Finally, I have one final warning for those of you that use makecert.exe to create test certificates. By default, makecert.exe creates certificates that chains up to the Root Agency root CA certificate located in the Intermediate Certification Authorities store. The Root Agency CA certificate has a public key of 512 bits, so once you deploy this update no certificate created with makecert.exe will be considered valid.
You should now consider makecert.exe deprecated. As a replacement, starting with Windows 7 / Windows Server 2008 R2, you can use certreq.exe to create a self-signed certificate. For example, to create a self-signed code signing certificate you can create the following .INF file:
[NewRequest]
Subject = "CN=Self Signed Cert"
KeyLength = 2048
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
KeySpec = "AT_SIGNATURE"
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE"
RequestType = Cert
SMIME = False
ValidityPeriod = Years
ValidityPeriodUnits = 2
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.3
The important line above is the RequestType value. That tells certreq.exe to create a self-signed certificate. Along with that value, the ValidityPeriod and ValidityPeriodUnits values allow you specify the lifetime of the self-signed certificate.
Once you create the .INF file, run the following command:
Certreq -new selfsigned.inf selfsigned.crt
This will take your .INF file and generate a new self-signed certificate that you can use for testing.
Ok, so this was supposed to be a short post pointing to where you need to go, but it turns out that I had some other related stuff. The important message here is go read the Security Advisory and the KB article.
Go read the Security Advisory and the KB article.
Ex pace.
Jonathan “I am the Key Master” Stephens
Comments
- Anonymous
October 18, 2012
- This gotcha definitely should be in the KB and bulletin, not burried in a blog about a related tech area (Authenticode test certs have very little to do with directory services other than the historic X.500 connection and perhaps internal MS team structures).
- It would have been prudent for the update to include a new > 1024 bit test root and an update to the code that used the old root. The new test root would be untrusted in the same way as the old one and have a similar DN (chaning only some intermediary OU to say "2012"), thus retaining its limitation as something that would be used only in (automated) test procedures.
- Self signed certificates can be created with makecert.exe too, it is just not the default action. Switching to a different tool would have a much greater impact on system requirements and many other internal processes anywhere this is routinely used, wheras using makecert.exe with larger key sizes is available on any system not still running the pre-2000 "export grade" configurations.
- Anonymous
October 19, 2012
Also, you must add "Exportable = True" under [NewRequest] somewhere. Otherwise, you will not be able to sign and deploy a ClickOnce app with the new certificate.