730922 - convert authenticode certificates to PCKS12, for mac code signing

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

I've been trying to do this for nearly a day now and gotten nowhere following these instructions: https://intranet.mozilla.org/Build:CombinedSigning#Mac_Signing_Setup

I haven't been able to find an RSA key for any of our certs (release, nightly nor the self signed one), so I've only been able to try method #1. I tried that method on keystage01, admin.b.m.o, and a Windows 7 machine, including trying multiple versions of IE on admin. I couldn't even get a PKCS12 out of keystage01. With the other machines I got a PKCS12 but after importing it into the Keychain on mac-keymaster I got told that it couldn't be used for signing.

Comment 1

[[e-mail] (:bhearsum)]

Turns out that our staging keys' .spc file isn't a valid PKCS7 like it was supposed to be. Apparently SPC files are "simply DER encoded PKCS#7 files containing the certificates. Well they are in the newer versions of the tools. The older versions used an invalid PKCS#7 format." (http://www.drh-consultancy.demon.co.uk/pkcs12faq.html). So, I bet the tools on keymaster/keystage are one of the "older versions", since that's where we generated them.

I found some instructions for converting certs on these two pages: http://www.entropy.ch/blog/Developer/2007/08/16/Converting-Microsoft-pvk-Private-Keys-to-Java-Keystore.html, http://www.entropy.ch/blog/Developer/2008/02/11/Mac-OS-X-Application-Code-Signing.html. They start with a pvk/spc and go through the entire process of how to get a PKCS12. This requires the 'pvk' tool found here: http://www.drh-consultancy.demon.co.uk/pvk.html. The short version is:
~/pvk.exe -in MozAuthenticode.pvk -out MozAuthenticode.key.pem
openssl pkcs7 -inform der -print_certs < MozAuthenticode.spc > MozAuthenticode.cert.pem
openssl pkcs12 -export -inkey MozAuthenticode.key.pem -in MozAuthenticode.cert.pem -out MozAuthenticode.p12

After that, I imported the key into Keychain and successfully signed something in the VNC session. I couldn't sign something over ssh, but I think that's to do with some permissions that we can fiddle with in Keychain.

Still need to:
1) Convert the release key
2) Create a new staging key that can actually be converted (hopefully with the same root, since we have that root deployed on our Windows 7 machines for the silent update tests....)
3) Update the CombinedSigning doc with better instructions for converting keys.

Comment 2

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #1)
> Still need to:
> 1) Convert the release key
> 2) Create a new staging key that can actually be converted (hopefully with
> the same root, since we have that root deployed on our Windows 7 machines
> for the silent update tests....)
> 3) Update the CombinedSigning doc with better instructions for converting
> keys.

These are all done now, with very detailed notes taken in https://intranet.mozilla.org/RelEngWiki/index.php/Signing.

This is how I generated a new staging key from our existing root:
openssl genrsa -out MozAuthenticode.key -des3 4096
openssl req -new -key MozAuthenticode.key -out MozAuthenticode.csr
openssl x509 -req -days 7200 -in MozAuthenticode.csr -CA MozFakeCA.cert.pem -CAcreateserial -CAkey MozFakeCA.key.pem -out MozAuthenticode.pem -outform PEM
openssl crl2pkcs7 -norl -certfile MozAuthenticode.pem -outform DER -out MozAuthenticode.spc

The only caveat is that I cannot for the life of me get OS X's codesign tool to sign properly with our staging keys. It will run, but exit with 1 and give me this error: CSSMERR_TP_NOT_TRUSTED. Googling around, this seems to be related to the root not being trusted, despite the fact that I've imported the root into Keychain. I pinged Christian to see if he knows anything, and he's going to try to contact someone that knows all about signing on OS X. If that goes somewhere we might be able to revisit this, otherwise we'll use a different key for staging/dep mac builds.

Comment 3

[[e-mail] (:bhearsum)]

