I have to add some certificates to firefox before building it. Then test it with this certificates. I know that certificates are hardcoded into the certdata.txt, in this location:
mozilla-source\mozilla-central\security\nss\lib\ckfw\builtins
I've tried to add certificates into the certdata.txt using addbuilit from nss-tools. But after building it I get errors.
Compiler shows this errors when reading certdata.txt:
0:49.23 c:/mozilla-source/mozilla-central/obj-x86_64-pc-mingw32/security/nss/lib/ckfw/builtins/builtins_nssckbi/certdata.c(20983,1): warning: missing terminating '"' character [-Winvalid-pp-token]
0:49.23 "\152\270\202\165\004\122\100\146\207\136\301\151\270\325\275\134
Actually it's pretty easy to do.
Firstly you need a nss and nspr, because of nss that is built in to mozilla installer does not have addbuiltin function that we need.
Download NSS for windows
Download Nspr for windows
Second step
unpack both of these files.
Then copy the contents of the NSPR /lib folder to the NSS /bin folder
Copy your certificate and certutil.txt to the NSS /bin folder.
Note: Your certificate should be in .der format!
Third step
Run this code bellow:
addbuiltin -n "My certificate name" -t "CT,C,C" < CAcert.der >> certdata.txt
My certificate name - The name of the certificate that will be added to the certutil.txt.
CT,C,C - Is the trusted properties of the certificate.
CAcert.der - Certificate itself.
certdata.txt - Certificates containing file.
But before copying certutil.txt back to the source code you have to do one more thing.
Open certutil.txt in Notepad++ and turn on hidden characters by Menu View → Show Symbol → Show All Characters. Then change /r/n to /n.
And you've done!
I want to manually add .mobileprovision to the keychain access without using xCode because I didn't develop the app with xCode. Any suggestions?
I found a YouTube video by Kotobee to be immensely helpful.
You will need an OpenSSL. All necessary info is within this video.
My personal notes from this video:
Step 1: Need Open SSL folder
Step 2:
Process of making the KEYS
https://youtu.be/yCvbbIfMnxI?t=6m
https://youtu.be/yCvbbIfMnxI?t=8m4s
1ST KEY
certificate signing request file (CSR)
open SSL file in COMMAND PROMPT (cmd)
openssl genrsa -out [keyname].key 2048
// optional change [keyname]
(NOTE: if issues locating openssl.cfg type at command prmpt
set OPENSSL_conf-d:\OpenSSL-Win64\bin\openssl.cfg
nothing will show on command prmpt, but continue)
2ND KEY
making the CertificateSigningRequest.certSigningRequest KEY
//// video timestamp around 13:00 //////
openssl req -new -key [keyname].key -out CertificateSigningRequest.certSigningRequest -subj "/emailAddress=yourEmail#whatever.com, CN= companyName, C=US"
C=US is about the country of origin. So you may need to change this if not US.
NOTE: SEEMS LIKE ONCE YOU HAVE THE KEY FROM OPENSSL, don't need to do this process again. Not positive though, but so far seems true.
3RD KEY
https://youtu.be/yCvbbIfMnxI?t=14m52s
log into developer.apple.com account
3 steps:
STEP A:
Certificates
there's a DIFFERENCE between DEVELOPMENT & PRODUCTION/DISTRIBUTION
Click the PLUS sign in upper right corner of web page.
You can likely reUPLOAD the SAME key created under name:
CertificateSigningRequest.certSigningRequest
dev site will return "Your certificate is ready" to download
file name will be
ios_distribution.cer for DISTRIBUTION KEY
ios_development.cer for DEVELOPMENT KEY
/// NOTE: SO FAR LOOKS LIKE YOU CAN USE SAME KEY ONCE MADE!
Put your .cer file into the OpenSSL bin folder
STEP B:
Make your APP ID via the developer.apple.com site
https://youtu.be/yCvbbIfMnxI?t=16m58s
THIS SECTION appears to need to change per app, especially for DISTRIBUTION
could just use the wildcard key and be done with it for DEVELOPMENT
STEP C: Create .mobileprovision file
(note: this will include your registered devices)
Make an APP ID
click on Identifiers > App IDs >
Explicit App: Dev Prov Profile
App Bundle: id="com.domain.app"
Enabled: Push Notifications (can exclude this line)
Download new .mobileprovision file from developer.apple.com into
D:\OpenSSL-Win64\bin
Make sure latest CertificateSigningRequest.certSigningRequest file in
D:\OpenSSL-Win64\bin
Along with .key file in D:\OpenSSL-Win64\bin
STEP D: Create .pem file
In Command Prompt type:
openssl x509 -in [developer_certificate].cer -inform DER -out [app_pem_file].pem -outform PEM
ios_distribution.cer OR ios_development.cer
rename the [app_pem_file].pem file if you like -- make it similar (my thought)
to bundle app ID name or Explicit App name
OR
make it same as the .key name (if recreating & not using a previous one)
this creates the .PEM file
STEP E: Create .p12 file (final task)
In Command Prompt type:
openssl pkcs12 -export -inkey [keyname].key -in [app_pem_file].pem -out [app_p12].p12
As I said, all this information is on the video. You don't need my personal notes to get the key. :)
I have the following designated requirement in my app:
(
anchor apple generic
and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */
or
anchor apple generic
and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */
and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */
and certificate leaf[subject.OU] = <redacted_team_id>
)
and identifier "com.company.app"
Now I’m trying to validate a development build of my app against this DR. The “apple generic” root certificate check works fine, the bundle identifier check works fine. The certificate check in the first branch (6.1.9) looks for a “Apple Mac App Signing (Release)” certificate, so it fails. That’s expected with a development build.
As I understand the DR, the second branch (checking for certificate fields 6.2.6 and 6.1.13) should apply to development builds, but both certificate field checks fail:
$ codesign --verify -R="certificate 1[field.1.2.840.113635.100.6.2.6]" MyApp.app
test-requirement: code failed to satisfy specified code requirement(s)
$ codesign --verify -R="certificate leaf[field.1.2.840.113635.100.6.1.13]" MyApp.app
test-requirement: code failed to satisfy specified code requirement(s)
My question is: what exactly are the 6.2.6 and 6.1.13 certificate fields and why doesn’t my (properly signed) development build match them?
The 6.2.6 and 6.1.13 certificate fields are related to apps signed with the Developer ID certificate. The development build doesn’t match them because it was signed with the plain Mac development certificate.
HTTPS for https://www.bigfont.ca is working in Chrome, Internet Explorer, and Safari but not in Firefox. It also passes all the tests at this SSL Checkers. Firefox says:
An error occurred during a connection to www.bigfont.ca.
Peer's certificate has been marked as not trusted by the user.
(Error code: sec_error_untrusted_cert)
This is a known situation with Firefox. We looked at the StartSSL FAQ and the advice is:
You must add the intermediate CA certificate to your installation.
We are using SmartSSL and OpenSSL to create an SSL Certificate. So, we added the intermediate CA certificate by following Troy Hunt's tutorial and ran this command to create the PFX.
OpenSSL> pkcs12 -export -in bigfont.ca.crt -inkey bigfont.ca-encrypted.key
-certfile sub.class1.server.ca.pem -out bigfont.ca.pfx -password pass:my-password
We uploaded the resultant bigfont.ca.pfx file to at the Azure Website's Config page.
To test further, we ran openssl s_client -servername www.bigfont.ca -connect www.bigfont.ca:443 -showcerts. The results show that the certificate chain is working well.
depth=1 C = IL,
O = StartCom Ltd.,
OU = Secure Digital Certificate Signing,
CN = StartCom Class 1 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:
/description=T8eg9X1a04Scp3hM
/C=CA
/CN=www.bigfont.ca
/emailAddress=shaunluttin#bigfont.ca
i:
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
1 s:
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
i:
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=
/description=T8eg9X1a04Scp3hM
/C=CA
/CN=www.bigfont.ca
/emailAddress=shaunluttin#bigfont.ca
issuer=
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3369 bytes and written 547 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: 6E1F00009...FDD7B7BF7B7
Session-ID-ctx:
Master-Key: 2FA3C020A506198C1319081F9E023D35...5AEB01985323AADCF9
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1413947020
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=10054
If the chain is working, why does Firefox complain?
Solution
Reset Firefox to its default state.
Firefox
Help
Troubleshooting Information
Reset Firefox
Details
The problem turned out to be related to the cert8.db file that stores the Firefox certificates. Find it here:
Firefox
Help
Troubleshooting Information
Application Basics
Profile Folder
Show Folder
The problem was probably that we messed with Firefox's Authorities Certificate for StartCom. We probably did this while muddling thru the process of restoring our StartSSL Client Authentication certificate.
Your Certificates (Client Authentication)
Authorities
We probably accidentally messed with these, thereby making Firefox not trust StartCom.
It wasn't relevant when the question was asked, but it is worth mentioning now.
A lot of browsers has stopped trusting StartCom.
The previous answers might still help with similar problems for other issuers than StartCom.
But if you are still using StartCom, you might want to switch to https://letsencrypt.org
Deleting the CA certificate and importing it again did the trick for me.
I've created a Firefox plugin, a Win32-native code DLL - using Firebreath. I'm working on Windows 7/x64, and targeting Windows only. The plugin itself is working well, but I'm really stuck getting a correctly signed XPI. If I don't sign my XPI, it's accepted and installed by FF 3.6 thru 10 (beta). Of course, during the install it lists the publisher as (Author not verified). So, I spent a week debugging the signing process... but FF 9 and 10 still say (Author not verified)! FF 3.6 rejects the signed XPI as invalid.
How do I troubleshoot this??
Just to repeat: I sign the xpi without error, and the resulting XPI installs successfully on FF 9 and 10, but FF still says (Author not verified).
Here's the batch code I use to sign the XPI:
echo * clean out old signing folder and xpi
if exist package rmdir /S /Q package
if exist %package%.xpi del %package%.xpi
echo * copy in files for package
md package
xcopy ..\*.rdf package
md package\plugins
xcopy ..\build\bin\Plugin\Debug\*.dll package\plugins
echo * clean out certificate database
del *.db
echo * import our signing certificate
pk12util -d . -i %keyfile% -K %pwd% -w keypass.txt
echo * adjust trust on base, intermediate and root cert
certutil -M -d . -n "VeriSign" -t "c,c,C"
certutil -M -d . -n "VeriSign Class 3 Code Signing 2010 CA - VeriSign, Inc." -t "TC,TC,TC"
certutil -M -d . -n "%certname%" -t "u,u,Cu"
certutil -L -d .
echo * create signed package
signtool -d . -X -Z %package%.xpi -k "%certname%" -p %pwd% package
I work for Mozilla, but this isn't an authoritative answer, just what I've gathered asking around:
So, essentially, each certificate authority has three trust bits Mozilla might grant it: they might trust it to sign websites, and/or mail, and/or code. Your certificate is from a certificate authority that Mozilla doesn't trust to sign code. (This is why going and manually setting the bit in your preferences makes it work—for you.)
I'm told so few people try to use binary code in xpi's that Mozilla doesn't really have an organized way to find out which authorities can be used for what. However, you can check out this list: look at the "Code Trust Bit":
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
For example (picked completely at random), ComSign Secured CA has the "Websites" and "Code" trust bits set.
I gather that Mozilla publicly discusses what rights to grant to each CA, and re-evaluates each CA periodically:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Basically your signature needs to include full certificate chain up to the trusted VeriSign root certificate, bypassing the "VeriSign Class 3 Public Primary Certification Authority - G5" with unknown trust in mozilla (bug 602107), as by default the chain ends too soon.
Your XPI is currently signed with your certificate, with no further certificate chain included, relying that the user's browser will trust the issuer of your certificate immediately. You can examine this with Mozilla's jarsigner tool (see Mozilla NSS tools):
Tools\nss-3.11>jarsigner -verify -verbose -certs my-old.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
(showing just the output for the 1st file)
You need to include a few more certificates to complete the chain to a certificate that is by default explicitly trusted in the end user's browser. In the end it should look like this:
jarsigner -verify -verbose -certs my-newly-signed.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
X.509, CN=VeriSign Class 3 Code Signing 2010 CA, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.2.10 1:00 to 8.2.20 0:59]
[KeyUsage extension does not support code signing]
X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.11.06 1:00 to 8.11.21 0:59]
[KeyUsage extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 23.5.06 19:01 to 23.5.16 19:11]
To achieve this you need to:
remove the not-explicitly-trusted VeriSing's built-in certificates from the certificate database with Mozilla's certutil tool
Build the certificate trust chain of your certificate all the way up to Microsoft's "Class 3 Public Primary Certification Authority".
sign the xpi (this time full certificates chain will be included in the signature)
verify the xpi with jarsigner as described above
test the xpi in Firefox - you should not see "Author not verified" anymore.
Caveats:
Trust bits in the built-in Firefox certificate store are actually 3-state (trusted, untrusted and unknown), despite only being shown as 2-state checkbox in the FF GUI (checked=trusted, unchecked=untrusted OR unknown). By default trust is unknown, which enables you to bypass the VeriSign's certificate as described. If you ever enabled trust via FF's checkboxes it will still work, but if you uncheck the trust checkbox the trust will be set to untrusted, which will prevent bypassing that certificate in the chain. The easiest (only?) way to reset this back to initial unknown is to delete your firefox profile.
After Mozilla eventually enables the code-signing trust bit (see the bug above) you will still need to sign like this if you want to support older versions of Firefox.
Hope it helps!