We need to create temporary certificates for signing apps on -dev. Note these are not going to be the final certificates, just temporary ones so we can do some end-to-end testing. Jeremy can you create the certificates as per Brian's requirements and then I'll link to them in marketplace code. Brian can you tell Jeremy the kind of certificates you'd like please as we spoke about in the vidyo call (but I didn't have time to write down).

You can use the same parameters we use for MARs for Firefox updates. See bug 704285 comment 10. You just need to change the "mar-nightly-X" to "mar-b2g-apps-X".

I ran the following commands: 4 certutil -d . -N 7 certutil -S -d . -s "CN=mar-apps-1" -n mar-apps-1 -x -t ",," -g 2048 9 certutil -S -d . -s "CN=mar-apps-2" -n mar-apps-2 -x -t ",," -g 2048 12 certutil -L -d . -n mar-apps-1 -r > mar-apps-1.der 13 certutil -L -d . -n mar-apps-2 -r > mar-apps-2.der And my directory looks like: nss_certs]$ ls cert8.db key3.db mar-apps-1.der mar-apps-2.der secmod.db What do I do with those files now?

Reading those comments it looks like they become parameters to signing tool "You then need to pass the path to mar-signing-database-do-not-copy-from-this-machine as the "-d" parameter to the mar signing tool, and the name of the cert as the -n parameter to the mar signing tool" We were hoping to avoid using signtool, so I'm wondering if we can turn those into a pem or file compatible with xpisign.

Ignoring signing so we can test the rest of the process. But I think we'll just create a normal cert and key for now. https://github.com/mozilla/zamboni/commit/b0a209

> certutil -S -d . -s "CN=mar-apps-1" -n mar-apps-1 -x -t ",," -g 2048 This simply means: Create a self-signed certificate with subject distinguished name CN=mar-apps-1 with an RSA 2048 key. It should be simple to do the same in OpenSSL which will output the PEM files in the format you need.

Where in settings do I configure the locations?

SIGNED_APPS_KEY is the path the pem file. SIGNED_APPS_SERVER_ACTIVE should stays as False until bug 797902 is good to go.

Brian, do you need me to send you the cert, key, or both?

Ping @bsmith for comment 8.