One last thing here: I swapped in the new staging keys on the dep signing servers this morning....and then they broke some tests. Thinking about it a bit more, I'm not sure we need to bother swapping in the new certs, because the only point of them was to try and be consistent between signcode + mac signing. With it resolved that we won't be doing that for staging, maybe we'll just use the old certs. Need to double check that logic tomorrow morning, though.

Comment 4

[[e-mail] (:bhearsum)]

Yup, there's no reason to use different staging certs now, given that we can't use them everywhere. Resolving as FIXED again, and we'll generate new staging certs for mac when those signing servers are up.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #2)

> The only caveat is that I cannot for the life of me get OS X's
> codesign tool to sign properly with our staging keys. It will run,
> but exit with 1 and give me this error: CSSMERR_TP_NOT_TRUSTED.

I created a self-signed cert (to use as a CA cert).  Then I followed
the procedure you outline, with the exception that I created a pkcs12
file corresponding to the signing cert that I'd created (which
contains both the cert and its private key).

I successfully imported both the pkcs12 signing cert and my test CA's
cert (i.e. without its private key) with Keychain Access.  Then I
changed my signing cert's trust settings to always trust it for "code
signing".

But when I tried to use the codesign utility to sign Firefox with my
signing cert, I got the following error:

this identity cannot be used for signing code

I've also followed Apple's procedure to get a "Developer ID
Application" cert for myself (as a member of ADC).  This "identity"
*does* work from codesign (codesign allows me to use it to sign
Firefox).

But (very strangely) there is no private key associated with the cert
that I downloaded from Apple and imported with Keychain Access.  So I
suspect codesign is actually using some kind of Apple private key to
do the signing (supposedly) with my "Developer ID Application" cert.
Or perhaps the private key is stored somewhere on Apple's servers
(which I did use in the process of generating my "Developer ID
Application" cert).

This (if true) is pretty disturbing on its own.

But it may also mean that we need to "sign" Firefox with a "Developer
ID" acquired (somehow) from Apple, for OS X to recognize the
signature.

Has anyone tried the new signing procedure on Firefox, then tried to
run that copy of Firefox on Mountain Lion?

All my tests (so far) have been performed on OS X 10.6.8.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #5)

> But (very strangely) there is no private key associated with the cert
> that I downloaded from Apple and imported with Keychain Access.

This is definitely true -- I used the openssl x509 utility to confirm it.  But I've now also found the public/private keypair that codesign was probably using (in the "login" keychain).  I imagine the private key got downloaded from an Apple server when I imported the "Developer ID Application" cert using Keychain Access.

I've also now figured out how to create a pkcs12 signing cert that codesign will use.  More tomorrow about how I did that, and what happens when I run my signed FF distro on Mountain Lion.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Following up comment #5 and comment #6)

> But (very strangely) there is no private key associated with the
> cert that I downloaded from Apple and imported with Keychain Access.
> So I suspect codesign is actually using some kind of Apple private
> key to do the signing (supposedly) with my "Developer ID
> Application" cert.  Or perhaps the private key is stored somewhere
> on Apple's servers (which I did use in the process of generating my
> "Developer ID Application" cert).

>> But (very strangely) there is no private key associated with the
>> cert that I downloaded from Apple and imported with Keychain
>> Access.
>
> This is definitely true -- I used the openssl x509 utility to
> confirm it.  But I've now also found the public/private keypair that
> codesign was probably using (in the "login" keychain).  I imagine
> the private key got downloaded from an Apple server when I imported
> the "Developer ID Application" cert using Keychain Access.

Turns out I was mostly wrong about this.

It's true that the "Developer ID Application" cert that you download
from Apple's Member Center doesn't come with a private key.  But the
first part of the process of getting the "Developer ID Application"
cert involves running Keychain Access's Certificate Assistant, which
creates a certificate request to send to Apple, and before that
creates a public/private keypair for the identity for which the
"Developer ID Application" cert will be issued.  No part of this
keypair gets downloaded from Apple.	

This is the keypair I found in my "login" keychain.

You can export it to a file and reimport that file on another machine.
The best way to do this is to export the "Developer ID Application"
cert and the private key together in a pkcs12 (*.p12) file.