I would like to know how to read an app bundles signature and the certificate which comes with the signature. I have been using the codesign tool so far. However I would like to retrieve these information in a more programatic manner. In the man pages is written that the codesign tool is just a shell wrapper of the codes signing api. The Code Signing Guide in the apple developer library says that the signature itself is stored in the binary file. Now my question is how do I get these information from the binary file?
Ok I found a solution with the help of this post and the Security Transforms Programming Guide I am able to solve this problem.
Related
Hopefully, as I understood correctly to safely transmit (post) data from a phonegap / cordova hybrid app to a server, I need a procedure to check the SSL certificate of my server. Am I right?
The tool PhoneGap SSL Certificate Checker plugin developed by eddyverbruggen (to be found here https://www.npmjs.com/package/cordova-plugin-sslcertificatechecker) seems the most user friendly tool available.
However, from the guide, I cannot deduce how to properly use the tool.
Is it sufficient to call the function window.plugins.sslCertificateChecker.check when the app is launched or;
Do I need to call the function everytime the user wants to post (and retrieve) data to (from) the server; calling the post function (an ajax function) in the successCallback?
Thank you
PS. I also encountered the Cordova Advanced HTTP plugin (https://www.npmjs.com/package/cordova-plugin-advanced-http) that seems less user friendly to me. I think it is a separate question, but if someone could give a hint about the differences between the two plugins, that would be appreciated too.
I've developed application which communicates with my own server over HTTPS. And I use .p12 certificate for mutual authorization. The problem is that after I send first request on server I receive OSX's dialog message:
I know that need to make code sign but:
Can I make some workaround/hack/trick to prevent it? Please note that my app is not going to go on Mac Store. So I could use any private API.
If we can't prevent this dialog then what should I do:
1. Code sign my application via Mac Developer Program?
2. Or make trusted my p12 certificate?
If need to make some of these items above please provide a quote as proof from Apple's documentation.
I use OSX 10.8 an later.
Code signing your application is the most straightforward way to avoid this dialog. When importing the certificate and private key your signed application and future versions that match its designated requirement will be given access to the key for all purposes. See Mac OS X Code Signing In Depth and the Code Signing Guide for more information.
On your development systems that have already imported the key into the keychain you may see the authorization prompt one additional time, on systems that do not yet have the key in the keychain the prompt shouldn't appear at all.
We are building a web application(Java). Could anybody help brief me what we need to realize the following business scenario ?
An user access our web site
He inputs some data
He generate a PDF file from the data he input and export it
He digitally sign this PDF file
He then upload this PDF file to our web site
The system can parse the PDF file to know who signed this file and be sure it is of integrity and Non-repudiation and to some post-processes.
My questions are:
What products/libraries(commercial or free opensource) should I need to implement the above ?
Do those products provide API for developers to programmatically operate the signing process and retrieve information from a signed documents ?
Is it a reasonable or proper way to do the digital signature in the above 3~5 steps ? could the user sign the data online in one step(e.g., without export a PDF file) ?
iText is a java library which, amongst other things, enables you to sign and verify signatures on pdf documents. This would enable your users to sign a pdf online. A good example of using iText for signing and verifying signatures in pdf documents can be found here
The library's licence is AGPL i.e. you need to release your software under AGPL or buy a commercial licence.
It used to be under the LGPL so you can work with iText 2.1.7 under the terms of LGPL and not need to buy a commercial licence.
If the data is located on the client, then your easiest option is to create a Java applet which will be executed in browser, and which will sign the data. Any data can be signed, and you don't need PDF just for signing. Generic binary data can be signed using PKCS#7/CMS format or using XMLDSig (less widespread option).
For signing data in Java applet you can use BouncyCastle or our SecureBlackbox (Java edition). BouncyCastle is open-source and SecureBlackbox comes with support, documentation and samples.
I have been searching all over the apple documentation, including these forums, yet was not able to retrieve a certificate from a configuration profile that I had created and installed on my iPhone.
More specifically:
Using the iPhone Configuration Utility, I created a simple configuration profile that contains a certificate under the Credentials tab.
I am now trying to retrieve this certificate using my iPhone app but without any luck of coming across useful documentation/examples.
I know how to extract PKCS12 data - I just don't know where to find the certificate data to begin with.
Is there a path to the certificate data or to an NSDictionary of configuration profile values?
It seems it is not possible currently to read a profile. See https://devforums.apple.com/message/533356 (requires login).
Was looking for the same thing, to authenticate user as an enterprise employee.
"Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)”
I get this error when trying to upload my app through the Application Loader.
Any ideas whats wrong and how I can sort it?
Adam
You can check your configuration in this iPhone development forum topic
I've seen this error pop-up due to XCode 4.x incorrectly handling schemes whose names contain spaces