(In reply to Jeremy Orem [:oremj] from comment #8) > Brian, do you need me to send you the cert, key, or both? Do not ever send anybody the key under any circumstances. The certificate contains the public key. So, I need just the certificate.

Also, you can just attach the certificate (*not the key*) to this bug. It is fine for the certificate to be public.

Does the cert in comment 12 look okay?

(In reply to Brian Smith (:bsmith) from comment #5) > > certutil -S -d . -s "CN=mar-apps-1" -n mar-apps-1 -x -t ",," -g 2048 > > This simply means: Create a self-signed certificate with subject > distinguished name CN=mar-apps-1 with an RSA 2048 key. It should be simple > to do the same in OpenSSL which will output the PEM files in the format you > need. (In reply to Jeremy Orem [:oremj] from comment #13) > Does the cert in comment 12 look okay? For testing purposes, that certificate is fine. The final certificate should use a 2048-bit RSA key. The attached cert has a 1024-bit key. Also, we should use the SHA-256 hash algorithm instead of SHA-1 for all signatures, including especially the actual signatures on the app zip/jar/xpi files. I'm also working on the documentation for how the final certificates should be produced. I am going to share that after I've finished the signature verification code, which is what I'm working on today and tomorrow.

During testing I noticed that the attached certificate actually doesn't work because it is missing the EKU info. In bug 772365 I attached a script and an OpenSSL configuration file to be used in conjunction with it, which will allow the creation of new test certs with the proper properties. We need to generate certs (one EE cert, one CA cert) based on that script, keeping those certs secured sufficiently where we can load the newly-generated CA cert as the default trust anchor on the testing devices. I recommend keeping the scripts more-or-less as-is, except you may want to change the validity period of the certs from 3650 days to 90 days or something more reasonable, since these are just test certs that we won't be using for long. The official OpenSSL documentation does a pretty good job of explaining all the options and configuration settings, but they are confusing. Let me know what, if anything, needs documentation. Then, we need to sign at least a simple (no-op) app with the new cert for testing purposes; we will include that newly-signed app in the test suite. Please attach the newly-generated CA cert and newly-signed app here, and/or send them directly to me by email. I will document exactly how to sign the test app in bug 791741.

Actually, I noticed that I attached an out-of-date version of the script in bug 772365, so here's the updated version. Bob, it would be great to get any feedback on the parameters I chose for these certs, as I expect that we'll use the same parameters (except validity length) on the production certs.

Comment on attachment 677986 [details] [diff] [review] Script used to generate test CA cert and test EE cert Antonio, please review this script and the associated configuration file to see if anything seems problematic, as far as the stuff that goes into the cert is concerned (as opposed to the actually management of the test CA and security of the private keys implied by these scripts, which I already know if far-from-ideal). BTW, I included the Netscape cert type field but I didn't actually check if it was necessary. Perhaps it is better to mark it non-critical or remove it completely.

Comment on attachment 677986 [details] [diff] [review] Script used to generate test CA cert and test EE cert r+ from me on this, with a couple of nits. I would add #!/bin/sh at the start, and there seems to be missing a final return character at the last line.

Comment on attachment 677987 [details] openssl configuration file needed for previous script r+ from me fixing at least the first issue (incorrect extended key usage extension on the CA). >[req-examplla-app-signing-root-ca-1] >basicConstraints = critical,CA:TRUE >keyUsage = critical,keyCertSign >extendedKeyUsage = critical,codeSigning This is inconsistent with the X509 RFC and the real usage of the certificate. Besides Extended Key Usage being recommended mostly for end entity certificates, in this particular case it's incorrect since key usage (certificate signing) and extended key usage (code signing) are incompatible. So I would remove this extension. >nsCertType = objCA This is deprecated, I would remove it also. >[req-examplla-marketplace-app-signing-1] >basicConstraints = critical,CA:FALSE >keyUsage = critical,digitalSignature >extendedKeyUsage = critical,codeSigning >nsCertType = objsign Same as with the CA extension, this field is deprecated, I would remove it.

Is the script/config ready to go?

I will be updating it over the weekend as part of finalizing the app signing client side patches, but for generating a new test cert, you can use the files as-is, except for removing the two "nsCertType =" lines. (In reply to Antonio Manuel Amaya Calvo from comment #21) > This is inconsistent with the X509 RFC and the real usage of the > certificate. > Besides Extended Key Usage being recommended mostly for end entity > certificates, > in this particular case it's incorrect since key usage (certificate signing) > and > extended key usage (code signing) are incompatible. So I would remove this > extension. See bug 725351. I still want to include the EKU in the intermediate cert. It would be good to hear Bob's thoughts on it. > >nsCertType = objCA > > This is deprecated, I would remove it also. > > >nsCertType = objsign > > Same as with the CA extension, this field is deprecated, I would remove it. Yes, I have now verified that the signature verification works without the Netscape cert type extension. (There was conflicting information about whether our code signing verification still required that extension.)

(In reply to Brian Smith (:bsmith) from comment #23) > I will be updating it over the weekend as part of finalizing the app signing > client side patches, but for generating a new test cert, you can use the > files as-is, except for removing the two "nsCertType =" lines. > > (In reply to Antonio Manuel Amaya Calvo from comment #21) > > This is inconsistent with the X509 RFC and the real usage of the > > certificate. > > Besides Extended Key Usage being recommended mostly for end entity > > certificates, > > in this particular case it's incorrect since key usage (certificate signing) > > and > > extended key usage (code signing) are incompatible. So I would remove this > > extension. > > See bug 725351. I still want to include the EKU in the intermediate cert. It > would be good to hear Bob's thoughts on it. Ok, I've seen it now. I didn't knew that Microsoft had redefined the meaning of the EKU and that you were going along with it. For what it's worth, currently only Microsoft own CA's use the non-yet-standard semantic (at least on the intermediate CA list I have installed on my Windows machine), and I'm not very happy with redefining existing extensions to mean something they didn't mean originally instead of just adding a new extension (and much less doing it by way of accomplished facts instead of changing the standard first) but it's your call. Do you know if there's going to be a proposed change to the standard with this?

(In reply to Antonio Manuel Amaya Calvo from comment #24) > I didn't knew that Microsoft had redefined the meaning of the EKU and that > you were going along with it. For what it's worth, currently only Microsoft > own CA's use the non-yet-standard semantic (at least on the intermediate CA > list I have installed on my Windows machine), and I'm not very happy with > redefining existing extensions to mean something they didn't mean originally > instead of just adding a new extension (and much less doing it by way of > accomplished facts instead of changing the standard first) but it's your > call. > > Do you know if there's going to be a proposed change to the standard with > this? The IETF PKIX working group is shutting down so I'm not sure which group will update the spec. But, yes, I expect the spec to be updated in some way. Anyway, it's better to discuss that in bug 725351.

Comment on attachment 677986 [details] [diff] [review] Script used to generate test CA cert and test EE cert what's wrong with using certutil? I'm always leary of openssl creating certs with the same serial number... (they may have fixed that). bob

(In reply to Robert Relyea from comment #26) > what's wrong with using certutil? I'm always leary of openssl creating certs > with the same serial number... (they may have fixed that). IIRC, the server-side people asked for help in doing it with OpenSSL. I did rewrite the scripts that generate the certs for local testing using certutil anyway. But, I could not figure out how to get certutil to generate AKI and SKI automatically like OpenSSL can, so I ended up just ommitting AKI and SKI. Similarly, certutil doesn't have a non-interactive --basicConstraint option so I had to build a response file to pipe into certutil to get it to generate basic constraints without prompting.

What is the status of this bug?

rtilder helped me generate a key/cert pair for the dev app signing service. Does anything else need to be done?

rtilder helped me generate a key/cert pair for the dev app signing service. Does anything else need to be done?

sounds done to me

(In reply to Brian Smith (:bsmith) from comment #16) > We need to generate certs (one EE cert, one CA cert) based on that script, > keeping those certs secured sufficiently where we can load the > newly-generated CA cert as the default trust anchor on the testing devices. [...] > Then, we need to sign at least a simple (no-op) app with the new cert for > testing purposes; we will include that newly-signed app in the test suite. > Please attach the newly-generated CA cert and newly-signed app here, and/or > send them directly to me by email. > > I will document exactly how to sign the test app in bug 791741. Please attach a signed app and the root cert to this bug, so that I can review them and include them in the patches for bug 682525. I cannot finish bug 682525 without the root cert at least, because we need to embed that cert in the device.

(In reply to Brian Smith (:bsmith) from comment #32) > > I will document exactly how to sign the test app in bug 791741. The example signing script that shows all the settings needed for the certs is now in bug 772365 attachment 682525 [details] [diff] [review].

Here is the chain: -----BEGIN CERTIFICATE----- MIID+DCCAuCgAwIBAgIEAQAAADANBgkqhkiG9w0BAQsFADCBhDEbMBkGA1UEAxMS RXhhbXBsbGEgUm9vdCBDQSAxMRQwEgYDVQQLEwtFeGFtcGxsYSBDQTEdMBsGA1UE ChMURXhhbXBsbGEgQ29ycG9yYXRpb24xFjAUBgNVBAcTDU1vdW50YWluIFZpZXcx CzAJBgNVBAgTAkNBMQswCQYDVQQGEwJVUzAeFw0xMjExMTYxOTQ2NDhaFw0yMjEx MTQxOTQ2NDhaMIGpMSswKQYDVQQDEyJFeGFtcGxsYSBNYXJrZXRwbGFjZSBBcHAg U2lnbmluZyAxMSkwJwYDVQQLEyBFeGFtcGxsYSBNYXJrZXRwbGFjZSBBcHAgU2ln bmluZzEdMBsGA1UEChMURXhhbXBsbGEgQ29ycG9yYXRpb24xFjAUBgNVBAcTDU1v dW50YWluIFZpZXcxCzAJBgNVBAgTAkNBMQswCQYDVQQGEwJVUzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKcPxTyYqMBmcLYOIzv5m7dMXTzU/RFn3gay tFDaXElGStfp0D0hztgOw/BJ9w0U6FgqF2d7xZQ7/eVIVu3SfMWMY8OfImb9tgxO dv91qFVHt7Z4jPDN3vHa+GYq7EYFJPJ7Pz41v2j28ZVBWh/nYpIFzI+AKEbY2mHo SioLq+Oe7fTQ0lrwEsYwFJydC6w92ZhoFAB4qDC/kiuKidVS9N620fMz8ZN9V050 GfZAksIGA4kCWea6MnL7QYYsQJkPQ6gCJN41/CPDF4SX4vhsGi5Y51iFP9vVk8h2 UFGnBKlu4QA2PbMFtgKg3o/Ra3EITgfeYnYN4KMawssxBoFyDlUCAwEAAaNLMEkw DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwMwEQYJYIZIAYb4QgEBBAQDAgQQMA0GCSqGSIb3DQEBCwUAA4IBAQBGeIKh m1f+e8+m9AZuWqQxIskjkNDmzF804rncvpLAb7QV0JBLGV4r9tRsM04zdr3+VCEH Ybf7Dpg20vyoMI+sFgCbeShxfwCjQqOTf0BhBzkqtFgRzCxH4XWbEi7nC0uOXrxB f9ehwzY4amNkb/SpjzBoaB6zKOWARizsLK33ussci3s0U4oYiXr6t/oNEmRK07o5 i+jJb1u0pLDuDQ2K6MysHegUGxsBqqAXWFnEvxz5iGdBIjnfUhZt48Nxk1t4iB0f KOE+pAxb9B4euFfvnFIJQW6hnZyVtxcfL4Woht3/oY3dwiX386N9OsNqQh7RqJ0H UAcbM6h3dEcYdRNL -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIID0zCCArugAwIBAgIBATANBgkqhkiG9w0BAQUFADCBhDEbMBkGA1UEAxMSRXhh bXBsbGEgUm9vdCBDQSAxMRQwEgYDVQQLEwtFeGFtcGxsYSBDQTEdMBsGA1UEChMU RXhhbXBsbGEgQ29ycG9yYXRpb24xFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxCzAJ BgNVBAgTAkNBMQswCQYDVQQGEwJVUzAeFw0xMjExMTYxOTQ2MzVaFw0yMjExMTQx OTQ2MzVaMIGEMRswGQYDVQQDExJFeGFtcGxsYSBSb290IENBIDExFDASBgNVBAsT C0V4YW1wbGxhIENBMR0wGwYDVQQKExRFeGFtcGxsYSBDb3Jwb3JhdGlvbjEWMBQG A1UEBxMNTW91bnRhaW4gVmlldzELMAkGA1UECBMCQ0ExCzAJBgNVBAYTAlVTMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzmIBDAecwWuASNR17Sko/+0I AwOS4Lbn2B2mS+ZX1VGPTWa6TeVkRmcWGUN6YrAdTs3ktGe+ntCwGSxy9j494EHz ds8F+oSKhe+3IegqXd151MPnJPQNLU9YIwazD24AKWKgtxcJT8zyFfx1SQCYLgN5 2ZNdxZOROgHQxcMDTfJqja+zd4kY1JS5muWOtch66Jmdi8G5ursrPoYe7bRIn/zr UeUp0D9c8PMdjrEvCzNHqTOy5fmWSi5hxyF03T1ItD28pmSqVyP09Zt3gywSYIxX zM3w7LX4u3n329U26qL+KPsYdtBQ0UoytleH30TqTXnOux2Awgu6BJLQb6RXxwID AQABo04wTDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDAWBgNVHSUB Af8EDDAKBggrBgEFBQcDAzARBglghkgBhvhCAQEEBAMCAAEwDQYJKoZIhvcNAQEF BQADggEBAH/UufyK4VMCv9e9NvWMY4JBhzj+gCerw1UgLL03qw8QGDd0ulC0Mkut 0ILxbHFyp8bv/U7JA+7YZOOy3VZq4NURzn3500Uvi34U1N+P+22pqura+auKufj/ iXAOGKV00gNKxFu44FS8AkJA8THi8tZidEwXniKD/Lsa1sg3qda5z49ZwVeLs3z4 HkMHPX7GuBRth21Kug3h/dKUdGrDGIw3seBV90Y6EhY+nnYLhMcpjw7PWS4n0Ebe EdrRiDV52y7LVgyVzc4rtQnh5VbYZWSSRLvMoCKhCJO5ZYLSaxCZtZ+yv+mLJKp8 7DD7Q7B7C3c3skakdg/IrIvufrEIJS0= -----END CERTIFICATE-----

In general, those look OK but could you please re-generate them without the nsCertType extension? (See comment 23 and the preceeding discussion.) Thanks.

New certs: -----BEGIN CERTIFICATE----- MIID5TCCAs2gAwIBAgIEAQAAADANBgkqhkiG9w0BAQsFADCBhDEbMBkGA1UEAxMS RXhhbXBsbGEgUm9vdCBDQSAxMRQwEgYDVQQLEwtFeGFtcGxsYSBDQTEdMBsGA1UE ChMURXhhbXBsbGEgQ29ycG9yYXRpb24xFjAUBgNVBAcTDU1vdW50YWluIFZpZXcx CzAJBgNVBAgTAkNBMQswCQYDVQQGEwJVUzAeFw0xMjExMjEyMzAwMDhaFw0yMjEx MTkyMzAwMDhaMIGpMSswKQYDVQQDEyJFeGFtcGxsYSBNYXJrZXRwbGFjZSBBcHAg U2lnbmluZyAxMSkwJwYDVQQLEyBFeGFtcGxsYSBNYXJrZXRwbGFjZSBBcHAgU2ln bmluZzEdMBsGA1UEChMURXhhbXBsbGEgQ29ycG9yYXRpb24xFjAUBgNVBAcTDU1v dW50YWluIFZpZXcxCzAJBgNVBAgTAkNBMQswCQYDVQQGEwJVUzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALUf3+5RodJXiFUyBpEHW8Sp4DgLwk5SYnwW Bn3T1tnnlpUtlX3WkgBYV+ppF5VO65QWxdtlOivj61p2gMgnXJuqL9Lyua7Gkkpf ahA8glW/vXTYKh24eI1UZ7+lRWwIT+44yx2ON8YpwV9vrQG/D6WZYb6yWEWuL6L7 26zmSljYm5wGd0DHX3pNDqOQzeKJunekw44rQitGh4i+0ARONsuc/Mr+lJqkAKky wJm1HZiKVPrCyQI2IySJjg5juyXhtnQtH4g6yZBhi1hu2GjtVMzEppdwdi2h2MDn +J3ySsPGb3LVQk8CIUrAgGJhtCFijIA0q9jrbaKyvjm77MA3IFsCAwEAAaM4MDYw DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwMwDQYJKoZIhvcNAQELBQADggEBAETF3qwy8crcGa7TZLw7M1zu4dilT+yj ezTEMOVvLqAO1UZQ6zw8GPig6dNeZ79uL8nYpmvHr5lXpgNmoX9h2uMNjl9OGs5C EsaUb0H5PiBXfnCnetYkePpzTrPsnQAMlj95e0TlCOuVx6AjjQqU+95N8o8L9HQw lEmMojGY6vKz44SSXw+vB88n6mhkPehBGStHCOs9VYFAXh8CsjSE6eetUxlTKlxr 0ujjC5dTncQzUYz2oQtP9E4MuMo5TtNvf0CY7WqXgOzYTPmBq2jFe0e14tXHGBHK 6xRf2vk1zRUU6yQzo1zJkJtGZHH8xpD+q/4qnfoi/nwZNrULsvRUV9M= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDwDCCAqigAwIBAgIBATANBgkqhkiG9w0BAQUFADCBhDEbMBkGA1UEAxMSRXhh bXBsbGEgUm9vdCBDQSAxMRQwEgYDVQQLEwtFeGFtcGxsYSBDQTEdMBsGA1UEChMU RXhhbXBsbGEgQ29ycG9yYXRpb24xFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxCzAJ BgNVBAgTAkNBMQswCQYDVQQGEwJVUzAeFw0xMjExMjEyMzAwMDNaFw0yMjExMTky MzAwMDNaMIGEMRswGQYDVQQDExJFeGFtcGxsYSBSb290IENBIDExFDASBgNVBAsT C0V4YW1wbGxhIENBMR0wGwYDVQQKExRFeGFtcGxsYSBDb3Jwb3JhdGlvbjEWMBQG A1UEBxMNTW91bnRhaW4gVmlldzELMAkGA1UECBMCQ0ExCzAJBgNVBAYTAlVTMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2q2Aueu/440QF7Er7zE9/XT5 lB6XD6v7mzGHRrt6H/6XnUhRwzVs4N0f/QjRrju3ft3S86kpP81dY9HdtqhQ0sLX 8RuuxLdW1dilt1UQzPak8NkafKJFPZB/W8/a67yv0lPhUhk1on04IlM7hekv2MV8 BDvUa1MRrUkKTMj87/0BBxz8nUlKcR7Tk5Sy3uCfHUmCx1KtK681H/idDDuHz0j+ hUrd31bjnAOVG+46+bF942uyrxmYTrlQgbsV/EXmV9bM3N1G3kxsNvA6yqUDn//C a7nfd78vQ2XVhZ38DlC/eRn78kMBfU1hD8hS41dZmqQ/LrPpJLs9RJaUp9G2zwID AQABozswOTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDAWBgNVHSUB Af8EDDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOCAQEAl1BLyPwCAnN3PHKb FG+NsQE9gXUuS0PXkmI+ZZIhlzYTfdNkDvq/c/JCfq4DRz3YrcbEk7a5ZmpgD3Yu HBEqWwhPT1mMXPUabd08UB4C8RCd9oNlsuu3vzP/iO3xej+QqgP9erBFyc8T35kr 14oqO6H5ZUytKsIZaAF0sHtUhpztlS6UboA2AGPVSeFvfdTFVjkr1XP6L92HYCHG GPCbifvZqvA3xrwn73TOpG9SpxjWwOoZH7F+2+LekYcMjGIOOsX4JmBbPF+IUFbB gujb5+Kr1di+cDw2trERLjRq+OqWyUD+w5W7Zse9NsiJluRmViGfH4sB1UpLLKhI Ii8dkA== -----END CERTIFICATE-----