cf. bug 585812 Assigning to joduinn since he usually handles these.

Ordered 1 year cert. Order number is USMOZIX3-2X

New authenticode keys created Friday, and verified with a redo of signing a recent Firefox release this morning. New passphrase given out to non-Canadian RelEng folks today, and I'll give to the Canadians when they are back tomorrow from Thanksgiving. This new authenticode key will be used for tomorrow's FF8.0b3. Done.

Here are notes I took while doing this, to make it easier to renew the signing key next time. Pre-requisites not documented elsewhere: ======================================== *) you must use IE, even though that is not mentioned on thawte.com. Their website appears to work fine with Firefox, but some ActiveX components fail out silently, causing later steps to fail out in interesting and unusual ways. *) you must connect to thawte.com using the *same* install of IE throughout *all* the different steps below. *) you must use IE8 or above, and with security settings adjusted to allow thawte.com ActiveX component to work correctly. For these reasons, I have update the IE6 on cm-keymaster01 to IE8, with adjusted security settings on cm-keymaster01, and used it for generating new Authenticode key in this bug. To get a new Authenticode key from Thawte.com: ============================================== *) login to thawte.com using the release@mozilla.com address. *) on thawte.com, in their section of "Code Signing Certificates", you want to buy "Microsoft® Authenticode® (Multi-Purpose)" certificate. **) Make sure that the Key-size is 2048 (not 1024). Buy a 1-year version. On Thawte website, if you generate a code signing certificate it has sometimes silently defaulted to 1024bits and not provided the option to go higher. We require our key to be 2048bits, like our expiring key. While generating the keys in oct2011, Thawte website defaulted to 2048, and was fine. Noting here just to watch for next time. *) Have mrz watch emails to hostmaster@mozilla.com for a verification email from thawte, and a voicemsg containing a verify code. If mrz doesnt have time to call Thawte back and read them the verification code, mrz may ask you to do so in his place. If you do this, acting as mrz, you need to tell Thawte "security" that your name is "Matthew Zeier" and then read them the verification code. It is not enough to tell Thawte that you are "calling on mrz's behalf" and give them the same verification code. ?!? *) Once the verbal verification is done, wait a few minutes for an email "Order Confirmation: Thawte Code Signing Certificate", then wait for an email "thawte Automated Order Verification". *) If mrz is not around to get the verification code, your application will timeout and be cancelled after 2?3? days. This time we did not need to redo, but last year took several go-arounds to get past this step. *) When you get email "Your Thawte Code Signing Certificate Is Approved", you can login to thawte.com site and follow the instructions to download the private key to cm-keymaster01. Make sure the file extension is .pvk. Also, make a clear note of what is upper / lower case in the passphrase! *) In IE8, go to Tools->InternetOptions, then click the "Content" tab, then click the "Certificates" button. Select the certificate and click "Export". Select "PKCS#7" format, check the "Include all certificates in the certification path if possible" checkbox and save as MozAuthenticode.p7b. *) Rename the new MozAuthenticode.p7b to MozAuthenticode.spc. To verify that the keys are valid, do a test signing. I did it as follows: *) Rename an existing recent release in ~/signing-work to a temp name. Copy the directory to the original name. Note that the signing automation will look for tags that do exist, so testing with "VERSION=4.0b5" worked, but "VERSION=4.0b5.test" did not work. Also before starting to sign, delete the signed build to avoid erroring out when automation finds signed builds already exist. For example, I did: $ cd ~/signing-work $ mv firefox-8.0b2 firefox-8.0b2.orig $ rsync -av firefox-8.0b2.orig firefox-8.0b2/ $ cd firefox-8.0b2 $ rm -rf signed-build* $ rm -rf cache* $ vi Makefile ...and comment out the download verify-download, upload steps within the "all" target. *) Follow signing instructions https://intranet.mozilla.org/Build:CombinedSigning, with following caveats: **) the build notes for the most recent release will be more accurate then https://intranet.mozilla.org/Build:CombinedSigning **) use the "make all" target, not the "make autosign" target **) Make sure to use the modified copy of FF8.0b2 release, not the original. **) make sure to change the KEYDIR environment variable to point to the directory containing the new key (in my case d:/2011-keys). **) Remember to restart signcodepwd after each attempt at signing. *) After doing a test signing of a previous release, verify that both the Firefox installer, and also the installed Firefox executable both show the new certificate expiry dates, and correct certificate chain. *) Rename back the real release directory. Post patch, update docs and declare victory! :-)

nthomas reminded me that I had to patch http://hg.mozilla.org/build/tools/file/tip/release/signing/Makefile to point to new location of key.

Comment on attachment 566061 [details] [diff] [review] change Makefile to use new authenticode key in new directory http://hg.mozilla.org/build/tools/rev/f1ace66b1766

We should use these keys for xulruner as well. I added a note to the build notes template: https://wiki.mozilla.org/Releases/BuildNotesTemplate#Signing

note that next time we do this, the fingerprint of the new public key needs to be added to firefox so that new hotfix addons can be deployed.